我对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：ClassUnloadingWith ConloctMark（默认选项），每次发生GC备注阶段时都会触发类卸载吗？在日志中，我有一些GC与GC原因：元数据GC阈值，但其他人没有这个原因，但卸载仍然发生在备注阶段。为什么会这样？
恐怕如果我使用此选项，我会遇到更多问题
为什么不直接为这些东西建立一个测试环境，然后自己测试呢？
无论如何，正如这里已经回答的那样，VM 将执行一些最后的英雄行为（1-2 个完整的 GC，完整的软引用清除），以确保在抛出 OOM 之前情况不可恢复。
使用-XX：-ClassUnloadingWith ConloctMark对我减少类卸载时间有用吗？
它是否会减少它们，我不知道，可能不会。这就是你必须自己尝试的。但它可能会将不可避免的事情推迟很长时间。
如果我们使用-XX:classunloadingwithconcurentmark(默认选项)，那么每次GC remark阶段发生时，类卸载都会被触发吗？
是的，这是与JDK-8049421一起添加的，并且使用JDK-8051607再次关闭它的标志。
您所要做的就是在openjdk bugtracker和/或hotspot-gc-dev邮件列表中搜索“类卸载”。这都是公开信息。
另一个可以尝试的方法是设置< code >-XX:MinMetaspaceFreeRatio = 20-XX:MaxMetaspaceFreeRatio = 30 。这将更快地触发类卸载，并有希望导致更短的周期。
G1在STW Remark阶段执行类卸载，这是默认行为。您不能阻止类卸载，因为这样做最终会导致“内存不足”错误。
缓解此问题的唯一方法是修改代码以停止使用动态类生成。
