java - JDBC4Connection 中的内存泄漏

Question

我试图在我们的一个 Java 守护程序中捕获内存泄漏，在转储内存并通过内存分析器工具对其进行分析后，我注意到大部分泄漏是由 JDBC4Connection 引起的:

10 instances of "com.mysql.jdbc.JDBC4Connection", loaded by "sun.misc.Launcher$AppClassLoader @ 0x2aaab620ed00" occupy 858,283,752 (81.55%) bytes. Biggest instances:

* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64ad820 - 87,110,160 (8.28%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64af520 - 86,730,408 (8.24%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64ad0e0 - 86,584,048 (8.23%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64aede0 - 86,488,800 (8.22%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab61f5320 - 85,752,872 (8.15%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64ae6a0 - 85,603,280 (8.13%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64adf60 - 85,270,440 (8.10%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab61f4be0 - 85,248,592 (8.10%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab64afc60 - 85,120,704 (8.09%) bytes.
* com.mysql.jdbc.JDBC4Connection @ 0x2aaab61f5a60 - 84,374,448 (8.02%) bytes.

Keywords
com.mysql.jdbc.JDBC4Connection
sun.misc.Launcher$AppClassLoader @ 0x2aaab620ed00

我很确定我们关闭了所有 MySQL 资源，但无法完全找到导致这种情况的原因。

有什么好的捕捉方法吗？您过去是否遇到过这种情况，可以建议我应该寻找什么？

附言:深入了解 MAT，我看到以下信息:

com.mysql.jdbc.JDBC4Connection @ 0x2aaab64ad820 | 1,856 | 87,110,160 | 8.28%
|- java.util.HashMap @ 0x2aaab62115a8 | 64 | 87,021,632 | 8.27%
| '- java.util.HashMap$Entry[16384] @ 0x2aaae182e970| 131,096 | 87,021,568 | 8.27%

似乎每个 JDBC 都持有大量的 Hashmap 条目(>6000 个对象)，并且根本没有释放它们。

提前致谢!

Answer 1

Duffymo 几乎可以肯定是正确的。在过去，当我们遇到内存泄漏时，它实际上总是 MySQL JDBC 驱动程序。只是忘记在某处关闭一个小的 ResultSet 或 Connection 或 Statement。每次我们使用它们来发现问题并确保它们得到解决时，我最终都会审核整个代码库。

至于HashMap，我也见过。我没有查看源代码，但我的印象是 MySQL 驱动程序在内部将行(至少是行值)存储在 HashMap 中。

泄漏结果集非常容易。由于这个原因，JDK 7 或 8 中那些自行处理这些问题的可关闭资源的想法真的很吸引我。

您可以在某处(比如连接)插入一个垫片类来记录每个打开/关闭的资源，看看您是否可以在不直接读取所有源代码的情况下找到泄漏的位置。