Java进程内存无限增长。内存泄漏？

Question

我们有一个在Solaris 10上运行的java进程，为大约200-300个并发用户提供服务。管理员报告说，随着时间的推移，进程使用的内存显著增加。几天内它就达到2GB，并且从未停止增长。

我们已经转储了堆，并使用Eclipse内存探查器对其进行了分析，但没有看到任何异常。堆的大小非常小。

在添加内存统计html" target="_blank">日志记录后，我们在应用程序中发现管理员使用的“top”实用程序报告的内存使用量与MemoryMXBean和运行时库报告的内存使用量之间存在差异。

下面是两者的输出。

Memory usage information 

From the Runtime library
Free memory: 381MB
Allocated memory: 74MB
Max memory: 456MB
Total free memory: 381MB

From the MemoryMXBean library.
Heap Committed: 136MB
Heap Init: 64MB
Heap Used: 74MB
Heap Max: 456MB
Non Heap Committed: 73MB
Non Heap Init: 4MB
Non Heap Used: 72MB

Current idle threads: 4
Current total threads: 13
Current busy threads: 9
Current queue size: 0
Max threads: 200
Min threads: 8
Idle Timeout: 60000

  PID USERNAME NLWP PRI NICE  SIZE   RES STATE    TIME   CPU COMMAND
99802 axuser   115   59    0 2037M 1471M sleep  503:46 0.14% java

这怎么可能？top command报告了更多的使用情况。我以为RES应该接近heap-non-heap。

然而，pmap-x报告堆中的大部分内存：

Address     Kbytes       RSS       Anon     Locked Mode   Mapped File
*102000         56         56         56       - rwx----    [ heap ]
*110000       3008       3008       2752       - rwx----    [ heap ]
*400000    1622016    1621056    1167568       - rwx----    [ heap ]
*000000      45056      45056      45056       - rw-----    [ anon ]

谁能解释一下吗？我完全迷路了。

谢谢

使现代化

这似乎不是Linux问题。

此外，根据Peter Lawrey的响应，pmap报告的堆是本机堆，而不是Java堆。

Answer 1

在垃圾回收环境中，抓住未使用的指针相当于“泄漏失败”，并阻止气相色谱完成其工作。很容易意外地将指针保留在周围。

一个常见的罪魁祸首是哈希表。另一个是逻辑上被清除的数组或向量（通过将重用索引设置为0），但数组的实际内容（在使用索引之上）仍然指向某个东西。

Answer 2

我遇到了类似的问题，并找到了解决方案：

Solaris 11
JDK10
REST application using HTTPS (jetty server)
There was a significant increase of c-heap (observed via pmap) over time

我决定用libumem做一些压力测试。所以我从

UMEM_调试=默认UMEM_日志记录=事务LD_预加载=libumem。所以1.

并通过https请求强调应用程序。过了一会儿，我用mdb连接到了流程。在mdb中，我使用了：：findleaks命令，它将此显示为泄漏：

libucrypto.so.1`ucrypto_digest_init

因此，看起来比JCA（Java密码体系结构）实现OracleUcrypto在Solaris上有一些问题。

问题通过更新$JAVA_HOME/conf/Security/java.security文件得到解决-我将OracleUcrypto的优先级更改为3，SUN实现更改为1

security.provider.3=OracleUcrypto
security.provider.2=SunPKCS11 ${java.home}/conf/security/sunpkcs11-solaris.cfg
security.provider.1=SUN

这之后问题就消失了。

这也解释了为什么linux上没有问题-因为JCA提供程序有不同的实现