gpt4 book ai didi

java - 无法访问的对象不是从堆中收集的垃圾

转载 作者:塔克拉玛干 更新时间:2023-11-03 02:59:15 34 4
gpt4 key购买 nike

我正在为我的 JVM 堆 (Java 1.7) 中无法访问的对象而苦苦挣扎。从图中可以看出(图中所有类都是不可达的),我们有超过74%的objects没有reference,所以应该是garbagged collected。在我们的 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

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

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)

最佳答案

一种可能是您在 finalize() 方法中使用病态行为使 JVM 过载。如果您有覆盖 Object.finalize() 的类,JVM 必须做大量的工作才能真正清理它们(然后清理所有它们引用的对象)。如果您创建此类对象的速度快于垃圾收集器处理它们的速度,您很快就会遇到麻烦。

本文介绍了 pathological finalizer example详细但总结一下:

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

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

还有其他可能的解释,但过度使用 finalize() 是一个可能的原因。 Effective Java Item 7 strongly discourages finalizers :

Finalizers are unpredictable, often dangerous, and generally unnecessary. Their use can cause erratic behavior, poor performance, and portability problems....

Providing a finalizer for a class can, under rare conditions, arbitrarily delay reclamation of its instances.

关于java - 无法访问的对象不是从堆中收集的垃圾,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25489639/

34 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com