Python中文网

一个关于 编程问题的解答网站.

有 Java 编程相关的问题?

你可以在下面搜索框中键入要查询的问题!

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

1 日，16 小时 Questions & Answers

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

本质上，它是一个使用magnolia（cms系统）的网页，在生产环境中有4个实例可用。在java进程中，有时CPU会达到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！）的重新启动服务器上出现在其他内存较少（4GB！）的服务器上重新启动20小时后出现问题运行了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），无论如何，我在本地运行服务器，在打开它之后，我加载了一点并使用了heapdump，我发现了一些有趣的事情：

有很多这样的例子

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

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

我的问题是

  1. 我无法重现这个错误
  2. 我不知道内存到底在哪里泄漏（如果是这样的话）

有什么想法吗


共 (6) 个答案

  1. # 1 楼答案

    • 很多时候，插入JVM的java代理可能会导致“奇怪”错误。如果有任何代理正在运行（例如jrebel/liverebel、newrelic、jprofiler），请先尝试在没有代理的情况下运行
    • 使用非标准参数（-XX）运行JVM时也会发生奇怪的事情；已知某些组合会导致问题；您当前正在使用哪些参数
    • 内存泄漏也可能发生在Magnolia本身，你试过谷歌搜索“Magnolia泄漏”吗？您是否使用任何第三方magnolia模块？如果可能，请尝试禁用/删除它们

    该问题可能只与您的一部分连接。您可以尝试通过在登台/开发服务器上“重放”访问日志来重现该问题

    如果没有别的办法，如果是我，我会做以下事情： -试图在一个“空”的Magnolia实例上复制问题（没有我的任何代码） -试图在一个“空”的Magnolia实例上复制问题（没有第三方模块） -尝试升级所有软件（magnolia、第三方模块、JVM） -最后，试着用你的工具包运行生产现场，并试着找到泄漏

  2. # 2 楼答案

    请尝试一个工具来查找源代码中的漏洞，例如plumbr

  3. # 3 楼答案

    您说您已经试过jvisualvm来检查机器。也许，再试一次，像这样：

    • 这次请查看“采样器->；内存”选项卡

    • 它应该告诉您哪些（类型的）对象占用最多的内存

    • 然后找出这些对象通常在哪里创建和删除

  4. # 4 楼答案

    对于一个困难的调试问题，您需要找到一种方法来重现它。只有这样，你才能测试实验性的变化，并确定它们是使问题变得更好还是更糟。在这种情况下，我会尝试编写快速创建&；删除服务器连接，即创建服务器连接并快速向其发送内存昂贵的请求等

    在可以复制它之后，尝试减小堆大小，看看是否可以更快地复制它。但是要做到这一点，因为一个小堆可能不会达到“GC开销限制”，这意味着GC在尝试恢复内存时花费了过多的时间（某种程度上是98%）

    对于内存泄漏，您需要找出它在代码中积累对对象的引用的位置。例如，它是否构建了所有传入网络请求的映射？ web搜索https://www.google.com/search?q=how+to+debug+java+memory+leaks显示了许多关于如何调试Java内存泄漏的有用文章，包括关于使用您正在使用的Eclipse Memory Analyzer等工具的提示。搜索特定的错误消息https://www.google.com/search?q=GC+overhead+limit+exceeded也很有帮助

    no-opfinalize()方法不应该导致这个问题，但它们很可能会加剧这个问题。finalize()上的文档显示，拥有finalize()方法会迫使GC两次确定实例未被引用（在调用finalize()之前和之后）

    因此，一旦可以重现问题，请尝试删除那些no opfinalize()方法，看看重现问题是否需要更长的时间

    重要的是，内存中有许多AbstractReferenceMap$WeakRef实例。弱引用的要点是引用一个对象而不强迫它留在内存中AbstractReferenceMap是一个映射，它可以使键和/或值成为弱引用或软引用。（软引用的要点是尝试将对象保留在内存中，但在内存不足时让GC释放它。）无论如何，内存中所有这些WeakRef实例都可能加剧问题，但不应将引用的映射键/值保留在内存中。他们指的是什么？还有什么是指这些对象

  5. # 5 楼答案

    有很多可能性，也许你已经探索过其中的一些

    这肯定是某种内存泄漏

    如果您的服务器有用户会话，并且当用户处于非活动状态超过X分钟/小时时，您的用户会话未过期或未被正确处理，则您将获得已用内存的累积

    如果您有一个或多个程序生成的映射，并且您没有清除映射中的旧/不需要的条目，您可能会再次得到已用内存的累积。例如，我曾经考虑添加一个映射来跟踪进程线程，这样用户就可以从每个线程获取信息，直到我的老板指出在任何时候都没有完成从映射中删除的线程，所以如果用户保持登录和活动状态，他们将永远保留这些线程

    您应该尝试在非生产服务器上进行负载测试，模拟大量用户对应用程序的正常使用。甚至可能会将服务器的内存限制得比平时更低

    祝你好运，记忆问题是个很难解决的问题

  6. # 6 楼答案

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

    忠告:

    • 首先去掉无用的finalize()方法

      • 如果你有其他的^ {< CD1>}方法，考虑把它们去掉。（取决于完成工作通常是一个坏主意…）

    • 使用内存探查器尝试识别正在泄漏的对象以及导致泄漏的原因。有很多这样的问题。。。以及其他关于查找Java代码泄漏的资源。例如：

    现在谈谈你的特殊症状

    首先，抛出OutOfMemoryError的位置可能与此无关

    但是，您拥有大量的AbstractReferenceMap$WeakRef和AbstractReferenceMap$ReferenceEntry对象这一事实是一个字符串，表明您的应用程序或它所使用的库中的某些东西正在进行大量缓存。。。而缓存也与问题有关。（类是ApacheCommons集合库的一部分。它是ReferenceMap和ReferenceIdentityMap的超类。）

    您需要跟踪那些WeakRef和ReferenceEntry对象所属的映射对象（或多个对象），以及它们所引用的（目标）对象。然后，您需要弄清楚是什么在创建它/它们，并弄清楚为什么条目没有被清除以响应高内存需求

    • 您是否在其他地方有对目标对象的强引用（这将阻止WeakRefs被破坏）

    • 地图是否使用不当导致泄漏。（仔细阅读javadocs…）

    • 映射是否由多个线程在没有外部同步的情况下使用？这可能导致损坏，可能表现为大规模存储泄漏

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

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

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

    • 当GC需要“中断”一个Reference时，这会产生更多的工作；e、 g.处理参考队列

    • 即使发生这种情况，最早也要到下一个GC周期才能收集得到的不可访问对象

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

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