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

我对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.

不幸的是,我们不直接使用这些类(显然代码使用它们,但不是直接使用它们),所以我似乎走到了尽头.

对我来说是个问题

我无法重现错误

我无法弄清楚内存泄漏的地方(如果是这种情况)

有什么想法吗？