你写的每一行代码都在为垃圾回收打工三个星期前我接手了一个线上服务——平均响应时间从50毫秒飙升到了5秒CPU使用率居高不下每隔两小时就会触发一次Full GC。团队把堆内存从4G加到8G问题反而更严重了。他们以为“内存不够”是原罪实际上堆越大GC暂停时间越长性能黑洞越深。我们打开GC日志发现Young GC频率高达每秒40次每次停顿300毫秒而一次Full GC竟然耗时12秒。这不是内存不足这是垃圾回收器在和业务线程争抢CPU时间片。调优的第一课别急着加内存先弄清楚你的对象是怎么死的。对象生死的真相不是你以为的“没引用”几乎所有Java开发者都知道“可达性分析算法”但大多数人低估了GCRoot的规模。JVM并非只扫描栈帧中的局部变量还会扫描所有的静态字段、JNI引用、活跃线程栈、同步监视器等。一个典型的Web应用线程数200GCRoot总数可能超过10万个。每次GC都需要从这10万个根出发遍历整个堆。最常被忽视的GCRoot是ThreadLocal。很多开发者以为方法结束就会释放但如果你用线程池线程一直存活ThreadLocal里的对象永远不会被回收除非你手动remove。我见过一个系统因为ThreadLocal里的数据库连接池监控对象不断累积最终导致元空间溢出。另一个经典陷阱是集合中的“残留引用”。HashMap里的Entry即使被remove如果Key还活着Value就无法被回收不实际上remove会断开Map.Entry的引用链。但如果你用HashMap存储Key-Value对Value内部又持有外部对象的引用就会形成隐性的内存泄漏。比如一个缓存Mapkey是订单IDvalue是订单详情对象订单详情对象里又引用了用户对象。当订单ID被移除但用户对象还被其他缓存持有那么整个订单详情依然存活。实际调优中80%的内存问题不是堆不够而是对象不该活而活。学会用MAT或JProfiler做堆转储分析找那些“本该GC却没GC”的对象才是调优的第一步。逃逸分析JVM帮你优化但你不懂它很多人以为“new出来的对象一定在堆上分配”这其实是Java语言规范给你留下的错觉。在JVM实现层面逃逸分析可以把不会逃逸的对象直接分配到栈上随着栈帧弹出自动销毁完全绕过GC。但逃逸分析依赖于C2编译器Server Compiler而且只有在JVM断定对象不会逃逸出方法或线程时才会生效。一个典型的反例你在循环里创建StringBuilder拼接字符串如果StringBuilder对象只在方法内部使用没有返回JVM可以将其分配在栈上。但如果你在方法里把StringBuilder赋值给一个局部变量然后返回其toString()结果JVM就认为StringBuilder逃逸了因为toString()返回的String引用了StringBuilder内部char数组不实际上StringBuilder的char数组是对象内部的如果StringBuilder本身逃逸则内部数组也逃逸。但更好的做法是使用StringBuffer还是StringBuilder不重要关键在于让对象不要被方法返回。实际代码中很多开发者习惯写return new ArrayList(list)这会导致每次调用都创建一个新对象。如果调用频率很高比如每秒数千次就会产生大量短期对象增加GC压力。改成返回不可变视图Collections.unmodifiableList(list)或直接返回原始引用如果确定安全就能显著减少对象产生。逃逸分析不是银弹。它的生效依赖于JIT编译优化而JIT编译是有开销的。如果你的热点方法内联失败、逃逸分析判定不准反而会回退到堆分配。更糟的是某些对象明明可以栈分配但因为代码写得过于复杂多层调用、匿名内部类导致逃逸分析无法穿透。Young GC的终极奥秘对象年龄和大小很多调优指南告诉你“调大新生代大小可以减少Young GC频率”这是正确的废话。新生代越大会导致GC暂停时间线性增长因为扫描的对象更多了。实际的调优方向是让短期对象尽快死在新生代减少晋升到老年代的机会。一个关键参数是-XX:PretenureSizeThreshold默认值为0表示不启用大对象直接进入老年代的策略。如果你知道某些对象体积很大比如缓存数组、大字符串可以设置一个阈值比如1MB让它们直接进入老年代避免在新生代复制的昂贵操作。但要注意这个方法会减少新生代空间反而可能加剧新生代GC。另一个反直觉的点是对象年龄提升Tenuring。默认情况下对象在新生代每熬过一次Minor GC年龄1达到15CMS或6G1后晋升老年代。如果你发现老年代增长过快可以增大-XX:MaxTenuringThreshold让对象多在新生代存活几轮但这会增加新生代复制次数。实际上对于大多数应用保持默认值就好除非你明确知道对象的生命周期分布。最好的调整方法是监控GC日志中的“Desired survivor size”。JVM会动态调整幸存区的大小使得每次GC后幸存区空间占用不超过50%。如果幸存区经常被填满导致对象提前晋升可以显式增大-XX:SurvivorRatio从默认8改为4或更低给幸存区更多空间。一个真实案例某个订单系统每处理10万个订单就触发一次Full GC。我们发现许多订单详情对象约10KB在新生代存活时间极短但因为没有空间直接被Copy到老年代。调整-XX:TargetSurvivorRatio从50%降到20%并增大幸存区比例后晋升率下降了60%Full GC频率从每20分钟一次降到每3小时一次。G1垃圾回收器你以为它在延迟其实它在分区G1Garbage First是JDK 9以来的默认回收器但大多数人对它的认知停留在“可以设置暂停时间目标”上。核心思想是把堆划分为2048个Region1-32MB每次只回收其中几个Region从而控制暂停时间。但底层逻辑比你想象得复杂。导致G1性能问题的头号杀手是“Humongous Allocation”巨型对象分配。G1规定对象大小超过Region的一半通常是1-16MB即为巨型对象会直接分配到老年代的多个连续Region中。这些巨型对象在GC时无法被移动因为连续空间不好处理导致老年代产生大量碎片。而碎片会进一步导致分配失败触发Full GC。解决办法不是禁止大对象而是在代码层面拆分大对象。例如一个包含100万个元素的ArrayList如果你能改为分片存储比如10个List每个10万就不会产生巨型对象。或者使用堆外内存DirectBuffer配合Netty的PooledByteBuf来管理大缓冲区。另一个G1调优重点是-XX:G1HeapRegionSize。默认会根据堆大小自动计算堆/2048。如果你有大量小于1MB的对象可以调小Region比如1MB这样可以更精细地回收。但Region太小会导致Region数量过多增加GC元数据开销。一个经验法则Region大小堆大小/2048但不超过32MB。关于暂停时间目标-XX:MaxGCPauseMillis很多人设10ms却发现根本达不到。G1会努力达成这个目标但代价是收集更多的年轻代Region意味着更大的吞吐损失。如果设得太小比如20msG1会把年轻代空间压缩到很小导致Young GC频率激增。推荐值100-200ms除非你是对延迟极度敏感的交易系统。CMS的前世今生为什么被G1取代但仍有生存空间CMSConcurrent Mark Sweep曾经是低延迟服务的标配但它在JDK 14中被正式移除。尽管如此许多老系统依然在运行CMS。CMS最大的问题是碎片化和并发模式失败。由于采用标记-清除算法老年代会越来越碎片化最终导致“晋升失败”Promotion Failed即新生代对象无法找到足够连续空间晋升到老年代从而触发Full GC而CMS的Full GC是单线程且非常缓慢。当你发现GC日志中有大量的CMS remark暂停超时或者“concurrent mode failure”时说明碎片化已经非常严重。此时可以尝试启用-XX:UseCMSCompactAtFullCollection在Full GC后压缩配合-XX:CMSFullGCsBeforeCompaction默认0即每次Full GC后都压缩。但压缩是Stop-The-World的反而违背了CMS的低延迟初衷。另一个常见调优点是调整CMS触发阈值。默认老年代使用率达到68%-XX:CMSInitiatingOccupancyFraction时开始并发收集。这个值偏保守可以调高到75%-80%来减少收集次数。但注意调得太高比如92%很容易导致并发模式失败因为Concurrent Mark阶段还没完成老年代就满了。根据经验对于堆内存固定的系统可以设为85%并开启-XX:UseCMSInitiatingOccupancyOnly仅使用设定的阈值不动态调整。现在的趋势是逐渐迁移到G1但如果你维护的是CMS系统最实用的策略是增大堆空间并同时调大CMS触发阈值让老年代有更多空闲空间来处理晋升。比如8G的堆设CMSInitiatingOccupancyFraction80等于在老年代用满6.4G时才开始GC留出1.6G缓冲大幅降低并发失败风险。元空间不再PermGen的调优新坑JDK 8用元空间Metaspace取代了永久代默认只受本地内存限制。很多人觉得“元空间不会OOM”实际上动态生成类CGLIB、Javassist、反射过多会导致元空间膨胀直到触发操作系统OOM Killer。更糟的是元空间GC是Full GC的一部分不会单独触发。一个常见场景是Spring或Hibernate的类加载器泄漏。每次热部署比如JRebel或应用重新加载都会创建新的ClassLoader如果旧ClassLoader没有被垃圾回收那么它加载的类会永远占用元空间。解决方法使用-XX:MaxMetaspaceSize设置上限比如256MB一旦超过就触发Full GC让JVM有机会回收死掉的ClassLoader。另一个点是字符串常量池从JDK 7开始移到了堆上但元空间中仍然存在类的元数据。如果一个类使用了大量的字符串常量比如枚举类的name这些常量在JVM内部是interned字符串占用的是堆而不是元空间。所以不要混淆。对于大量使用Lambda表达式的应用每个lambda表达式都会在运行时生成一个匿名内部类这些类默认不会被卸载除非它的ClassLoader被回收。如果lambda在循环或频繁方法中使用可以考虑提取为静态方法引用减少匿名类生成。调优工具链不只是jstat和jmap很多人调优只会用jstat -gcutil看GC占比用jmap dump堆。我在实战中依赖的是一个闭环工具链GC日志是根本。启动参数加入-Xloggc:/path/to/gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintTenuringDistribution -XX:PrintHeapAtGC -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles5 -XX:GCLogFileSize10M。有了详细的晋升分布和每次GC前后的堆情况才能判断是对象提前晋升还是老年代碎片。Aliasing分析堆转储。MAT的“Leak Suspects”报告能快速定位持有大对象的GCRoot但更深层次的优化需要看OQL查询。比如我常用SELECT FROM java.lang.String WHERE length 1000查找大字符串然后跟踪这些字符串来自哪里。JMCJava Mission Control的飞行记录器。对生产环境影响极小小于1%可以录制方法调用、锁等待、GC暂停特别适合排查GC暂停和响应时间波动的关联。最实用的“高级”命令jhsdb jinfo可以在不重启进程的情况下获取完整的JVM参数。许多线上环境没开日志我常用jhsdb jinfo --flags pid看当前生效的参数然后对比分析。性能调优的终极哲学减少对象所有调优文章的结尾都会回到原点——最好的垃圾回收就是没有垃圾。这不是在鼓励你使用基本类型数组不放堆而是说每一次对象分配都要有“税收意识”。一个典型的优化案例某个日志框架每秒写10万行日志每个日志行都new了一个StringBuilder里面append时间戳、线程名、消息最后调用toString。我们意识到99%的日志都在DEBUG级别而生产环境日志级别是INFO所以大量日志根本不会输出。解决方案在拼接日志之前先判断日志级别避免无谓的对象创建。if(logger.isDebugEnabled()) { logger.debug(...) }这行代码减少了90%的Young GC频率。另一个常见场景是缓存中的重复对象。如果一个订单对象被多个线程并发读取每个线程都new一个Order对象来存储查询结果实际上可以共享不可变对象。使用享元模式Flyweight或者让底层存储返回不可变视图而不是每次都复制全量字段。最后记住一个公式GC暂停时间 ≈ 存活对象大小 拷贝系数 / 带宽。堆越大存活对象越多GC暂停时间越长。所以调优的本质是缩小存活集live set。把你代码中的每个对象都想象成银行存款——你存得越多银行JVM在处理每个客户GC时就越慢。当你把30%的缓存换成弱引用WeakHashMap当你让临时对象死在栈上当你减少了无谓的字符串拼接你会发现内存管理和垃圾回收策略的调优到最后不过是一场与“懒人本能”的博弈。而你每次写的new SomeObject()都是在给垃圾回收器打工。问题是你想当老板还是永远当那个996的打工仔