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

28 浏览
0 Comments

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

我遇到了一个非常奇怪的Java应用程序问题。\n基本上，它是一个使用magnolia（一个CMS系统）的网页，在生产环境中有4个实例。有时候CPU会占用到100%的Java进程。\n首先，我们进行了线程转储，并检查了有问题的线程，发现了奇怪的情况：\n

"GC task thread#0 (ParallelGC)" prio=10 tid=0x000000000ce37800 nid=0x7dcb runnable 
"GC task thread#1 (ParallelGC)" prio=10 tid=0x000000000ce39000 nid=0x7dcc runnable

\n好吧，这非常奇怪，我从来没有遇到过这样的垃圾收集器问题，所以我们接下来的做法是激活JMX，并使用jvisualvm检查机器：堆内存使用率非常高（95%）。\n天真的方法：增加内存，以便问题出现的时间更长，结果是，在增加内存的重新启动服务器上（6GB！），问题在重新启动后的20小时后出现，而在其他内存较小的服务器（4GB！）上，问题需要更多的时间才会再次出现，这些服务器已经运行了10天。此外，我还尝试使用失败的服务器的Apache访问日志，并使用JMeter将请求重放到本地服务器，以尝试重现错误...但也没有成功。\n然后我进一步调查日志，发现了这些错误：\n

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

\n另一个例子\n

    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)

\n然后我发现，这种问题是由于垃圾收集器使用大量CPU但无法释放足够内存所导致的。\n好吧，所以这是一个与内存有关的问题，而在CPU上表现出来。所以，如果内存使用问题解决了，那么CPU应该没问题。于是我拍了一个堆转储，不幸的是它太大了，无法打开（文件大小为10GB），无论如何，我在本地运行服务器加载了一些数据并拍了一个堆转储，在打开它后，我发现了一些有趣的东西：\n有大量的这样的实例：\n

AbstractReferenceMap$WeakRef  ==> 占用21.6%的内存，900万个实例
AbstractReferenceMap$ReferenceEntry  ==> 占用9.6%的内存，300万个实例

\n此外，我还发现了一个被用作“缓存”的Map（可怕但是事实），问题在于这个Map没有同步，并且在线程之间是共享的（静态的），问题可能不仅是并发写入，而且还因为缺乏同步，线程A无法看到线程B对该Map所做的更改，然而，我无法弄清楚如何使用内存Eclipse分析器来链接这个可疑的Map，因为它没有使用AbstracReferenceMap，它只是一个普通的HashMap。\n不幸的是，我们并不直接使用这些类（显然代码中使用了它们，但不是直接使用），所以我似乎陷入了死胡同。\n对我来说的问题是：\n

    \n

  1. 我无法重现这个错误

    2. \n

  2. 我无法弄清楚内存泄漏（如果有的话）到底在哪里

    3. \n

\n有什么想法吗？

0

3 答案

0 Comments

Java垃圾收集器和内存问题

Java垃圾收集器和内存问题是Java开发中经常遇到的一个问题。下面将介绍这个问题的出现原因以及解决方法。

出现原因：

1. 内存泄漏：Java垃圾收集器无法及时回收不再使用的对象，导致内存占用不断增加。

2. 内存碎片化：Java垃圾收集器在回收内存时可能会导致内存碎片化，进而影响程序的性能和效率。

解决方法：

1. 使用工具：可以尝试使用一些工具来定位源代码中的内存泄漏问题，比如plumbr。这些工具可以帮助开发者找出源代码中的内存泄漏点，并提供相应的解决方案。

2. 手动释放资源：在代码中，可以使用手动释放资源的方式来解决内存泄漏问题。例如，显式地调用对象的close()方法来释放资源，或者使用try-finally块确保资源在使用后被正确释放。

3. 优化代码逻辑：优化代码逻辑可以减少不必要的内存占用和对象创建，从而减少Java垃圾收集器的压力。例如，使用缓存技术来重复利用对象，避免频繁的对象创建和销毁。

4. 调整垃圾收集器参数：可以根据具体情况调整垃圾收集器的参数，以提高其性能和效率。例如，调整垃圾收集器的堆大小、新生代和老年代的比例等。

Java垃圾收集器和内存问题是Java开发中常见的问题，可能导致内存泄漏和内存碎片化。通过使用工具定位内存泄漏点、手动释放资源、优化代码逻辑和调整垃圾收集器参数等方法，可以有效地解决这些问题，提高程序的性能和效率。

0
0 Comments

Java垃圾回收器和内存存在的问题及解决方法

在解决一个困难的调试问题时，你需要找到一种复现问题的方法。只有这样，你才能测试实验性的更改，并确定它们是否能够改善或恶化问题。在这种情况下，我会尝试编写循环，快速创建和删除服务器连接，创建一个服务器连接并快速发送内存密集型请求等等。

一旦你能够复现问题，尝试减小堆大小，看看是否能够更快地复现问题。但是要将这个步骤放在第二位，因为小堆可能不会触发"GC overhead limit"错误，这意味着垃圾回收器花费过多的时间（按某种度量标准达到98%）来回收内存。

对于内存泄漏，你需要找出代码中积累对象引用的位置。例如，它是否构建了一个包含所有传入网络请求的Map？

通过网页搜索可以找到许多有用的文章，介绍如何调试Java内存泄漏，包括使用像你正在使用的Eclipse Memory Analyzer工具的技巧。搜索特定的错误信息"GC overhead limit exceeded"也会很有帮助。

空操作的finalize()方法不应该引起这个问题，但它们可能会加剧问题。在finalize()方法的文档中可以看到，拥有finalize()方法会强制垃圾回收器在调用finalize()之前和之后两次确定实例无引用。

因此，一旦能够复现问题，尝试删除那些空操作的finalize()方法，看看问题是否需要更长时间才能复现。

重要的是，内存中有许多AbstractReferenceMap$WeakRef实例。弱引用的目的是引用一个对象而不强制将其保留在内存中。AbstractReferenceMap是一个允许键和/或值为弱引用或软引用的Map。（软引用的目的是在内存不足时尽量保持对象在内存中，但让垃圾回收器在需要时释放它。）无论如何，所有这些内存中的WeakRef实例可能会加剧问题，但不应该保留引用的Map键/值在内存中。它们引用的是什么？还有什么引用这些对象？

+1 引用的这句话："With a difficult debugging problem, you need to find a way to reproduce it. Only then will you be able to test experimental changes and determine if they make the problem better or worse."

0
0 Comments

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

Java垃圾回收器和内存的问题可能出现的原因和解决方法如下：

首先，应该删除无用的finalize()方法，因为它们可能会加重任何垃圾回收性能问题。如果还有其他finalize()方法，也考虑将其删除。使用内存分析器来尝试识别泄漏的对象以及导致泄漏的原因。

其次，根据问题的特点，大量的AbstractReferenceMap$WeakRef和AbstractReferenceMap$ReferenceEntry对象表明应用程序或使用的库正在进行大量的缓存操作，并且这些缓存操作与问题有关。需要跟踪这些WeakRef和ReferenceEntry对象所属的映射对象以及它们所引用的目标对象。然后需要找出是什么导致了这种情况以及为什么这些条目没有在内存需求高时被清除。

最后，问题在堆越大时变得更糟的观察结果与引用/缓存相关的问题一致。Reference对象对于垃圾收集器来说比普通引用更耗费资源。当垃圾收集器需要“破坏”一个Reference对象时，会产生更多的工作，例如处理Reference队列。即使发生这种情况，结果不可达的对象也不能在下一次垃圾收集周期之前被回收。

以上是关于Java垃圾回收器和内存问题的一些可能原因和解决方法。请注意，这些只是理论，还可能有其他问题导致这种情况。

0