Java 堆被无法访问的对象淹没

Question

我们的 Java EE 应用程序已经开始出现一些严重的问题。具体来说，应用程序在启动后几分钟内运行了高达 99% 的老年代堆。没有抛出 OOM，但实际上 JVM 没有响应。 jstat 显示老年代的大小根本没有减少，没有进行垃圾收集，并且 kill -3 说:

Heap
 PSYoungGen      total 682688K, used 506415K [0xc1840000, 0xf3840000, 0xf3840000)
  eden space 546176K, 92% used [0xc1840000,0xe06cd020,0xe2da0000)
  from space 136512K, 0% used [0xe2da0000,0xe2da0000,0xeb2f0000)
  to   space 136512K, 0% used [0xeb2f0000,0xeb2f0000,0xf3840000)
 PSOldGen        total 1536000K, used 1535999K [0x63c40000, 0xc1840000, 0xc1840000)
  object space 1536000K, 99% used [0x63c40000,0xc183fff8,0xc1840000)

虚拟机选项是:

-Xmx2300m -Xms2300m -XX:NewSize=800m -XX:MaxNewSize=800m -XX:SurvivorRatio=4 -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseParallelGC -XX:ParallelGCThreads=4 

(我将其从 2300m 堆/1800m 新生成更改为尝试解决问题)

一旦 JVM 进入“内存不足”状态(一直持续)，我对其进行了堆转储并在其上运行 Eclipse 内存分析器。

结果很有趣。大约 200Mb 被各种对象占用(有些比其他对象拥有更多)，但其余的 1.9Gb 都无法访问(可能值得注意的是，大部分被 GSON 对象占用，但我认为不是任何事情的指示，只是说我们在服务器操作期间搅动了很多 GSON 对象)。

任何解释为什么 VM 有这么多无法访问的对象，并且根本无法收集它们？

JVM:

$ /0/bin/java -version
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
Java HotSpot(TM) Server VM (build 20.12-b01, mixed mode)

当系统进入这个停顿状态时，详细的 GC 会继续打印以下内容:

922.485: [GC [1 CMS-initial-mark: 511999K(512000K)] 1952308K(2048000K), 3.9069700 secs] [Times: user=3.91 sys=0.00, real=3.91 secs] 
926.392: [CMS-concurrent-mark-start]
927.401: [Full GC 927.401: [CMS927.779: [CMS-concurrent-mark: 1.215/1.386 secs] [Times: user=5.84 sys=0.13, real=1.38 secs] (concurrent mode failure): 511999K->511999K(512000K), 9.4827600 secs] 2047999K->1957315K(2048000K), [CMS Perm : 115315K->115301K(262144K)], 9.4829860 secs] [Times: user=9.78 sys=0.01, real=9.49 secs] 
937.746: [Full GC 937.746: [CMS: 512000K->511999K(512000K), 8.8891390 secs] 2047999K->1962252K(2048000K), [CMS Perm : 115302K->115302K(262144K)], 8.8893810 secs] [Times: user=8.89 sys=0.01, real=8.89 secs] 

已解决

正如 Paul Bellora 所建议的，这是由于在 JVM 中创建的对象数量过多，在太短的时间内创建的。此时调试变得相当乏味。我最终做的是，使用自定义 JVM 代理来检测类。仪器将计算方法和构造函数调用。然后检查计数。我发现一个不起眼的单个操作会创建大约 200 万个对象，并触发某些单独的方法大约 150 万次(不，没有循环)。与其他操作相比，操作本身很慢。您也可以使用任何热点分析器(例如 visualVM)，但我遇到了各种各样的麻烦，所以最终编写了自己的。

我仍然认为 JVM 的行为是一个谜。看起来垃圾收集器停滞不前，不再清理内存，但内存分配器希望它这样做(因此不会引发 OOM)。相反，我本以为它会清除所有无法访问的内存。但是应用程序的行为也不会好很多，因为无论如何大部分时间都会花在垃圾收集上。

我用来寻求帮助的代理可以在这里找到:https://github.com/veselov/MethodCountAgent .它远不是一款完美的软件。

Answer 1

Any explanation as to why the VM is having so many unreachable objects, and is uncapable of collecting them at all?

(基于我们在评论中的交流)听起来这不是传统的内存泄漏，而是一些逻辑不断向新对象发送垃圾邮件，使得 GC 难以跟上当前架构。

罪魁祸首可能是某些 API 请求被多次发出，或者被“卡”在某种错误状态，例如我描述的无限分页场景。这两种情况都归结为数百万个响应 gson 对象(指向 Strings(指向 char[]s))被实例化，然后符合 GC 条件.

正如我所说，您应该尝试隔离问题请求，然后进行调试并进行测量以确定这是您的应用程序或其库之一的错误或可伸缩性问题。