在绝大多数情况下，你不需要，也不应该手动触发垃圾回收。

现代的Java虚拟机（JVM）内置了非常智能和高效的垃圾回收器，它们会自动管理内存，手动调用System.gc()或Runtime.getRuntime().gc()往往会带来负面影响,而不是好处。

下面我将从以下几个方面详细解释：

1. 手动GC的命令是什么？
2. 为什么说手动GC通常是个坏主意？
3. 什么情况下才应该考虑手动GC？
4. 如何在不修改代码的情况下“手动”触发GC？（JVM参数）
5. 如何监控和分析GC行为？

手动GC的命令是什么？

在Java代码中,有两个方法可以手动建议JVM进行垃圾回收：

a) System.gc()

这是最常见的方式，是一个静态方法，直接在System类中调用。

public class ManualGCExample {
    public static void main(String[] args) {
        // 创建一些对象，模拟内存占用
        for (int i = 0; i < 10000; i++) {
            byte[] array = new byte[1024 * 1024]; // 每个对象约1MB
        }
        System.out.println("准备手动触发GC...");
        System.gc(); // 建议JVM进行垃圾回收
        System.out.println("GC建议已发出。");
        // 为了让GC有机会执行，主线程稍作等待
        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

b) Runtime.getRuntime().gc()

这是另一种等价的方式，通过获取当前JVM的Runtime实例来调用gc()方法。

// 与上面效果完全相同
Runtime.getRuntime().gc();

关键点：

• 这两个方法都是建议（recommendation），而不是命令（command）。
• JVM可能会忽略这个建议，也可能不会立即执行GC,具体执行时机由GC算法和JVM决定。
• 它们会触发一个Full GC（或称为Major GC），这是一个非常耗时的操作，会暂停所有应用程序线程（即"Stop-The-World", STW）。

为什么说手动GC通常是个坏主意？

滥用System.gc()是Java性能优化中常见的反模式,原因如下：

1. 不可预测性：你无法控制GC何时发生，JVM可能会延迟执行，也可能在你最不希望它发生的时候执行（在处理一个高并发的请求时）。

   
   （图片来源网络，侵删）

2. 性能开销巨大：System.gc()通常会导致一次Full GC，Full GC需要扫描整个老年代（Old Generation）和元空间（Metaspace），这个过程会长时间暂停所有用户线程，对于高延迟敏感的应用（如Web服务、交易系统）,这会导致明显的卡顿和性能下降。

3. 破坏JVM的自动优化：现代GC（如G1、ZGC、Shenandoah）是基于复杂的启发式算法来决定何时、何地进行GC的，它们会根据应用程序的内存分配速率、回收效率等动态调整策略，手动GC会干扰这种自动优化,导致GC策略次优化。

4. 误导开发者：开发者可能会误以为调用System.gc()就能解决内存问题（如OutOfMemoryError），但实际上，内存泄漏的根源在于代码逻辑（对象被意外地长生命周期引用），而不是GC不够“努力”，不修复根本问题，手动GC只是治标不治本,甚至可能让问题更糟。

什么情况下才应该考虑手动GC？

虽然罕见，但在某些特定场景下,手动GC可能是有用的：

1. 单元测试：在单元测试中，你可能需要确保测试方法结束后，某些大对象被回收，以避免影响后续测试，但更好的做法是使用WeakReference等工具来验证回收，而不是依赖System.gc()。

2. 调试和诊断：当你怀疑有内存泄漏，并使用内存分析工具（如Eclipse MAT, VisualVM）时，可以在某个特定逻辑点调用System.gc()，然后生成堆快照，这样做可以确保生成快照时，那些本应被回收但实际上没有被回收的对象仍然存在，从而方便分析。这纯粹是诊断目的，不应出现在生产代码中。

3. 特定资源清理：如果一个对象持有了一些非Java资源（如文件句柄、数据库连接），并且这个对象的finalize()方法中包含了这些资源的清理逻辑，在某些极端情况下，开发者可能会尝试调用System.gc()来加速finalize()的执行。但请注意，finalize()方法本身是不可靠且不推荐的，Java 9+甚至被废弃了。 更好的做法是使用try-with-resources或明确的close()方法。

如何在不修改代码的情况下“手动”触发GC？（JVM参数）

如果你想在运行时或通过管理工具（如JConsole, VisualVM）触发GC，而不修改源代码,可以使用JVM参数。

a) 启用显式GC (-XX:+ExplicitGCInvokesConcurrent)

默认情况下，在JConsole或VisualVM中点击“执行GC”按钮，调用的就是System.gc()，它会触发一个STW的Full GC。

你可以通过以下JVM参数来改变这个行为：

• -XX:+DisableExplicitGC：（强烈推荐在生产环境使用） 这个参数会完全忽略System.gc()和JConsole的“执行GC”命令，JVM将完全自主管理GC,这是避免手动GC干扰的最佳实践。

• -XX:+ExplicitGCInvokesConcurrent：当你在JConsole中点击“执行GC”时，这个参数会让G1或Parallel GC等并发回收器尝试执行一次并发标记的GC，而不是STW的Full GC，这能显著减少GC暂停时间,但依然会干扰JVM的自动调度。

b) 使用JMX触发GC

这是更“专业”的“手动”方式，通过JMX（Java Management Extensions），你可以获取一个MemoryMXBean对象，并调用它的gc()方法。

// 代码示例
import java.lang.management.ManagementFactory;
import java.lang.management.MemoryMXBean;
public class JMXGCTest {
    public static void main(String[] args) throws Exception {
        MemoryMXBean memoryMXBean = ManagementFactory.getMemoryMXBean();
        // 这与System.gc()行为类似，但通过JMX接口
        memoryMXBean.gc(); 
        // 让程序保持运行，以便用JConsole连接
        Thread.sleep(Long.MAX_VALUE);
    }
}

使用jconsole或visualvm连接到这个JVM，你可以在MBeans -> java.lang -> Memory -> Operations下找到并调用gc()操作。

如何监控和分析GC行为？

与其手动触发GC，不如学会如何监控和分析GC,这才是解决内存问题的正确路径。

1. 启用GC日志：这是最重要的一步，通过JVM参数,让JVM把GC的详细信息打印到日志文件中。

   java -Xms512m -Xmx512m -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log MyApp

   • -Xms, -Xmx：设置堆大小。
   • -XX:+PrintGCDetails：打印详细的GC信息。
   • -XX:+PrintGCDateStamps：打印GC发生的时间戳。
   • -Xloggc:gc.log：将GC日志输出到文件。

2. 使用分析工具：

   • GCViewer：一个开源工具，可以解析gc.log文件，生成图表，直观地展示GC次数、暂停时间、堆内存变化等。
   • Eclipse MAT：强大的内存分析工具，用于分析堆转储文件（Heap Dump）,查找内存泄漏的根源。
   • VisualVM / JConsole：JDK自带的监控工具，可以实时查看内存使用情况、线程状态，并执行一些管理操作（如触发GC，但再次强调，生产环境慎用）。

记住黄金法则：相信JVM，而不是自己。 优秀的工程师应该通过优化代码和配置JVM来让垃圾回收自动化、高效化，而不是试图去“帮助”它。