Tag: concurrent mark sweep

UseConcMarkSweepGC vs UseParallelGC: 我目前遇到很长时间的垃圾收集问题。请参阅以下内容。我目前的设置是我使用-Xms1g和-Xmx3g。我的应用程序使用的是java 1.4.2。我没有设置任何垃圾收集标志。从它的外观来看，3gb是不够的，我真的有很多垃圾收集的对象。题：我应该改变我的垃圾收集算法吗？我该怎么用？是否更好地使用-XX:+UseParallelGC or -XX:+UseConcMarkSweepGC 或者我应该使用这种组合 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 占用内存的主要是报告数据而不是缓存数据。此外，该机器有16GB的内存，我打算将堆增加到8GB。这两个选项之间有什么区别，因为我仍然觉得很难理解。该机器有多个处理器。我可以拍摄最多5秒，但30至70秒真的很难。谢谢您的帮助。 Line 151493: [14/Jan/2012:11:47:48] WARNING ( 8710): CORE3283: stderr: [GC 1632936K->1020739K(2050552K), 1.2462436 secs] Line 157710: [14/Jan/2012:11:53:38] WARNING ( 8710): CORE3283: stderr: [GC 1670531K->1058755K(2050552K), 1.1555375 secs] Line 163840: [14/Jan/2012:12:00:42] WARNING ( 8710): CORE3283: stderr: [GC […]

Java ConcurrentMarkSweep垃圾收集器不会删除所有垃圾: 简短forms：CMS垃圾收集器似乎未能收集到越来越多的垃圾; 最终，我们的JVM填满了，应用程序变得没有响应。通过外部工具（JConsole或jmap -histo:live ）强制GC清理一次。更新：问题似乎与JConsole的JTop插件有关; 如果我们不运行JConsole，或者在没有JTop插件的情况下运行它，行为就会消失。（技术说明：我们在Linux 2.6.9盒子上运行Sun JDK 1.6.0_07,32位。升级JDK版本并不是一个选择，除非有一个不可避免的主要原因。另外，我们的系统不是连接到可访问Internet的计算机，因此JConsole等的屏幕截图不是一个选项。）我们当前正在运行带有以下标志的JVM： -server -Xms3072m -Xmx3072m -XX:NewSize=512m -XX:MaxNewSize=512m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+DisableExplicitGC 在JConsole中观察内存图，有一个完整的GC，在我们的应用程序生命周期的前几个小时内每隔约15分钟运行一次; 在每个完整的GC之后，仍然有越来越多的内存在使用中。几个小时后，系统达到稳定状态，CMS旧版中大约有2GB的已用内存。这听起来像是经典的内存泄漏，除非我们使用任何强制完整GC的工具（点击JConsole中的“收集垃圾”按钮，或运行jmap -histo:live等），旧版本突然降至~500MB使用，我们的应用程序在接下来的几个小时内再次响应（在此期间相同的模式继续 – 在每个完整的GC之后，越来越多的旧版本已经满了。）需要注意的一点是：在JConsole中，报告的ConcurrentMarkSweep GC计数将保持为0，直到我们使用jconsole / jmap / etc强制GC。使用jmap -histo和jmap -histo:live按顺序生成，我能够确定明显未收集的对象包括：几百万个HashMap和HashMap$Entry数组（比例为1：1）数百万个Vector和对象数组（1：1的比例，与HashMaps的数量大致相同）几百万个HashSet ， Hashtable和com.sun.jmx.remote.util.OrderClassLoader ，以及Hashtable$Entry数组（大约相同数量的每个;大约是HashMaps和Vectors的一半）下面的GC输出有一些摘录; 我对它们的解释似乎是CMS GC在没有故障转移到世界末日GC的情况下中止。我是否以某种方式误解了这个输出？有什么东西会导致这种情况吗？在正常运行时期间，CMS GC输出块看起来像这样： 36301.827: […]

Concurrent Mark Sweep（CMS）是否能阻止世界事件？: 我看到许多类的卸载，我的整个系统将在这段时间内挂起.. [Unloading class sun.reflect.GeneratedMethodAccessor117] [Unloading class sun.reflect.GeneratedConstructorAccessor1896] [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor485] [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor579] …. // about 1700 of them 同时我没有看到烫发空间的峰值，所以它似乎不是GC事件。我想知道以下内容 IS Concurrent Mark Sweep收集了一个停止世界事件？即使烫发空间不满也会发生吗？

CMS垃圾收集器 – 什么时候运行？: 我很困惑可能控制CMS收集器何时启动的两个参数： MaxHeapFreeRatio （默认为70％） CMSInitiatingOccupancyFraction （默认超过90％）这些参数对每个参数意味着什么？收集器何时开始（标记阶段），并收集（扫描阶段）？