0

我目前有一个 Java EE 应用程序，我在其中实现了自己的连接池类。我使用的每种方法都执行一个简单的查询（Statement 和 ResultSet）。在我使用 JDBC/my pool 的每个方法的 finally 块中，我首先关闭 ResultSet，然后关闭 Statement，因为书籍和网上指示应该做的很多很多资源。最后，我将连接返回到池中。

在查看 JVM 的内存时，我注意到在我通过连接池使用 JDBC 进行调用后，内存从未真正释放，或者需要很长时间才能释放。我检查了我的垃圾收集设置，并且正在使用 gencon (IBM WebSphere)，许多在线资源都表明它也非常好。我也在我的应用程序中使用 Spring Framework。

我写的连接池类很简单。初始化时，它会创建一定数量的数据库连接并将它们添加到队列中（我尝试了另一种仅使用简单向量的实现，但与内存的结果相同）。当您请求连接时，它会检查以确保有可用的连接，如果有，它会向调用者提供一个连接。最后，您将其返回并将其放回队列/向量中。

我想知道是否还有其他可以做的？我应该让 Spring Framework 来处理我的连接池，还是有其他东西可以更好地处理内存？对我来说，这确实有意义，但我对实现连接池不太熟悉。所有资源都说要做我正在做的事情，但我假设他们可能正在使用一些内置的池实现。我确实知道关闭连接是有效的，但由于这是一个自定义池解决方案，我不能真正做到这一点。

谢谢！

4

2 回答 2

4

您的应用程序是否在 WebSphere 应用程序服务器中运行？它是从应用服务器获取它的数据源，而不是自己创建它吗？如果是这样，那么连接和语句已经被池化了，您不需要自己池化它们。

于 2012-10-29T22:33:23.310 回答
2

好的，第一件事是第一件事：除非你有很好的理由，否则实现你自己的连接池机制是一种不必要的风险练习。那里有许多连接池机制可供选择 - Spring 将是其中之一，Jakarta 的 DBCP 是另一个。如果您可以选择使用第三方实用程序进行连接池 - 请执行此操作。如果您在容器中运行，让容器为您完成工作（WebSphere 已经通过它的各种“帮助类”完成了这项工作）。

关于您遇到的症状：内存未释放的事实并不意味着存在内存泄漏。由 JVM 决定是否以及何时真正释放未引用的对象实例。您是否也遇到 OutOfMemory 错误？

首先发出一些堆转储（在 JDBC 资源发布之后）以查看其中发生了什么。

关于你写的代码——不发布代码，很难猜测你是否有隐藏的错误；但是您描述的流程似乎是正确的。

于 2012-10-29T22:32:46.603 回答