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将请求重播到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.

不幸的是,我们不直接使用这些类(显然代码使用它们,而不是直接使用),所以我似乎已经死了.

我的问题是

>我无法重现错误
>我无法弄清楚内存泄漏的地方(如果是这样)

有什么想法吗？