我们的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)

VM选项包括：

-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 Memory Analyzer。

结果很有趣。大约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。它远非完美的软件。