Java 耗尽内存的未完成对象

我们在AWS上的Tomcat中运行一个基于Jersey（1.x）的服务，在大约20个实例的数组中周期性地运行一个实例“坏掉”：在大约4个小时的过程中，它的堆和CPU使用增加，直到堆耗尽，CPU被固定。在这一点上，它会自动从负载平衡器中删除并最终终止

通过检查这些实例的堆转储，java.lang.ref.Finalizer实例占用了约95%的内存，该实例保存了各种内容，但大部分或全部与HTTPS连接（sun.net.www.protocol.HTTPS.HttpsURLConnectionImpl、sun.security.ssl.SSLSocketImpl、各种加密对象）有关。这些是我们使用Jersey的客户端库与外部Web服务建立的连接。来自“健康”实例的堆转储并不表示存在任何类型的问题

在负载相对较低的情况下，实例可以运行数天或数周而不会出现问题。随着负载的增加，实例失败的频率也会增加（平均CPU达到~40%时，每天会出现几次）

我们的JVM参数是：

-XX:+UseG1GC -XX:MaxPermSize=256m -Xmx1024m -Xms1024m

---

我正在为垃圾收集指标添加JMX日志记录，但我不完全清楚我应该寻找什么。目前，我主要是想知道是什么引发了此类故障，或是寻找其他调查目标。

是否可能是连接泄漏？我想你已经检查过了

---

我也遇到过类似的GC错误问题。根据您的JVM版本，您似乎正在使用一个实验性（并且可能存在错误）功能。您可以尝试禁用G1并使用默认的垃圾收集器。另外，根据您的版本，您可能会遇到垃圾收集开销，因为计算哪些内容可以被丢弃，哪些内容不能被丢弃需要花费很长时间，所以它可能会被丢弃，并且不能正确地处理GC内容。如果JVM中有-XX:-usegcOverdeLimit，它可能会有所帮助。

Java使用单个终结器线程来清理死对象。您的机器的症状与大量积压的定稿一致。如果终结器线程速度太慢（因为某些对象需要很长时间才能完成），则终结器队列条目的累积可能会导致终结器线程越来越落后于传入对象，直到所有对象都停止

---

您可能会发现分析在确定哪些对象正在减慢终结器线程时很有用

这最终证明是由一个JVM错误引起的（不幸的是，我丢失了与我们跟踪到的特定错误的链接）。升级到更新版本的OpenJDK（我们最终使用的是OpenJDK 1.7.0_50）解决了这个问题，我们没有对代码进行任何更改。

可能相关：这显然不是连接泄漏。成堆的健康实例没有显示任何额外连接的迹象；它实际上只是不健康实例中的终结器队列。我们使用的是Java7（OpenJDK1.7.0_25），所以G1是官方支持的，但我不知道是什么让我们选择了它。我们正在运行的其他服务似乎只是使用默认的并行GC，没有问题。这听起来像是在这里发生的事情，我只需要弄清楚是什么引起了问题。到目前为止，我在分析方面还没有取得很多成功，因为我无法在生产环境之外复制故障状态。当我看到一个健康的例子时，没有什么事情是不寻常的，即使是在很重的负载下。