【发布时间】:2010-12-10 04:11:19
【问题描述】:
我们在旧代码中发现了一个未关闭连接的错误。这是一个简单的修复,但我想知道我们如何证明它已修复。可以选择是否使用连接池。对于池的使用,添加对池的监控很容易,但是当不使用连接池时,我们如何跟踪那些未关闭的孤立连接?和其他内存泄漏一样吗?
这个错误看起来基本上是一个剪切和粘贴错误。我们有一些管理数据库连接的类,所以大致如下所示:
OurDBConn conn1 = ConnectionManager.getConnection();
try {
// business logic
} catch () {
//
} finally {
ConnectionManager.returnConnection(conn1);
}
/// and then later in the same method
OurDBConn conn2 = ConnectionManager.getConnection();
try {
// business logic
} catch () {
//
} finally {
ConnectionManager.returnConnection(conn1); // NOTE Error: conn1 should be conn2
}
我不知道为什么早期的编码人员不只是重用原始连接,但事实就是这样
(开始编辑/追加)
是的,连接代码也是我们的,所以我可以使用给出的答案。
但是,尽管下面的答案回答了我提出的问题,但我认为我没有提出正确的问题。我不确定stackoverflow 的正确做法是什么;问另一个问题,还是编辑这个?
我应该问的一个问题是:这些孤立的、未关闭的连接如何在系统性能中体现出来?另外,既然这些连接对象只存在于某个方法的范围内,那么这些连接难道不符合垃圾回收的条件吗?然后如果它们被 gc'ed,那么打开的连接被 gc'ed 有什么影响?
(结束编辑)
【问题讨论】:
-
我会密切关注这一点,我们的几个项目中都存在非常相似的问题。
-
作为记录,我需要有一个非常好的理由不将其移至成熟的连接池实现,例如 DBCP 或 C3PO - 如果你有机会 - 也许你应该考虑这样做?
标签: java jdbc connection-pooling