Java垃圾收集器和内存的问题

Question

我对Java应用程序有一个非常奇怪的问题.

基本上它是一个使用玉兰(一个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)

然后我发现这样的问题是由于垃圾收集器使用了大量的CPU但却无法释放大量内存

好吧,所以MEMORY的一个问题在CPU中表现出来,所以如果内存使用问题解决了,那么CPU应该没问题,所以我拿了一个堆转换,不幸的是它太大了打开它(文件是10GB),无论如何我运行服务器本地加载它一点点并采取了堆转储,打开后,我发现了一些有趣的东西:

有一个TON的实例

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

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

建议:

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

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

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

  • 如何找到Java内存泄漏
  • 带有HotSpot VM的Java SE 6故障排除指南,第3章.

现在你的特殊症状.

首先,OutOfMemoryError抛出s 的地方可能无关紧要.

然而,事实上,你有庞大的数字AbstractReferenceMap$WeakRef和AbstractReferenceMap$ReferenceEntry对象是一个字符串表示的东西在你的应用程序或它使用的库是做了巨大的缓存量......这是缓存中存在的问题有关.(该AbstractReferenceMap类是Apache共享类别库的一部分.它是超类ReferenceMap和ReferenceIdentityMap).

您需要跟踪这些WeakRef和ReferenceEntry对象所属的地图对象(或对象)以及它们引用的(目标)对象.然后你需要找出创建它/它们的原因,并找出为什么条目没有被清除以响应高内存需求.

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

• 是否正在使用错误的地图以导致泄漏.(仔细阅读javadocs ......)

• 多个线程是否使用了地图而没有外部同步？这可能导致腐败,这可能表现为大规模存储泄漏.

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

最后,你观察到当堆更大时问题更严重.对我来说,这仍然与Reference/ cache相关的问题一致.

• Reference 对象比GC常规引用更有效.

• 当GC需要"打破"a Reference时,会产生更多的工作; 例如,处理参考队列.

• 即使发生这种情况,最早到下一个GC循环之前仍然无法收集生成的无法到达的对象.

所以我可以看到一个充满引用的6Gb堆将如何显着增加GC中所花费的时间百分比......与4Gb堆相比,这可能会导致"GC Overhead Limit"机制提前启动.

但我认为这是一个偶然的症状,而不是根本原因.