什么是用于调查Java中的数据库连接使用的好工具？ [英] What is a good tool for the investigation of Database Connection usage in Java?

问题描述

什么是调查Java中的数据库连接使用的好工具？

开发人员正在支持一个复杂的Java程序，可用。因为问题是零星的，知道哪个线程已经打开了多个连接到数据库以集中在这个区域的努力是有用的。

最后，正确的修复似乎是重写程序来重用连接，而不是每个线程打开多个连接。

我问，开发人员在他的工具箱中应该有什么工具调查资源，即已由线程分配的数据库连接。

解决方案

不是特定的工具，用于跟踪哪些代码负责打开连接或其他资源。

我假设您在java端使用一致的方法来获取数据库连接（池或

这个想法是在连接工厂/池或者其他任何地方创建一个非常轻的包装类。包装器将实现任何jdbc接口有意义，所以你可以交换它的正常连接对象，但大多数方法将透明地调用/返回底层连接。

如果你正在使用某种IoC框架（例如spring），你应该能够轻松地在配置级别换出连接/工厂类。现在所有的java代码都将使用你的新的数据库连接包装。

如果你使用一个池，然后调用 connection.close / code>通常只是将对象返回到池，而不是销毁连接。所以这种技术适用于正常的连接泄漏或只是不返回到池（池耗尽）泄漏。

现在我们只需要记录有趣的位并设置陷阱

堆栈跟踪以标识创建者

在连接的构造函数或工厂方法中一个新的 Throwable 对象，并将它作为一个局部变量存储在你的包装器中。我们使用 Throwable ，因为它比使用 Thread.currentThread（）。getStackTrace（） p>

设置陷阱

实现 finally 方法在你的包装类。这是一个由GC调用的清除方法，当对象被销毁时，因为它不再使用。

finally 方法应该检查我我关闭了吗？如果已经关闭，那么一切都很好...但是如果连接是GCed，它没有被关闭...然后这是一个泄漏连接。

现在 Throwable 又回来了。我们可以抓取 Throwable 并输出一个很好的日志消息，说：我是一个泄漏的连接，这里是一个堆栈跟踪我的创建者。

扩展构思

此方法可适用于各种情况。当然，您可以在包装器中保留其他类型的数据，以解决特定问题。例如创建时间。然后，您可以轮询长期连接，并再次暗示创建者。或者，您可以轮询现有连接并解析 Throwable 堆栈跟踪，以获取关于使用随时间的连接数的代码的数据。

可能有一个现成的工具，也可以做这些类型的东西，但应用这种技术所需的代码量在大多数情况下是非常小的（假设你有一个简单的方法来交换我们的db连接工厂没有搜索 - 替换整个代码库）。

What is a good tool for the investigation of Database Connection usage in Java?

A developer is supporting a complex Java program which is ocassionally exhausting the number of Database connections available. Since the problem is sporadic it would be useful to know which thread has opened multiple connections to the database to focus the effort in this area.

In the end, the correct fix seems to be to rewrite the program to reuse connections and not open multiple connections per thread.

I am asking, what tools should the developer have in his tool box to be able to investigate the resources i.e. Database Connections that have been allocated by a thread.

解决方案

Not a specific tool, but rather a debugging technique for tracking down which code is responsible for open connections or other resources.

I am assuming you are using a consistent method on the java side to get a db connection (pooled or not doesn't matter).

The idea is to create a very light wrapper class around your connection factory/pool or whatever it is. The wrapper will implement whatever jdbc interface makes sense so you can swap it in for your normal connection object but most methods will just transparently call/return the underlying connection.

If you are using some sort of IoC framework (e.g. spring) you should be able to easily swap out the connection/factory class at a config level. Now all your java code will be using your new db connection wrapper.

If you are using a pool, then calling connection.close() usually just returns the object to the pool instead of destroying the connection. So this technique works for normal connection leak or just "not returned to pool (pool exhausted)" leak.

Now we just need to log the interesting bits and set a trap for leaked connections.

Stack trace to identify creator

In the constructor or factory method for your connection wrapper create a new Throwable object and store it as a local variable within your wrapper for later. We use a Throwable because it is faster/cheaper than using Thread.currentThread().getStackTrace().

Set the "trap"

Implement the finally method in your wrapper class. This is a cleanup method called by the GC when the object is being destroyed because it is no longer used.

The finally method should check "am I closed?". If already closed, then everything is fine... however if the connection is being GCed and it hasn't been closed... then this is a "leaked" connection.

Now the Throwable comes back into play. We can grab the Throwable and output a nice log message saying something like: "I'm a leaked connection and here is a stack trace implicating my creator."

Expanding the idea

This method can be adapted for a variety of situations. You can of course keep other types of data in your wrapper for troubleshooting your specific issue. For instance creation time. Then you can poll for long-lived connections and again implicate the creator. Or you can poll existing connections and parse the Throwable stack traces to get data on which code is using how many connections over time.

There is probably an off-the-shelf tool that can also do these types of things, but the amount of code required to apply this technique is very minimal in most cases (assuming you have an easy way to swap our your db connection factory without search-replacing your whole codebase).

这篇关于什么是用于调查Java中的数据库连接使用的好工具？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！