Java CMS 垃圾收集器 - 它何时运行？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/9697754/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
CMS garbage collector - when does it run?
提问by Konrad Garus
I am confused about two parameters that may control when the CMS collector kicks in:
我对 CMS 收集器启动时可能控制的两个参数感到困惑：
MaxHeapFreeRatio(70% by default)
MaxHeapFreeRatio（默认 70%）
CMSInitiatingOccupancyFraction(over 90% by default)
CMSInitiatingOccupancyFraction（默认超过 90%）
What does each of those parameters mean, exactly? When does the collector start (the marking phase), and collect (the sweeping phase)?
这些参数中的每一个究竟是什么意思？收集器何时开始（标记阶段）和收集（清扫阶段）？
采纳答案by moodywoody
CMSInitiatingOccupancyFractiondecides when the CMS kicks in (in order for this option to be effective you must also set -XX:+UseCMSInitiatingOccupancyOnly). MaxHeapFreeRatiois an option to size the generational spaces.
CMSInitiatingOccupancyFraction决定 CMS 何时启动（为了使此选项有效，您还必须设置-XX:+UseCMSInitiatingOccupancyOnly）。MaxHeapFreeRatio是调整代空间大小的选项。
See for example ...
参见例如...
http://java.sun.com/docs/hotspot/gc1.4.2/faq.html
http://java.sun.com/docs/hotspot/gc1.4.2/faq.html
The concurrent collection generally cannot be sped up but it can be started earlier. A concurrent collection starts running when the percentage of allocated space in the old generation crosses a threshold. This threshold is calculated based on general experience with the concurrent collector. If full collections are occurring, the concurrent collections may need to be started earlier. The command line flag CMSInitiatingOccupancyFraction can be used to set the level at which the collection is started. Its default value is approximately 68%. The command line to adjust the value is
-XX:CMSInitiatingOccupancyFraction=<percent>
并发收集通常无法加速，但可以提前启动。当老年代中分配的空间百分比超过阈值时，并发收集开始运行。该阈值是根据并发收集器的一般经验计算得出的。如果正在发生完整收集，则可能需要更早启动并发收集。命令行标志 CMSInitiatingOccupancyFraction 可用于设置开始收集的级别。其默认值约为 68%。调整值的命令行是
-XX:CMSInitiatingOccupancyFraction=<percent>
http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html
http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html
By default, the virtual machine grows or shrinks the heap at each collection to try to keep the proportion of free space to live objects at each collection within a specific range. This target range is set as a percentage by the parameters
-XX:MinHeapFreeRatio=<minimum>and-XX:MaxHeapFreeRatio=<maximum>, and the total size is bounded below by-Xmsand above by-Xmx.
默认情况下，虚拟机在每个集合处增加或缩小堆，以尝试将每个集合处的可用空间与活动对象的比例保持在特定范围内。此目标范围由参数
-XX:MinHeapFreeRatio=<minimum>和设置为百分比-XX:MaxHeapFreeRatio=<maximum>，总大小由-Xms和 上下限定-Xmx。
.. or ..
.. 或者 ..
http://www.petefreitag.com/articles/gctuning/
http://www.petefreitag.com/articles/gctuning/
-XX:MaxHeapFreeRatio- when the percentage of free space in a generation exceeded this value the generation will shrink to meet this value. Default is 70
-XX:MaxHeapFreeRatio- 当一代中的可用空间百分比超过此值时，该代将收缩以达到此值。默认值为 70
EDIT : I ran a few simulations with a test program that just randomly creates maps of byte arrays and copies them around. I noticed that a) fraction value was not respected - in particular with a conservative value (say 50) the CMS initial mark stage kicked in much beyond 50% occupancy, typically around 70-80% and b) nonetheless smaller fraction values made the CMS initial stage happen earlier
(program used -Xmx1536m -Xmx1536m -XX:NewSize=512m -XX:+UseConcMarkSweepGc+ gc logging and the two test parameters)
编辑：我用一个测试程序运行了一些模拟，该程序只是随机创建字节数组的映射并将它们复制。我注意到 a) 分数值没有得到尊重 - 特别是在保守值（比如 50）的情况下，CMS 初始标记阶段的占用率远远超过 50%，通常约为 70-80% 和 b）尽管如此，较小的分数值使 CMS初始阶段发生得更早（程序使用-Xmx1536m -Xmx1536m -XX:NewSize=512m -XX:+UseConcMarkSweepGc+ gc 日志记录和两个测试参数）
I've also found an old bug report regarding this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486089
我还发现了一个关于此的旧错误报告：http: //bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486089
