无法访问的对象不会从堆中垃圾回收

我正在与JVM堆(Java 1.7)中无法访问的对象作斗争。从图片中可以看出(图片上的所有类都无法访问),我们有超过74%的对象没有引用,因此应该将其收集起来。这种状态在我们的tomcat 7服务器上运行3周后变为仅运行探针监视应用程序,tomcat管理器和我们的web应用程序,这可能是问题的根源。

我们的应用程序基于JSF 1.2,在客户端上保存状态,如下图所示 - 主要使用ViewSaveState的char数组。当我从jVisualVM手动运行GC时,它会删除所有无法访问的对象,并且一切正常,直到3周堆达到其限制。

为什么某些对象没有被清理?

我们的 JVM 参数

-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=29001
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=
-Dorg.apache.el.parser.SKIP_IDENTIFIER_CHECK=true
-Xms320m
-Xmx2500m
-XX:MaxPermSize=500m
-XX:PermSize=96m
-verbose:gc
-Xloggc:/var/log/gc.log
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-Xdebug -Xrunjdwp:transport=dt_socket,address=1044,server=y,suspend=n
-XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC

http://puu.sh/b7mjB/3d23de7d41.png

堆栈跟踪以超出内存错误

我认为这个原因是隐藏在其他地方,堆栈跟踪来自应用程序的不同部分。可能会有一些泄漏,但堆栈跟踪只报告最后一个组件,当没有任何内存时,它会及时声明一些内存。

    java.lang.OutOfMemoryError: Java heap space
            at java.util.LinkedHashMap.createEntry(LinkedHashMap.java:442)
            at java.util.HashMap.addEntry(HashMap.java:888)
            at java.util.LinkedHashMap.addEntry(LinkedHashMap.java:427)
            at java.util.HashMap.put(HashMap.java:509)
            at sun.util.resources.OpenListResourceBundle.loadLookup(OpenListResourceBundle.java:134)
            at sun.util.resources.OpenListResourceBundle.loadLookupTablesIfNecessary(OpenListResourceBundle.java:113)
            at sun.util.resources.OpenListResourceBundle.handleGetObject(OpenListResourceBundle.java:74)
            at sun.util.resources.TimeZoneNamesBundle.handleGetObject(TimeZoneNamesBundle.java:75)
            at java.util.ResourceBundle.getObject(ResourceBundle.java:389)
            at java.util.ResourceBundle.getObject(ResourceBundle.java:392)
------------------
Exception in thread "Timer-22" Exception in thread "com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2" java.lang.OutOfMemoryError: Java heap space
Exception in thread "com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1" java.lang.OutOfMemoryError: Java heap space
------------------
Caused by: java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Arrays.java:2219)
        at java.util.ArrayList.grow(ArrayList.java:242)
        at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:216)
        at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:208)
        at java.util.ArrayList.add(ArrayList.java:440)
        at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1468)
        at org.hibernate.loader.Loader.getRow(Loader.java:1355)
        at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:611)
        at org.hibernate.loader.Loader.doQuery(Loader.java:829)
        at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
         at org.ajax4jsf.component.AjaxActionComponent.broadcast(AjaxActionComponent.java:55)
        at org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:329)
        at org.ajax4jsf.component.AjaxViewRoot.broadcastEventsForPhase(AjaxViewRoot.java:304)
        at org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:261)
        at org.ajax4jsf.component.AjaxViewRoot.processApplication(AjaxViewRoot.java:474)
        at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32)
        at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:183)
        ... 74 more
--------------
Caused by: java.lang.OutOfMemoryError: Java heap space
        at java.nio.ByteBuffer.wrap(ByteBuffer.java:350)
        at java.lang.StringCoding$StringDecoder.decode(StringCoding.java:137)
        at java.lang.StringCoding.decode(StringCoding.java:173)
        at java.lang.String.<init>(String.java:443)
        at com.ibm.db2.jcc.a.a.a(a.java:632)
        at com.ibm.db2.jcc.a.a.a(a.java:355)
        at com.ibm.db2.jcc.am.fc.e(fc.java:682)
        at com.ibm.db2.jcc.am.fc.k(fc.java:1481)
        at com.ibm.db2.jcc.am.ResultSet.getTimestampX(ResultSet.java:1075)
        at com.ibm.db2.jcc.am.ResultSet.getTimestamp(ResultSet.java:1034)

答案 1

一种可能性是,您正在用方法中的病理行为重载 JVM。如果你有重写JVM的类,为了实际清理它们(反过来,清理它们的所有引用对象),必须做大量的工作。如果您创建此类对象的速度比垃圾回收器处理它们的速度快,则很快就会遇到麻烦。finalize()Object.finalize()

本文详细介绍了一个病理终结器示例,但要总结一下:

  1. 具有方法的对象超出范围,并且(从概念上讲)有资格获得 GC。finalize()
  2. 与可以简单地释放的普通对象不同,JVM通过Finginer持有对对象的特殊引用,防止这些对象被平凡地收集。即使是短期对象也能在初始 GC 中存活下来,如果与 关联,则会移动到堆中生存期较长的部分。finalize()
  3. 现在,这些对象将由专用线程处理,该线程将依次调用每个对象。尚未轮到的对象仍保留在堆上,尽管它们无法访问。Finalizer.finalize()
  4. 一旦对象被线程处理,最后一个引用就会被删除,对象最终可以实际被GC'ed。由于对象在一个或多个集合轮中幸存下来,因此 GC 可能需要一些时间才能绕过它。Finalizer
  5. 可最终确定对象依次引用的任何对象现在才有资格收集。

如果您的方法需要特别长的时间,或者您正在创建大量此类对象,则线程无法跟上需求,对象将继续排队,最终填满整个堆。.finalize()Finalizer

还有其他可能的解释,但过度使用是一个可能的原因。有效的 Java Item 7 强烈反对终结器finalize()

终结器是不可预测的,通常是危险的,并且通常是不必要的。它们的使用可能会导致行为不稳定,性能不佳和便携性问题。

在极少数情况下,为类提供终结器可能会任意延迟其实例的回收。


答案 2

这个问题可能与这个问题有关

Java 堆被无法访问的对象淹没

我发现它,因为我在AIX 6.1上的IBM JVM 5 runninf中遇到了同样的问题

在两个 fullgcs 之间持续增长的唯一保留堆数量是无法访问的对象,如果我没有记错的话,在 Eclipse MAT 中以 ROOT 作为支配者。

为了获得这些转储,我将JVM配置为使用Xdump选项在fullgc之后创建一个系统转储(我认为仅适用于IBM JVM)。

希望这有帮助,如果有人知道GC详细日志是否留下了无法清理的无法访问对象的痕迹,请告诉我!

卡洛斯


推荐