可以使用哪种方法调查Java中的数据库连接使用情况? [英] What method can be used for the investigation of Database Connection usage in Java?

问题描述

可以使用哪种方法调查Java中数据库连接的使用情况?

What method can be used for the investigation of Database Connection usage in Java?

开发人员正在支持复杂的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 methods 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.

我假设您在Java端使用一致的方法来获取数据库连接(是否池化无关紧要).

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

这个想法是在连接工厂/连接池或其周围创建一个非常轻巧的包装器类.包装器将实现任何有意义的jdbc接口，因此您可以将其交换为常规连接对象，但是大多数方法只会透明地调用/返回基础连接.

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.

如果您使用某种IoC框架(例如spring)，则应该能够轻松地在配置级别交换出connection/factory类.现在，您所有的Java代码都将使用新的数据库连接包装器.

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.

如果使用的是池，则调用 connection.close()通常只会将对象返回到池中，而不是破坏连接.因此，该技术适用于正常的连接泄漏或只是未返回到池(池已耗尽)"泄漏.

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.

在连接包装器的构造函数或工厂方法中，创建一个新的 Throwable 对象，并将其作为本地变量存储在包装器中，以备后用.我们使用 Throwable ，因为它比使用 Thread.currentThread().getStackTrace()更快/更便宜.

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().

在包装器类中实现 finalize 方法.这是一种由于对象不再使用而被销毁时由GC调用的清理方法.

Implement the finalize 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.

finalize 方法应检查我关闭了吗?".如果已经关闭，则一切都很好...但是，如果连接处于GC状态，但尚未关闭，则这是泄漏"连接.

The finalize 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.

现在， Throwable 重新开始播放.我们可以抓取 Throwable 并输出一条类似以下内容的日志消息:我的连接已泄漏，这是与我的创作者牵连的堆栈跟踪."

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."

此方法可以适应多种情况.当然，您可以将其他类型的数据保留在包装中，以对特定问题进行故障排除.例如创建时间.然后，您可以轮询寿命长的连接，并再次暗示创建者.或者，您可以轮询现有连接并解析 Throwable 堆栈跟踪，以获取有关哪些代码随时间使用了多少连接的数据.

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屋！