Java JVM垃圾回收机制详解

JVM垃圾回收通过可达性分析确定回收对象，以分代策略管理堆内存，采用多种算法与收集器优化性能。1. 不可达GC Roots的对象被回收；2. 堆分为年轻代、老年代和元空间，分别处理短/长生命周期对象；3. 标记-清除、复制、标记-整理算法对应不同场景，Serial、Parallel、CMS、G1、ZGC等收集器适配各类应用需求；4. 开发中需监控GC频率与类型，调优参数并选择合适收集器，避免频繁Full GC影响性能。

JVM垃圾回收（Garbage Collection，简称GC）是Java后端开发中自动内存管理的核心机制。它负责在程序运行过程中自动识别并清理不再使用的对象，释放堆内存，避免内存泄漏和手动管理内存带来的风险。

1. 哪些对象需要被回收？

JVM通过可达性分析算法判断对象是否存活。从一组称为“GC Roots”的对象（如正在执行的方法中的局部变量、系统类加载器、活动线程等）出发，向下搜索引用链。如果一个对象无法通过任何引用链到达GC Roots，则被视为可回收的“垃圾”。

常见的GC Roots包括：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI（即Native方法）引用的对象
• 活跃线程本身

2. JVM堆内存结构与分代回收策略

Java堆通常分为三个区域：年轻代（Young Generation）、老年代（Old Generation）和元空间（Metaspace，替代永久代）。JVM采用分代收集策略，基于“大多数对象朝生夕死”的经验假设，对不同生命周期的对象采用不同的回收算法。

• 又分为Eden区、两个Survivor区（S0和S1）
• 新创建的对象优先分配在Eden区
• 当Eden区满时，触发Minor GC（也称Young GC）
• 存活的对象会被复制到其中一个Survivor区，同时年龄+1
• 经过多次Minor GC仍存活的对象将晋升到老年代

• 存放长期存活或大对象
• 当老年代空间不足时，触发Major GC / Full GC
• Full GC会暂停所有应用线程（Stop-The-World），影响系统性能

3. 常见的垃圾回收算法与收集器

JVM提供了多种垃圾回收算法和对应的收集器，开发者可根据应用场景选择合适的组合。

• 标记-清除（Mark-Sweep）：先标记存活对象，再清除未标记对象。缺点是会产生内存碎片
• 复制（Copying）：将存活对象复制到另一块区域，适用于年轻代，效率高但浪费空间
• 标记-整理（Mark-Compact）：标记后将存活对象向一端移动，消除碎片，适合老年代

• Serial：单线程收集，适用于客户端场景
• Parallel Scavenge：多线程年轻代收集，注重吞吐量
• ParNew：多线程版本的Serial，常与CMS搭配使用
• CMS（Concurrent Mark Sweep）：老年代收集器，追求低停顿，但已废弃（JDK 14起移除）
• G1（Garbage First）：面向服务端，将堆划分为多个Region，支持并发、并行，兼顾吞吐量与停顿时间
• ZGC / Shenandoah：超低延迟收集器，支持TB级堆内存，停顿时间控制在10ms以内

4. 实际开发中的关注点

作为Java后端开发者，虽然不需要手动触发GC，但需关注其对系统性能的影响。

• 频繁的Minor GC可能提示对象创建过多，考虑优化对象复用或缓存
• 频繁的Full GC可能导致接口超时，应检查是否有内存泄漏或大对象频繁晋升
• 可通过JVM参数调整堆大小、新生代比例等，如-Xms、-Xmx、-XX:NewRatio、-XX:MaxGCPauseMillis
• 使用工具如jstat、jmap、VisualVM、Arthas等监控GC日志和内存分布
• 合理选择GC收集器，例如高并发低延迟系统推荐使用G1或ZGC