java - Java垃圾收集器和内存问题

Question

我的 Java 应用程序遇到了一个非常奇怪的问题。

本质上它是一个使用 magnolia(一个 cms 系统)的网页，生产环境中有 4 个实例可用。有时 CPU 在 Java 进程中达到 100%。

所以，第一种方法是进行线程转储，并检查有问题的线程，我发现很奇怪:

"GC task thread#0 (ParallelGC)" prio=10 tid=0x000000000ce37800 nid=0x7dcb runnable 
"GC task thread#1 (ParallelGC)" prio=10 tid=0x000000000ce39000 nid=0x7dcc runnable 

好吧，这很奇怪，我从来没有遇到过这样的垃圾收集器问题，所以我们接下来要做的是激活 JMX 并使用 jvisualvm 检查机器:堆内存使用率非常高(95% )。

幼稚的方法:增加内存，因此问题需要更多时间才能出现，结果，在重新启动的内存增加的服务器上(6 GB!)问题出现在重新启动后 20 小时，而在其他内存较少的服务器上(4GB!)已经运行了10天，问题仍然需要几天才能再次出现。另外，我尝试使用服务器失败的 apache 访问日志，并使用 JMeter 将请求重播到本地服务器中，以尝试重现错误......它也不起作用。

然后我稍微调查了一下日志以发现这个错误

info.magnolia.module.data.importer.ImportException: Error while importing with handler [brightcoveplaylist]:GC overhead limit exceeded
at info.magnolia.module.data.importer.ImportHandler.execute(ImportHandler.java:464)
at info.magnolia.module.data.commands.ImportCommand.execute(ImportCommand.java:83)
at info.magnolia.commands.MgnlCommand.executePooledOrSynchronized(MgnlCommand.java:174)
at info.magnolia.commands.MgnlCommand.execute(MgnlCommand.java:161)
at info.magnolia.module.scheduler.CommandJob.execute(CommandJob.java:91)
at org.quartz.core.JobRunShell.run(JobRunShell.java:216)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)
    Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded

另一个例子

    Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
    at java.util.Arrays.copyOf(Arrays.java:2894)
    at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:117)
    at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:407)
    at java.lang.StringBuilder.append(StringBuilder.java:136)
    at java.lang.StackTraceElement.toString(StackTraceElement.java:175)
    at java.lang.String.valueOf(String.java:2838)
    at java.lang.StringBuilder.append(StringBuilder.java:132)
    at java.lang.Throwable.printStackTrace(Throwable.java:529)
    at org.apache.log4j.DefaultThrowableRenderer.render(DefaultThrowableRenderer.java:60)
    at org.apache.log4j.spi.ThrowableInformation.getThrowableStrRep(ThrowableInformation.java:87)
    at org.apache.log4j.spi.LoggingEvent.getThrowableStrRep(LoggingEvent.java:413)
    at org.apache.log4j.AsyncAppender.append(AsyncAppender.java:162)
    at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
    at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
    at org.apache.log4j.Category.callAppenders(Category.java:206)
    at org.apache.log4j.Category.forcedLog(Category.java:391)
    at org.apache.log4j.Category.log(Category.java:856)
    at org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:576)
    at info.magnolia.module.templatingkit.functions.STKTemplatingFunctions.getReferencedContent(STKTemplatingFunctions.java:417)
    at info.magnolia.module.templatingkit.templates.components.InternalLinkModel.getLinkNode(InternalLinkModel.java:90)
    at info.magnolia.module.templatingkit.templates.components.InternalLinkModel.getLink(InternalLinkModel.java:66)
    at sun.reflect.GeneratedMethodAccessor174.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:622)
    at freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:866)
    at freemarker.ext.beans.BeanModel.invokeThroughDescriptor(BeanModel.java:277)
    at freemarker.ext.beans.BeanModel.get(BeanModel.java:184)
    at freemarker.core.Dot._getAsTemplateModel(Dot.java:76)
    at freemarker.core.Expression.getAsTemplateModel(Expression.java:89)
    at freemarker.core.BuiltIn$existsBI._getAsTemplateModel(BuiltIn.java:709)
    at freemarker.core.BuiltIn$existsBI.isTrue(BuiltIn.java:720)
    at freemarker.core.OrExpression.isTrue(OrExpression.java:68)

然后我发现such problem is due to the garbage collector using a ton of CPU but not able to free much memory

好的，原来是内存有问题，表现在CPU上，所以如果内存使用问题解决了，那么CPU应该没问题，所以我拿了一个heapdump，可惜它太大而无法打开它(文件是10GB)，无论如何我在本地运行服务器m加载了一点并进行了堆转储，打开它后，我发现了一些有趣的东西:

有很多

的实例

AbstractReferenceMap$WeakRef  ==> Takes 21.6% of the memory, 9 million instances
AbstractReferenceMap$ReferenceEntry  ==> Takes 9.6% of the memory, 3 million instances

此外，我发现了一个似乎被用作“缓存”的 Map(可怕但真实)，问题是这样的映射不同步并且它在线程之间共享(是静态的)，问题可能是不仅是并发写入，而且由于缺乏同步，无法保证线程 A 会看到线程 B 对映射所做的更改，但是，我无法弄清楚如何使用内存 eclipse 分析器，因为它不使用AbstracReferenceMap，它只是一个普通的HashMap。

不幸的是，我们不直接使用这些类(显然代码使用它们，但不是直接使用)，所以我似乎走到了死胡同。

我的问题是

1. 我无法重现错误
2. 我无法弄清楚内存到底在哪里泄漏(如果是这样的话)

有什么想法吗？

Answer 1

'no-op' finalize() 方法绝对应该被删除，因为它们可能会使任何 GC 性能问题变得更糟。但我怀疑您还有其他内存泄漏问题。

建议:

• 首先摆脱无用的finalize()方法。

• 如果您有其他 finalize() 方法，请考虑摆脱它们。 (根据最终确定做事通常是个坏主意...)

• 使用内存分析器尝试识别正在泄漏的对象，以及导致泄漏的原因。有很多 SO Questions ... 和其他有关查找 Java 代码泄漏的资源。例如:

  • How to find a Java Memory Leak
  • 带有 HotSpot VM 的 Java SE 6 故障排除指南，Chapter 3 .

---

现在说说你的特殊症状。

首先，OutOfMemoryError 被抛出的地方可能无关紧要。

但是，您拥有大量 AbstractReferenceMap$WeakRef 和 AbstractReferenceMap$ReferenceEntry 对象的事实是一个字符串，表明您的应用程序或它正在使用的库中的某些内容正在做大量的缓存......并且该缓存与问题有关。 (AbstractReferenceMap 类是 Apache Commons Collections 库的一部分。它是 ReferenceMap 和 ReferenceIdentityMap 的父类(super class)。)

您需要追踪那些 WeakRef 和 ReferenceEntry 对象所属的 map 对象(或多个对象)，以及它们所引用的(目标)对象。然后你需要弄清楚是什么创建了它/它们，并弄清楚为什么没有清除条目以响应高内存需求。

• 您是否对其他地方的目标对象有强引用(这会阻止 WeakRefs 被破坏)？

• 是/是 map 使用不当导致泄漏。 (仔细阅读 javadocs ...)

• 映射是否被多个线程使用而没有外部同步？这可能会导致损坏，这可能表现为大量存储泄漏。

---

不幸的是，这些只是理论，可能还有其他原因导致这种情况。事实上，可以想象这根本不是内存泄漏。

---

最后，您观察到堆越大问题越严重。对我来说，这仍然与 Reference/缓存相关问题一致。

• Reference 对象比常规引用更适合 GC。

• 当 GC 需要“破坏”一个 Reference 时，会产生更多的工作；例如处理引用队列。

• 即使发生这种情况，产生的不可达对象最早也要等到下一个 GC 周期才能被收集。

所以我可以看到一个充满引用的 6Gb 堆将如何显着增加在 GC 中花费的时间百分比......与 4Gb 堆相比，这可能导致“GC 开销限制”机制更早启动。

但我认为这是偶然的症状，而不是根本原因。