我有一个关于 ClassUnloadingWithConcurrentMark 标志的问题，因为我在任何地方都没有找到任何有用的帮助。如果我们使用G1GC则默认设置为true(-XX:+ClassUnloadingWithConcurrentMark)。如果我使用 -XX:-ClassUnloadingWithConcurrentMark 标志在 G1 并发标记之后关闭类卸载，那么类卸载在哪里执行(哪个阶段)？我在某处读到，当完全GC被激活时会发生这种情况，如果完全GC从未被触发怎么办？我在备注阶段遇到问题 - 下面示例中的卸载花费了超过 3 秒的时间:
2015-06-08T08:09:16.318+0200: 572818.729: [GC remark 572818.729: [Finalize Marking, 0.0002590 secs] 572818.729: [GC ref-proc, 0.4479462 secs] 572819.177: [Unloading, 3.2004912 secs], 3.6499382 secs]
[Times: user=0.20 sys=0.08, real=3.64 secs]
使用 -XX:-ClassUnloadingWithConcurrentMark 对我减少类卸载时间有用吗？如果我使用此选项，如果类卸载永远不会发生，我担心我会遇到更多问题(例如内存不足异常，...)。
编辑:如果我们使用 -XX:+ClassUnloadingWithConcurrentMark (默认选项)，每次 GC 重新标记阶段发生时都会触发类卸载吗？在日志中，我有一些GC，其GC原因:元数据GC阈值，但其他人没有此原因，但卸载仍然发生在备注阶段。为什么会这样？
最佳答案
I'm afraid that If I'll use this option I'll have even more problems
为什么不为这些事情设置一个测试环境并自己测试呢？
无论如何，正如已经回答的那样 over here ，VM 将执行一些最后的英雄行为(1-2 次完整 GC，完整的软引用清除)，以确保在抛出 OOM 之前情况不可恢复。
Would using -XX:-ClassUnloadingWithConcurrentMark be useful to me to reduce class unloading times?
它是否会减少它们，我不知道，可能不会。这就是你必须自己尝试的事情。但这可能会延迟很长一段时间。
if we are using -XX:+ClassUnloadingWithConcurrentMark (default option) is class unloading triggered every time GC remark phase occurs?
是的，这是用 JDK-8049421 添加的以及使用 JDK-8051607 再次将其关闭的标志.
您所要做的就是在 openjdk bugtracker 和/或 hotspot-gc-dev 邮件列表上搜索“类卸载”。这些都是公开信息。
您可以尝试的另一件事是设置-XX:MinMetaspaceFreeRatio=20 -XX:MaxMetaspaceFreeRatio=30。这将更快触发类卸载，并有望缩短周期。
关于java - JVM ClassUnloadingWithConcurrentMark 标志，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30707750/