是否存在可强制执行完整垃圾回收的Garbage collector或flag/option？

这绝对是个戳中内存泄漏测试痛点的需求——毕竟要精准验证某个操作后资源是否真的释放，能触发一次“不留死角”的GC太关键了。结合HotSpot JVM（绝大多数Java应用的选择）的情况，给你梳理几个可行的方案：

1. 调整JVM参数，让System.gc()触发彻底的Full GC + 类卸载 #

默认情况下，System.gc()只是向JVM“建议”执行GC，但通过以下参数可以把它变成强制触发Full GC的指令，甚至附带类卸载能力：

• 如果用Serial/Parallel GC（默认的客户端/服务端GC）：System.gc()默认就会触发Full GC，但要确保没开-XX:+DisableExplicitGC（这个参数是禁用显式GC的，测试时绝对不能加）。
• 如果用CMS GC：需要加上-XX:+CMSClassUnloadingEnabled，这样显式GC时不仅会回收对象，还会尝试卸载不再使用的类；搭配-XX:+ExplicitGCInvokesConcurrent可以让CMS以并发方式执行Full GC，若要强制同步Full GC，也可以用-XX:-ExplicitGCInvokesConcurrent（注意是减号）。
• 如果用G1 GC：默认System.gc()触发的是并发GC，若要强制触发Full GC并卸载类，加上-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses即可。

2. 用jcmd工具触发更可靠的Full GC #

如果你的测试环境允许外部工具介入，jcmd是个比代码里调System.gc()更靠谱的选择：

jcmd <你的应用PID> GC.fullgc

这个命令会直接触发一次Full GC，不受应用内-XX:+DisableExplicitGC参数的影响，而且能确保回收所有可回收的对象，同时尝试类卸载（前提是类卸载的参数已经开启）。

3. 为了彻底性，建议配合Finalizer处理 #

有些对象会因为Finalizer队列的存在，第一次GC后不会被立即回收，所以可以在触发GC后加上Finalizer执行的逻辑，比如在代码里这么写：

// 先触发一次GC
System.gc();
// 等待Finalizer线程处理所有待终结的对象
Runtime.getRuntime().runFinalization();
// 再补一次GC，确保被Finalizer处理后的对象也被回收
System.gc();

这一步能避免因为Finalizer延迟回收导致的误判——毕竟你不希望因为Finalizer还挂着引用，就误以为类没被卸载对吧？

关于你的测试流程的补充 #

你提到的“执行操作→调用GC→用VM agent遍历类检查是否存在”的方案是完全可行的，但要注意：类卸载的前提是该类的所有实例已被回收、加载它的类加载器已被回收、没有任何静态引用或VM内部引用指向这个类。如果遍历后发现类还存在，大概率是有某个地方还握着对类或类加载器的引用，这就是内存泄漏的线索。

最后要提醒的是：没有任何GC能“100%保证”回收所有理论上可回收的资源（比如JNI层面的全局引用、VM内部的隐式引用），但上面的方案已经能覆盖绝大多数Java应用的测试场景，足够帮你定位类级别的内存泄漏了。

内容来源于stack exchange