1. 垃圾回收机制概述Java的垃圾回收Garbage Collection简称GC是JVM自动管理内存的核心机制。与C/C等需要手动释放内存的语言不同Java程序员不需要显式调用delete或free来释放对象占用的内存空间。这套机制通过追踪对象的引用关系自动识别并回收不再被使用的对象内存。我第一次接触GC概念是在处理一个内存泄漏问题时。当时应用运行几小时后就会出现OutOfMemoryError通过GC日志分析才发现是缓存中的对象引用未被正确清理。这个经历让我深刻认识到即使有自动GC机制理解其工作原理对写出高质量Java代码仍然至关重要。2. GC核心概念解析2.1 对象可达性判定JVM判断对象是否存活的依据是可达性分析Reachability Analysis。从GC Roots包括虚拟机栈局部变量、方法区静态变量、本地方法栈JNI引用等出发如果对象不可达就会被标记为可回收。这里有个容易误解的点即使对象还有引用但如果引用链不从GC Roots出发仍然会被回收。注意常见的内存泄漏场景就是对象被意外保留在长生命周期的集合中虽然程序不再使用但GC无法回收2.2 分代收集理论基于弱分代假说绝大多数对象朝生夕死和强分代假说熬过越多次GC的对象越难消亡HotSpot VM将堆内存划分为新生代Young GenerationEden区对象初次分配的位置Survivor区From/To经过Minor GC后存活的对象老年代Old Generation长期存活的对象元空间Metaspace类元信息等Java 8后取代PermGen这种设计使得不同区域可以采用最适合的收集算法。比如新生代使用复制算法而老年代使用标记-整理算法。3. 常见GC算法详解3.1 标记-清除Mark-Sweep最基础的GC算法分为两个阶段标记阶段遍历对象图标记存活对象清除阶段回收未标记对象的内存问题在于会产生内存碎片。我在处理一个大型缓存系统时就遇到过因为碎片导致明明有足够内存却无法分配大对象的情况。3.2 复制算法Copying将内存分为两块只使用其中一块。GC时把存活对象复制到另一块然后清空当前块。优点是没有碎片但内存利用率只有50%。HotSpot的年轻代采用改良版Eden和Survivor的比例默认是8:1:1。3.3 标记-整理Mark-Compact类似标记-清除但在清除后会进行内存整理解决碎片问题。老年代通常采用这种算法。缺点是移动对象需要更新引用会带来额外开销。4. HotSpot中的GC实现4.1 Serial收集器单线程工作的收集器进行GC时必须暂停所有工作线程Stop-The-World。看起来落后但在客户端模式下如GUI程序仍有价值因为其简单高效没有线程交互开销。4.2 Parallel收集器Serial的多线程版本注重吞吐量。JDK8的默认收集器适合后台运算不需要低延迟的场景。我常用以下参数调优-XX:ParallelGCThreads4 // GC线程数 -XX:MaxGCPauseMillis200 // 目标最大暂停时间4.3 CMS收集器以获取最短回收停顿时间为目标的收集器采用标记-清除算法。主要步骤初始标记STW并发标记重新标记STW并发清除虽然减少了停顿时间但会产生内存碎片且对CPU资源敏感。我在高并发系统中使用时经常遇到Concurrent Mode Failure导致退化为Serial Old的情况。4.4 G1收集器JDK9后的默认收集器将堆划分为多个Region优先回收价值最大的Region。特点包括可预测的停顿模型整体基于标记-整理局部基于复制适合大内存4G以上应用配置示例-XX:UseG1GC -XX:G1HeapRegionSize8m -XX:MaxGCPauseMillis1005. GC调优实战技巧5.1 关键参数解析-Xms4g -Xmx4g // 堆大小固定避免动态调整 -XX:NewRatio2 // 老年代与新生代比例 -XX:SurvivorRatio8 // Eden与Survivor比例 -XX:MaxTenuringThreshold15 // 晋升老年代年龄5.2 日志分析要点启用详细GC日志-Xloggc:gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps重点关注Full GC频率和耗时老年代使用趋势晋升失败Promotion Failed情况5.3 常见问题排查频繁Full GC检查是否有内存泄漏jmap -histo调整新生代大小减少过早晋升长时间GC停顿考虑切换到G1或ZGC检查是否有大对象分配jmap -histo:liveMetaspace溢出检查动态类生成如CGLIB适当增大-XX:MaxMetaspaceSize6. 新一代GC技术展望ZGC和Shenandoah作为新一代低延迟GC已经可以在TB级堆上实现10ms以下的停顿。我在一个金融交易系统中测试ZGC将99.9%的GC停顿控制在3ms内。关键参数-XX:UseZGC -XX:ConcGCThreads4 -XX:SoftMaxHeapSize8g不过这些收集器对JDK版本有要求ZGC需要JDK11且可能需要调整应用架构如减少对象分配速率。