1. 垃圾回收基础概念解析
在Java虚拟机(JVM)的内存管理机制中，垃圾回收(GC)是一个核心功能模块。它负责自动回收那些不再被程序使用的对象所占用的内存空间。理解GC的工作原理对于优化Java应用性能至关重要，特别是在处理高并发、大内存消耗的应用场景时。
GC主要分为两种类型：Minor GC（年轻代垃圾回收）和Full GC（全堆垃圾回收）。这两种回收机制针对不同的内存区域，触发条件和执行策略也各不相同。要深入理解它们的触发时机，首先需要了解JVM的内存结构划分。
现代JVM通常将堆内存划分为以下几个区域：
- 年轻代(Young Generation)：存放新创建的对象
- 老年代(Old Generation)：存放存活时间较长的对象
- 元空间(Metaspace)：存放类元数据信息（在JDK8+中取代了永久代）
年轻代又进一步分为：
- Eden区：对象最初被分配的区域
- Survivor区（包括From和To两个区域）：存放从Eden区经过一次GC后存活的对象
2. Minor GC的触发时机与执行过程
2.1 Minor GC的基本触发条件
Minor GC专门针对年轻代进行垃圾回收，它的主要触发条件是Eden区空间不足。具体来说，当尝试在Eden区分配一个新对象时，如果发现剩余空间不足以容纳该对象，JVM就会触发一次Minor GC。
这个判断过程发生在对象分配的时刻。JVM使用指针碰撞(Bump the Pointer)或空闲列表(Free List)等技术来管理Eden区的内存分配。当分配请求到来时，内存管理器会检查当前指针位置与Eden区上限之间的距离是否足够存放新对象。
2.2 Minor GC的执行流程
一次完整的Minor GC通常包含以下步骤：
- 根对象枚举：从GC Roots（如栈帧中的局部变量、静态变量等）出发，标记所有可达对象
- 标记阶段：遍历对象图，标记所有存活对象
- 清除阶段：回收未被标记的垃圾对象所占空间
- 对象晋升：将存活的对象移动到Survivor区或老年代
在HotSpot虚拟机中，年轻代通常采用复制算法进行垃圾回收。这是因为年轻代中的对象大多具有"朝生夕死"的特点，复制算法的效率在这种场景下非常高。
2.3 对象晋升规则
在Minor GC过程中，存活的对象会根据特定规则被晋升到Survivor区或老年代：
- 年龄阈值：每个对象都有一个年龄计数器，记录它经历过的GC次数。当对象年龄超过一定阈值（默认15，可通过-XX:MaxTenuringThreshold调整）时，会被晋升到老年代
- 空间担保：如果Survivor区空间不足，部分对象可能直接晋升到老年代
- 大对象直接分配：超过一定大小的对象可能直接分配在老年代（通过-XX:PretenureSizeThreshold参数控制）
提示：在实际应用中，可以通过-XX:+PrintGCDetails参数打印GC日志，观察对象晋升的具体情况。
3. Full GC的触发时机与执行机制
3.1 Full GC的主要触发条件
Full GC是对整个堆内存（包括年轻代和老年代）进行垃圾回收的过程，它的触发条件比Minor GC复杂得多。以下是常见的Full GC触发场景：
- 老年代空间不足：当老年代没有足够空间容纳从年轻代晋升的对象时
- 元空间不足：当元空间使用量超过其容量限制时
- System.gc()调用：虽然不保证立即执行，但通常会触发Full GC
- 堆外内存分配失败：当直接内存(Direct Memory)不足时
- 并发模式失败：在使用CMS或G1等并发收集器时，如果回收速度跟不上对象分配速度
3.2 空间分配担保机制
在Minor GC发生前，JVM会执行空间分配担保检查，这是Full GC的一个重要触发点：
- JVM会检查老年代最大可用连续空间是否大于年轻代所有对象总大小
- 如果条件不满足，则检查是否允许担保失败（HandlePromotionFailure）
- 如果担保失败也不允许，则会直接触发Full GC
这个机制是为了确保在极端情况下（年轻代所有对象都需要晋升）不会导致内存溢出。
3.3 不同垃圾收集器的Full GC行为
不同的垃圾收集器对Full GC的实现有所不同：
- Serial/Parallel收集器：采用标记-整理算法，会暂停所有应用线程（Stop-The-World）
- CMS收集器：并发收集，但在并发模式失败时会退化为Serial收集器执行Full GC
- G1收集器：设计目标是避免Full GC，但在某些情况下（如并发周期完成前堆被填满）仍会触发
4. GC调优实践与监控
4.1 关键性能指标
在评估GC性能时，我们主要关注以下指标：
- 吞吐量：应用运行时间占总时间（应用时间+GC时间）的比例
- 停顿时间：单次GC导致的应用暂停时间
- 频率：GC发生的频繁程度
- 内存占用：堆内存的使用效率
4.2 常见调优参数
以下是一些常用的GC调优参数：
| 参数 | 作用 | 默认值 |
|---|---|---|
| -Xms | 初始堆大小 | 物理内存1/64 |
| -Xmx | 最大堆大小 | 物理内存1/4 |
| -Xmn | 年轻代大小 | 堆大小的1/3 |
| -XX:SurvivorRatio | Eden与Survivor区比例 | 8 |
| -XX:MaxTenuringThreshold | 晋升老年代的年龄阈值 | 15 |
| -XX:+UseAdaptiveSizePolicy | 启用自适应大小策略 | true |
4.3 GC日志分析
通过分析GC日志可以深入了解GC行为：
code复制[GC (Allocation Failure) [PSYoungGen: 65536K->10752K(76288K)] 65536K->22016K(251392K), 0.0123456 secs] [Times: user=0.03 sys=0.01, real=0.01 secs]
日志中包含了：
- GC类型（Minor/Full）
- 触发原因（如Allocation Failure）
- 各区域回收前后的内存变化
- 耗时统计
5. 常见问题与解决方案
5.1 频繁Full GC问题排查
当应用出现频繁Full GC时，可以按照以下步骤排查：
- 检查老年代使用情况：是否设置了过小的堆或老年代空间
- 分析对象晋升速度：是否由于年轻代过小导致对象过早晋升
- 检查内存泄漏：使用堆转储(Heap Dump)分析老年代对象构成
- 评估元空间使用：类加载器是否导致元空间膨胀
5.2 Minor GC时间过长
如果Minor GC耗时异常增加，可能的原因包括：
- 年轻代过大导致每次回收对象数量增多
- 存活对象过多，复制开销大
- 引用链过长，标记阶段耗时增加
解决方案可能包括：
- 调整年轻代大小
- 优化对象结构，减少引用深度
- 考虑使用更高效的收集器（如ParNew）
5.3 系统吞吐量下降
当GC成为系统瓶颈时，可以尝试：
- 增加堆内存总量，减少GC频率
- 使用并行收集器提高GC效率
- 优化代码，减少对象分配速率
- 考虑使用ZGC或Shenandoah等低延迟收集器
在实际生产环境中，我发现合理设置-XX:MaxTenuringThreshold参数可以有效控制对象晋升速度。对于生命周期较短的应用，适当降低这个阈值可以减少老年代的压力；而对于长期运行的服务，提高阈值可以让更多对象在年轻代被回收，减少Full GC的发生。