本质上是使用木兰(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将请求重播到attemp中的本地服务器以重现错误…它也不起作用.
然后我调查了一些更多的日志找到这个错误
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应该是好的,所以我采取了一个堆转储,不幸的是它太大了打开它(文件是10GB),无论如何,我运行服务器本地加载它一点点,并采取了一个heapdump,打开它后,我发现了一些有趣的东西：
有一个TON的实例
AbstractReferenceMap$WeakRef ==> Takes 21.6% of the memory,9 million instances AbstractReferenceMap$ReferenceEntry ==> Takes 9.6% of the memory,3 million instances
另外,我已经找到一个似乎被用作“缓存”(可怕但真实)的地图,问题是这样的地图不是同步的,而是在线程之间共享(静态的),问题可能不仅仅是并发写入,而且由于缺少同步,不能保证线程A可以看到线程B对地图所做的更改,但是我无法弄清楚如何使用内存eclipse分析器链接这个可疑的映射,因为它不使用AbstracReferenceMap,它只是一个正常的HashMap.
不幸的是,我们不直接使用这些类(显然代码使用它们,而不是直接使用),所以我似乎已经死了.
我的问题是
>我无法重现错误
>我无法弄清楚内存泄漏的地方(如果是这样)
有什么想法吗？
解决方法
建议：
>首先摆脱无用的finalize()方法.
>如果你有其他的finalize()方法,考虑去掉它们. (根据定稿做事情一般是个坏主意…)
>使用内存分析器来尝试识别被泄漏的对象,以及导致泄漏的原因.有很多SO问题…和其他资源查找Java代码泄漏.例如：
> How to find a Java Memory Leak
>使用HotSpot VM,Chapter 3的Java SE 6故障排除指南.
现在你的特殊症状.
首先,OutOfMemoryErrors被抛出的地方可能是无关紧要的.
但是,您有大量AbstractReferenceMap $WeakRef和AbstractReferenceMap $ReferenceEntry对象的事实是一个字符串,表示您的应用程序或其正在使用的库正在执行大量的缓存,而且缓存涉及到问题. (AbstractReferenceMap类是Apache Commons Collections库的一部分,它是ReferenceMap和ReferenceIdentityMap的超类.)
您需要跟踪WeakRef和ReferenceEntry对象所属的地图对象(或对象)以及它们引用的(target)对象.那么你需要弄明白什么是创建它们/他们,并找出为什么条目没有被清除以响应高的内存需求.
>你有强烈的引用其他地方的目标对象(这会阻止WeakRefs被破坏)？
>是/是正在使用的地图不正确,以致导致泄漏. (仔细阅读javadocs …)
>这些地图是否被多个线程使用而无需外部同步？这可能会导致腐败,这可能会导致巨大的存储泄漏.
不幸的是,这些只是理论,也可能是其他的事情.事实上,可以想象,这根本不是内存泄漏.
最后,你的观察结果是当堆更大时问题更糟.对我来说,这与引用/缓存相关的问题仍然是一致的.
>参考对象比常规引用更适用于GC.
>当GC需要“打破”一个引用时,这会创造更多的工作;例如处理参考队列.
>即使发生这种情况,最终在下一个GC周期之前仍然无法收集所得到的不可达对象.
所以我可以看到一个充满参考文献的6Gb堆大大增加了在GC中花费的时间与4Gb堆相比的时间百分比,这可能会导致“GC开销限制”机制提前启动.
但我认为这是一个偶然的症状,而不是根本原因.