1. 垃圾回收程序世界的清洁工想象一下你正在经营一家繁忙的餐厅。顾客来来往往餐盘不断被使用又闲置。如果不及时清理这些用过的餐具很快整个餐厅就会堆满脏盘子新客人将无处就餐。在计算机世界中垃圾回收Garbage Collection简称GC就是那位不知疲倦的清洁工负责回收程序不再使用的内存空间让新对象有容身之处。我第一次真正理解GC的重要性是在处理一个长时间运行的Java服务时。服务运行一周后突然变得异常缓慢最终因内存不足而崩溃。通过堆转储分析发现是内存泄漏导致对象不断累积却未被释放。那次经历让我深刻认识到理解GC机制对开发稳定高效的应用程序至关重要。2. 垃圾回收算法不同的清扫策略2.1 标记-清除算法最基础的回收方式标记-清除算法就像传统的清洁方式先标记出所有需要清理的区域然后一次性清扫。具体分为两个阶段标记阶段从GC Roots如全局变量、活动线程栈中的引用等出发遍历所有可达对象并标记为存活清除阶段遍历整个堆内存回收未被标记的对象所占用的空间我在一个C项目中实现过简单的标记-清除算法发现它的主要问题是会产生内存碎片。就像餐厅里清理出的空位大小不一虽然总空间足够但可能无法容纳较大的新对象。// 简化的标记过程伪代码 void mark(Object obj) { if (obj null || obj.isMarked()) return; obj.setMarked(true); for (Object ref : obj.getReferences()) { mark(ref); } }2.2 复制算法分而治之的解决方案复制算法将内存分为两个相等的半区From和To空间工作时只使用From空间分配对象GC时将From空间中存活的对象复制到To空间清空整个From空间并交换From和To的角色这种算法在新生代回收中很常见。我曾在调优一个高吞吐量系统时通过调整新生代大小和Eden区与Survivor区的比例如-XX:SurvivorRatio8显著减少了minor GC的频率。注意复制算法的内存利用率只有50%适合对象存活率低的场景2.3 标记-整理算法解决碎片化的良方标记-整理算法结合了前两者的优点标记阶段与标记-清除相同整理阶段将所有存活对象向一端移动然后清理边界外的内存这就像整理餐厅桌椅把所有桌椅紧凑排列腾出连续的大空间。在Android开发中ART虚拟机就采用了标记-整理算法来管理堆内存。2.4 分代收集算法因地制宜的策略基于弱代假说大多数对象很快变得不可达现代GC通常采用分代收集新生代使用复制算法如Serial、ParNew、Parallel Scavenge老年代使用标记-清除或标记-整理如CMS、G1我在分析一个电商应用的GC日志时发现通过合理设置-XX:MaxTenuringThreshold晋升年龄阈值可以减少过早晋升到老年代的对象数量从而降低Full GC频率。3. 主流垃圾回收器详解3.1 Serial收集器单线程的经典Serial收集器是Java虚拟机最古老的收集器特点包括单线程工作进行GC时会暂停所有应用线程Stop-The-World新生代使用复制算法老年代使用标记-整理虽然简单但在客户端模式或资源受限的环境中仍有价值。我曾在一个嵌入式设备上使用Serial收集器-XX:UseSerialGC因为它的小内存占用和可预测的暂停时间。3.2 Parallel收集器吞吐量优先Parallel Scavenge新生代和Parallel Old老年代收集器关注吞吐量多线程并行GC适合后台运算不追求低延迟提供丰富的调优参数如-XX:GCTimeRatioGC时间与应用时间比在一个批处理系统中我通过-XX:ParallelGCThreads设置适当的GC线程数通常不超过CPU核心数使系统吞吐量提升了15%。3.3 CMS收集器低延迟的尝试Concurrent Mark-Sweep收集器是首个真正并发的老年代收集器初始标记STW并发标记重新标记STW并发清除CMS的优点是减少了停顿时间但存在内存碎片问题。我在一个Web服务中使用CMS-XX:UseConcMarkSweepGC时不得不定期通过-XX:CMSFullGCsBeforeCompaction设置压缩频率。3.4 G1收集器面向服务端的全能选手Garbage-First收集器是JDK 9及以后的默认收集器特点包括将堆划分为多个Region默认约2048个优先回收垃圾最多的RegionGarbage-First可预测的停顿时间模型-XX:MaxGCPauseMillis在调优一个大数据应用时我发现设置-XX:InitiatingHeapOccupancyPercent触发并发GC周期的堆占用率对平衡GC频率和停顿时间很关键。# 典型的G1调优参数示例 java -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -XX:InitiatingHeapOccupancyPercent45 \ -jar myapp.jar3.5 ZGC和Shenandoah超低延迟的新星ZGC和Shenandoah是新一代收集器目标是将停顿时间控制在10ms以内使用染色指针等新技术几乎全部工作并发进行适合大内存应用我在一个实时交易系统中测试ZGC-XX:UseZGC64GB堆的GC停顿确实可以低于5ms但需要JDK 11的支持。4. GC调优实战经验4.1 读懂GC日志GC日志是调优的第一手资料。启用详细日志记录-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/path/to/gc.log分析日志时我通常关注GC频率和持续时间回收前后各代使用率Full GC的原因如Allocation Failure、System.gc()4.2 常见问题与解决方案内存泄漏对象意外地保持可达状态。我使用Eclipse Memory Analyzer分析堆转储时经常发现是由于静态集合未清理或未正确关闭资源导致。过早晋升短生命周期对象进入老年代。通过-XX:PrintTenuringDistribution观察对象年龄分布调整Survivor区大小或晋升阈值。GC开销过大当超过98%的时间用于GC且回收的内存少于2%时JVM会抛出OutOfMemoryError。这时需要重新评估内存分配策略或改用更适合的收集器。4.3 工具链推荐jstat实时监控GC统计信息jstat -gcutil pid 1000VisualVM图形化分析堆和GCGCViewer可视化GC日志分析工具Perfino或Dynatrace生产环境监控5. 不同场景下的GC选择5.1 Web应用典型特征中等吞吐量要求响应时间稳定。我通常这样配置中小型应用G1JDK8大型应用CMS或Parallel收集器组合5.2 大数据处理高吞吐量优先可以容忍较长GC停顿Parallel Scavenge Parallel Old设置较大的新生代-Xmn5.3 金融交易系统低延迟是关键ZGC或ShenandoahJDK11适当限制堆大小如-XX:SoftMaxHeapSize5.4 Android应用ART虚拟机使用自己的GC并发标记-整理分代收集关注jank界面卡顿与GC的关系在开发Android应用时我经常使用Android Studio的Memory Profiler检测内存泄漏和跟踪对象分配。