引言
Java虚拟机（JVM）的内存管理和垃圾回收（Garbage Collection，GC）是Java开发者必须深入理解的核心主题。一个精通的JVM调优可以让应用吞吐量提升数倍，延迟降低数个量级，而一个不当的配置可能导致频繁的Full GC甚至内存溢出。本文将从JVM内存模型的基础出发，深入各个GC算法的原理，并提供生产环境的调优实战指南。
JVM内存模型深度解析
JVM内存主要分为堆内存（Heap）和非堆内存（Non-Heap）两大部分。堆内存是GC管理的主要区域，所有通过new创建的对象都分配在这里。堆内存通常被划分为新生代（Young Generation）和老年代（Old Generation/Tenured Generation）。新生代又细分为一个Eden区和两个Survivor区（S0和S1）。这种分代设计基于”弱分代假说”——大多数对象都是朝生夕死的，少数对象会长期存活。
新生代中的对象经历Minor GC后如果仍然存活，会被移动到Survivor区。每经历一次GC并存活下来，对象的”年龄”就会增加。当年龄达到阈值（默认15）时，对象被晋升到老年代。大对象（如大型数组）则可能直接分配到老年代，以避免在新生代中的复制开销。
非堆内存包括方法区（元空间Metaspace，存储类元数据）、直接内存（Direct Memory，用于NIO缓冲区和本地代码）和线程栈。元空间在Java 8后取代了永久代（PermGen），它使用本地内存而非堆内存，默认情况下不再有固定的大小限制，通过-XX:MaxMetaspaceSize参数可以设置上限。
主流GC算法对比
Serial GC：最简单的GC实现，使用单线程进行垃圾回收。适用于客户端应用或嵌入式场景，以及堆内存较小（<100MB）的情况。在GC期间会Stop-The-World，但对于小内存来说暂停时间很短。
Parallel GC：JDK 8的默认GC，使用多线程进行垃圾回收，充分利用多核CPU的优势。目标是最大化吞吐量，适合批处理、科学计算等对吞吐量要求高而对延迟不敏感的场景。通过-XX:ParallelGCThreads参数可以指定GC线程数。
G1 GC：从JDK 9开始成为默认GC，设计目标是在提供高吞吐量的同时，将GC暂停时间控制在可预测的范围内。G1将堆分割为大小相等的Region（每个Region大小为1-32MB），打破了传统的连续内存划分方式。G1通过维护Remembered Set（RSet）来追踪跨Region的引用关系，使得每次只需回收部分Region即可。
ZGC：一种可扩展的低延迟GC，目标是将GC暂停时间控制在亚毫秒级别，同时支持TB级别的堆。ZGC使用染色指针（Colored Pointers）和读屏障（Load Barrier）技术，使得大部分GC工作可以与应用程序并发执行。从JDK 15开始ZGC成为正式特性，目前已经非常成熟。
Shenandoah GC：与ZGC类似，也是一种低延迟GC，通过Brooks指针和转发指针实现并发压缩。目前主要在Red Hat的JDK发行版中使用。其暂停时间同样独立于堆大小。
GC日志分析与监控
GC日志是进行JVM调优最重要的信息来源。从JDK 9开始，统一GC日志（Unified GC Logging）取代了之前版本中碎片化的日志参数。通过-Xlog:gc*=info或-Xlog:gc*=debug可以启用GC日志。日志中包含了每次GC的类型、持续时间、回收前后的内存使用情况、晋升对象大小等详细信息。
解读GC日志时，需要关注几个关键指标。首先是GC的频率和持续时间——频繁的GC或长时间的GC都是需要优化的信号。其次是每次GC回收的内存量——如果老年代回收效果不佳，可能意味着存在内存泄漏。另外，晋升（Promotion）的对象量过大说明新生代可能太小，导致对象过早进入老年代。
专业的GC分析工具可以大大简化分析工作。GCViewer、GCeasy等工具能将GC日志可视化为图表，自动识别潜在问题。JDK自带的jstat可以实时查看GC统计，VisualVM和JMC（Java Mission Control）则提供了更全面的JVM监控能力。
调优实战策略
JVM调优应该是一个数据驱动的迭代过程，而非盲目修改参数。首先确定优化目标：是追求高吞吐量（吞吐量优先）还是低延迟（响应时间优先）。不同目标对应不同的GC选择——Parallel GC适合吞吐量优先，G1 GC适合平衡场景，ZGC适合低延迟优先。
常见的内存问题包括内存泄漏和内存溢出。内存泄漏通常由静态集合类、未关闭的资源、ThreadLocal未清理等原因导致。通过Heap Dump分析（使用jmap或-XX:+HeapDumpOnOutOfMemoryError参数自动生成），结合MAT（Memory Analyzer Tool）或JProfiler等工具，可以定位泄漏的根源。对于内存溢出，除了增加堆大小外，还应该检查是否存在不合理的大对象分配。
一些实用的调优原则：确保-Xms和-Xmx设置为相同值，避免堆动态调整的开销；新生代和老年代的比例（-XX:NewRatio）应根据应用中短生命周期对象的比例来调整；对于频繁创建大对象的应用，增加新生代比例可能比增加总堆大小更有效；在容器环境中，注意JVM对可用内存和CPU核心数的感知可能与预期不同，JDK 10+可以通过-XX:+UseContainerSupport参数改善这一问题。