无法从堆中收集无法访问的对象

我正在努力解决 JVM 堆（Java 1.7）中无法访问的对象。从图中可以看到（图中所有类都是不可达的），我们有超过74%的对象没有引用，所以应该被垃圾收集。在我们的 tomcat 7 服务器上运行 3 周后就会出现这种状态，该服务器仅运行 Probe 监控应用程序、tomcat 管理器和我们的 web 应用程序，这可能是问题的根源。

我们的应用程序基于 JSF 1.2，在客户端上保存状态，如下图所示 - 主要是带有 ViewSaveState 的字符数组。 当我从 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

OutOfMemoryError 的堆栈跟踪

我认为这个原因隐藏在其他地方，堆栈跟踪来自应用程序的不同部分。可能存在一些泄漏，但堆栈跟踪仅报告最后一个组件，该组件在没有内存的情况下及时声明了一些内存。

    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)

一种可能性是，您正在使 JVM 超载，并出现以下病态行为：finalize()方法。如果您有覆盖的类Object.finalize()JVM 必须做大量的工作才能真正清理它们（进而清理它们引用的所有对象）。如果您创建此类对象的速度快于垃圾收集器处理它们的速度，您很快就会遇到麻烦。

本文将介绍一个病理终结器示例 http://www.fasterj.com/articles/finalizer2.shtml详细，但总结一下：

1. 一个物体有一个finalize()方法超出范围并且（概念上）符合 GC 的条件。
2. 与可以简单地释放的普通对象不同，JVM 通过一个对象持有一个特殊的引用Finalizer http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/lang/ref/Finalizer.java，防止这些对象被轻易收集。即使是寿命较短的对象，也会在初始 GC 后存活下来，如果与某个对象关联，则会移至堆中寿命较长的部分。finalize().
3. 现在这些对象将由专用的处理Finalizer线程，它将调用.finalize()依次作用于每个对象。尚未轮到的对象仍保留在堆中，尽管它们无法访问。
4. 一旦对象被处理Finalizerthread 最后一个引用被删除，对象最终可以被 GC 回收。由于该对象在一轮或多轮收集中幸存下来，因此 GC 可能需要一些时间才能处理它。
5. 可终结对象依次引用的任何对象现在才符合收集条件。

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

还有其他可能的解释，但过度使用finalize()是一个可能的原因。:

终结器是不可预测的，通常很危险，而且通常是不必要的。它们的使用可能会导致行为不稳定、性能不佳和可移植性问题......

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