我们的 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 进入“内存不足”状态（持续很长时间），我就对 JVM 进行堆转储，并在其上运行 Eclipse Memory Analyzer。
结果很有趣。大约 200Mb 被各种对象占用（有些对象比其他对象拥有更多），但其余的 1.9Gb 都是无法访问的（可能值得注意的是，大部分被 GSON 对象占用，但我不认为这是任何事情的指示，只是说我们在服务器操作期间搅动了大量 GSON 对象）。
有什么解释可以解释为什么虚拟机有这么多无法访问的对象，并且根本无法收集它们吗？
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]
SOLVED
正如 Paul Bellora 所言，这是由于在太短的时间内在 JVM 中创建的对象数量过多造成的。此时调试变得相当乏味。我最终所做的是，使用自定义 JVM 代理来检测类。该检测将对方法和构造函数调用进行计数。然后检查计数。我发现一个不起眼的单个操作会创建大约 200 万个对象，并触发某些单独的方法大约 150 万次（不，没有循环）。与其他操作相比，该操作本身的速度较慢。您也可以使用任何热点分析器（例如 VisualVM），但我在这些方面遇到了各种麻烦，所以最终编写了自己的热点分析器。
我仍然认为 JVM 的行为是一个谜。看起来垃圾收集器陷入停滞，并且不会再清理任何内存，但内存分配器希望它这样做（因此不会抛出 OOM）。相反，我希望它能够清除所有无法访问的内存。但应用程序的行为也不会好多少，因为无论如何大部分时间都会花在垃圾收集上。
我用来寻求帮助的代理可以在这里找到：https://github.com/veselov/MethodCountAgent https://github.com/veselov/MethodCountAgent。它距离一个完美的软件还很远。
