1. 为什么Java开发者必须懂垃圾回收内存划分是理解GC的第一步先抛一个反直觉的结论JVM垃圾回收机制GC这个东西大多数Java开发者以为自己懂但一到线上出问题就抓瞎。Java和C最大的区别就在于内存管理——C程序员自己malloc自己freeJava程序员只管new回收的事全部交给GC。但交给GC不等于不用管恰恰相反JDK从8到11再到17默认垃圾回收器换了一茬堆内存结构也一直在演进不懂底层原理的话连JVM参数都看不懂更别提调优了。文章开头先明确一个概念JVM的垃圾回收机制并不只是把没用的对象删掉这么简单。它涉及的是一整套内存管理方案包括JVM内存模型的区域划分、对象存活判定算法、回收策略与收集器实现。从jvm工作原理的角度看GC的性能直接决定了Java服务的RT响应时间和吞吐量。所以无论你是刚学Java的新手还是准备jvm面试题的老兵或者是被线上OOM折磨得头秃的运维同学这篇文章都会有用。在展开垃圾回收算法之前必须先搞清楚JVM把内存划分成了哪些区域因为垃圾回收的行为和这些区域强绑定。JVM内存模型大致分为这么几块堆Heap对象实例的出生地也是垃圾回收的主战场。堆又细分为新生代Young Generation和老年代Old Generation。虚拟机栈JVM Stack线程私有存放栈帧每个方法调用对应一个栈帧。栈帧里的局部变量表存的是引用reference不是对象本身。程序计数器PC Register线程私有记录当前线程执行的字节码行号不存在垃圾回收问题。方法区Method Area存储类元信息、常量、静态变量。JDK 8之后改成了元空间Metaspace用的是本地内存不再占用堆空间。本地方法栈Native Method Stack为Native方法服务。新手最容易搞混的一点垃圾回收不是全堆扫描一遍然后清垃圾而是分区域、分代来回收的。为什么这样设计你想想一个电商网站里创建了大量的订单对象、Session对象这些对象绝大多数生命周期很短创建出来用完就没人引用了。如果把它们和那些长期存活的对象比如Spring容器里的单例Bean、缓存对象混在一起统一回收那么每次GC都要全量扫描代价巨大。分代收集的核心思想就是把不同寿命的对象放在不同区域用不同的频率和算法去回收物尽其用。具体来说新生代里绝大多数对象活不过第一轮GC所以新生代的回收频率高、速度快用的是复制算法老年代里的对象都是老油条了回收频率低用的是标记-整理或标记-清除算法。这个设计是经过几十年实战检验的也是JVM垃圾回收机制里最重要的理论基础。顺带提一嘴我在做技术面试官的时候经常发现候选人把堆内存和JVM内存混为一谈。堆只是运行时数据区的一部分方法区、虚拟机栈这些不在堆里。你答jvm内存模型的时候如果直接说JVM内存就是堆和栈那基本告别及格线了。正确说法是堆、栈虚拟机栈本地方法栈、方法区、程序计数器各司其职其中堆是GC的主战场。2. 对象生死判定可达性分析绝不是简单的引用计数确定了回收区域之后下一个核心问题是垃圾回收器怎么知道一个对象到底能不能回收这一步叫对象存活判定。很多教科书会提到两种算法引用计数法和可达性分析。但现实是引用计数法我们只需要在面试题里知道它存在实际JVM里用的是可达性分析。为什么引用计数法有个致命缺陷——循环引用。2.1 引用计数法的死穴最简单的例子A对象持有B的引用B对象持有A的引用除此之外没有其他地方引用A和B了。按引用计数法的逻辑A被B引用所以计数不为0B被A引用所以计数也不为0这俩对象永远无法被回收。但实际上它们已经是死对象了外面没人再用它们。如果JVM用引用计数法这种互相抱团的对象就内存泄漏了。所以HotSpot VM根本没采用这种方式而是用可达性分析。2.2 可达性分析的完整逻辑可达性分析的核心从一组根节点GC Roots出发沿着引用链往下走能走到的对象就是存活的走不到的对象就是可以回收的。这个过程很像你在一个社交网络里从几个大V出发做BFS遍历能触达的人就是活跃用户触达不到的就是僵尸号。那哪些对象可以充当GC Roots这是面试高频考点也是理解jvm工作原理的关键虚拟机栈中局部变量表里的引用比如方法里的局部对象方法区中的静态变量引用static修饰的类变量方法区中的常量引用比如String常量池里的对象JNI本地方法栈中的引用所有被同步锁synchronized持有的对象有个很有意思的细节哪怕对象被可达性分析标记为不可达它也未必立刻被回收。JVM会先判断这个对象是否有必要执行finalize()方法。如果对象没有重写finalize()或者finalize()已经被调用过了那就直接回收。如果重写了且还没执行过JVM会把这个对象放到一个叫F-Queue的队列里由优先级很低的Finalizer线程去执行finalize()。这个机制本意是给对象最后一次自救机会但实际开发中我强烈建议你当作它不存在。原因有两点第一finalize()的执行时机不可控全靠GC心情第二在finalize()里做资源清理很容易出问题而且会影响GC性能。JDK 9开始finalize()已经被标记为废弃了所以别再把它当成正经技术用了。你只需要知道在finalize()里重新给对象赋一个GC Roots能引用的指针对象就活过来了但这种自救只有一次机会。2.3 四种引用类型没有哪个是多余的对象存活判定还和引用类型密切相关。Java提供了四种引用强度从强到弱分别是强引用StrongReference、软引用SoftReference、弱引用WeakReference、虚引用PhantomReference。强引用平时Object obj new Object()就是强引用。只要强引用还在GC永远不会回收。这是Java程序的默认形态也是内存泄漏的主要来源。软引用内存充足时不回收内存不足时在OOM之前回收。适合做缓存、内存敏感场景。比如MyBatis等框架的本地缓存就有用到软引用的场景。弱引用只要发生GC就回收不管内存够不够。典型应用是ThreadLocal的ThreadLocalMap里的Entry它的key就是弱引用。这个设计有讲究后文会讲它带来的内存泄漏问题。虚引用最弱的引用随时可能被回收。它唯一的作用是对象被回收时收到一个系统通知主要用来做堆外内存的回收管理比如NIO里的DirectByteBuffer。在实际编码里强引用和弱引用最容易踩坑。我举个实际场景你在一个长期存活的对象里放了一个大对象的强引用比如一个Map缓存了所有用户数据这个Map的生命周期和Application一样长那这个Map里的对象永远没法被回收时间一长就是OOM。我之前遇到过这样一个线上事故一个后台管理系统的导出功能每次导出都会把查询结果放到一个static的LinkedList里做缓存本意是防止重复查询结果这个List只往里加不往外删用户操作两三天后堆内存就直接打满老年代GC全量回收也救不回来。这种缓存其实就是内存泄漏排查过程就是用jmap dump堆然后分析一抓一个准。好明白了对象怎么算死、怎么算活接下来才能谈回收算法和垃圾回收器因为是先有判定标准后有回收策略。3. 分代收集新生代和老年代为什么要区别对待分代收集理论是整个JVM垃圾回收机制的实践基石。大部分面向对象语言Java、C#都采用了类似的思路。核心一句话概括根据对象存活周期的不同把堆分成新生代和老年代对不同区域采用不同的回收策略。C#垃圾回收机制也类似不过C#的代数机制和JVM略有差异这里我们只聊JVM。3.1 新生代的三块内存Eden、Survivor从区、Survivor到区新生代默认占堆内存的1/3老年代占2/3这个比例可以通过-XX:NewRatio调整。新生代内部又分为一块Eden区和两块Survivor区From和To默认比例是8:1:1用-XX:SurvivorRatio调。为什么是8:1:1因为经过大量统计发现新生代里大约90%的对象都是朝生暮死活不过第一轮GC。所以JVM设计了一种高效的复制算法新对象在Eden区出生。第一次Minor GC时把Eden区存活的对象复制到To区然后清空Eden区。下次GC时把EdenFrom区存活的对象复制到To区清空EdenFrom。周而复始From和To身份互换谁空谁是To。复制算法的代价是浪费一块Survivor区作为交换空间但换来的好处是没有内存碎片速度也快。看到这块你可能会问如果Survivor区装不下存活对象怎么办那就触发分配担保把装不下的对象提前晋升到老年代。这和银行贷款担保的逻辑一样新生代担保人老年代接盘。检查对象存活条件对象每度过一轮Minor GC年龄加1默认到15岁就晋升老年代-XX:MaxTenuringThreshold。但这不是唯一晋升条件大对象-XX:PretenureSizeThreshold指定的阈值会直接在老年代分配因为大对象在新生代来回复制太消耗性能。3.2 老年代的回收机制标记-清除和标记-整理老年代的GC叫Major GC也叫Full GC。老年代里对象存活率高复制算法代价太大所以采用了不同的算法。标记-清除Mark-Sweep先标记出需要回收的对象然后统一回收。最大的问题就是内存碎片——回收之后内存东一块西一块等下次要分配一个大对象时明明总空间够但找不到一块连续空间又被迫提前触发Full GC性能雪崩。标记-整理Mark-Compact先标记需要回收的对象然后让所有存活对象往一端移动然后直接清理掉端边界以外的内存。这样解决了碎片问题但移动对象的成本更高而且减慢用户线程Stop The World时间更长。现代垃圾回收器在老年代处理上各有取舍后面讲收集器时会展开。3.3 Stop The WorldGC的代价从哪来无论哪种收集器在做回收时都无法避免一个现象Stop The WorldSTW。也就是说GC线程执行时应用的其他用户线程必须暂停。有人会问为什么要暂停不能让GC线程和应用线程同时跑吗原因是如果应用线程在GC期间继续运行、继续修改对象引用关系那么GC标记的结果可能刚标记完就过期了——我标记A对象是死的结果下一秒另一个线程又把A对象赋值给了某个root变量那我都来不及重新标记就把A回收了程序直接崩溃。所以要么暂停应用要么GC结果不可靠。Java靠STW保证一致性代价就是停顿。GC发展史的核心线索其实就是一部如何把STW时间压到最短的历史。从Serial一秒级别到Parallel多线程并行到CMS并发标记尽量不暂停再到G1把堆切成Region、能做到可预测的停顿时间最后到ZGC把STW压到毫秒甚至微秒级。这一路下来目标没变思路一代比一代精巧。如果你用jstat -gcutil观察过一个Java应用你会发现一次Full GC往往会伴随着应用RT飙升、请求超时。那种感觉就是STW的实感。所以各大厂做jvm调优时重点指标就是Minor GC频率、Full GC频率和单次停顿时长。4. 收集器大乱斗Serial、Parallel、CMS、G1再到ZGC谁在什么场景胜出垃圾回收器是算法的具体实现。JDK不同版本默认收集器不一样JDK 8默认Parallel Scavenge Parallel OldJDK 11和JDK 17默认G1。很多人问到底该怎么选答案永远取决于你的业务诉求——是要吞吐量还是要低延迟。4.1 经典四兄弟Serial、Serial Old、Parallel、Parallel OldSerial收集器是最老的单线程工作。它在进行垃圾回收时必须暂停所有工作线程只用一个GC线程回收。它简单高效但只在Client模式下有优势。Serial Old是Serial的老年代版本两者配合就是单线程打包方案。Parallel收集器JDK 8默认也叫吞吐量优先收集器。它把GC线程并行化了能充分利用多核CPU适合对吞吐量有要求但对停顿时间不敏感的场景比如后台批处理系统、离线计算任务。配合的-XX:ParallelGCThreads设置GC线程数-XX:MaxGCPauseMillis可以设置期望的最大停顿。这里有个容易误解的点把期望停顿时间设得越小越好不是。JVM会为了满足这个目标动态调整堆大小片面的调小会导致GC频率变高整体吞吐反而下降。调优要在吞吐量和停顿之间找平衡点别指望一个参数解决所有问题。4.2 CMS并发标记清除的传奇与退场CMSConcurrent Mark Sweep是JVM史上第一款并发收集器目标就是低停顿。它的老年代回收过程拆成了四个阶段初始标记CMS initial markSTW但只标记GC Roots能直接关联到的对象很快。并发标记CMS concurrent mark和应用线程同时跑从GC Roots做可达性分析耗时较长但不阻塞业务。重新标记CMS remarkSTW修正并发标记期间因用户线程继续运行而产生变动的对象记录这也要停顿时间也不短。并发清除CMS concurrent sweep和应用线程同时跑清理垃圾。听起来很棒对不对但CMS有三个致命伤CPU敏感并发阶段对CPU资源有抢占在CPU核数较少的机器上CMS会导致应用吞吐量明显下降。浮动垃圾并发清理阶段用户线程还在跑会不断产生新的垃圾这些垃圾只能等下次GC再处理。所以CMS不能等内存满了才回收要留一部分空间给并发阶段使用-XX:CMSInitiatingOccupancyFraction默认68%内存使用率达到68%就触发CMS GC。空间碎片CMS用标记-清除算法天生会产生碎片。碎片积累到一定程度老年代明明空间还不少却分配不出连续空间给大对象JVM会退化成Serial Old做一次Full GC 碎片整理那停顿时间直接起飞。CMS在JDK 9被标记废弃JDK 14被正式移除。官方推荐替换方案就是G1。现在网上很多老教程还在让你用CMS调参如果你用的是JDK 11请直接对标G1别再抱着CMS的理论写不切实际的经验了。4.3 G1从JDK 9后的新一代默认王者G1Garbage First把堆划分成了一个个大小相等的Region默认约2048个每个Region在逻辑上可以独立是Eden、Survivor、Old区。它不再要求新生代和老年代物理连续所以能用一种统一的方式同时管理年轻代和老年代。G1最核心的设计是它可以设定一个可预测的停顿时间目标比如-XX:MaxGCPauseMillis200G1会在这个目标时间内从回收收益最高的Region开始回收。这就是Garbage First命名的由来——优先处理垃圾最多的Region。这个过程需要维护一张记忆集Remembered Set来记录跨Region引用靠写屏障Write Barrier来更新。G1也用了并发标记、SATBSnapshot-At-The-Beginning等机制来减少停顿。使用G1时我建议你重点关注这几个参数-XX:MaxGCPauseMillis停顿目标默认200ms。-XX:G1HeapRegionSizeRegion大小默认根据堆大小自动计算。-XX:InitiatingHeapOccupancyPercentIHOP触发并发GC的堆占用百分比默认45%。实测下来G1对大堆比如堆内存超过4GB和多核环境优化非常好但对小堆、小内存环境反而可能比Parallel还慢。所以如果你的应用堆只有512MB跑批处理性质的任务用G1不见得优于Parallel。4.4 ZGC和Shenandoah低延迟时代的物种ZGCJDK 11引入实验JDK 15转正的目标是把STW时间控制在10ms以内无论堆多大。它用染色指针Colored Pointer、读屏障等非常激进的机制在应用线程运行的同时并发做几乎所有GC阶段包括并发标记、并发转移、并发重映射。但ZGC不是银弹它有一个很明显的特点为了换取极低的停顿它牺牲了一部分吞吐量。对于高并发低延迟的在线业务比如网关、实时交易ZGC是很好的选择但如果你的应用是计算密集型的批处理吞吐量下降的影响会非常直接。到了JDK 17时代ZGC已经进入生产可用状态很多互联网公司已经在线上跑ZGC了。不过我要提醒一句不要为了追新技术而换收集器换之前用压测和模拟流量验证收集器这类基础设施切换永远要把稳定性放在第一位。下面用一个表格总结几代收集器的定位差异收集器工作模式适用场景核心缺点当前状态Serial/Serial Old单线程STW客户端小应用停顿时间长老古董Parallel/Parallel Old多线程STW吞吐优先的批处理停顿不可控JDK 8默认CMS并发标记清除低延迟应用碎片、CPU敏感JDK 14已移除G1分Region并发回收大堆低延迟小内存环境收益低JDK 9默认ZGC并发全流程超低延迟大堆吞吐量下降JDK 15转正5. 用日志和命令工具把GC拉出黑盒jstat、jmap、jstack与GC日志排查实战说完了原理和收集器下面聊点真正能在生产环境救命的东西怎么用工具观察GC行为。很多开发者的jvm调优知识停留在调一个-Xmx参数的层面真的就太可惜了。调优的第一步永远不是改参数而是采集数据、发现规律。5.1 开启GC日志的正确姿势排查GC问题第一步是打印GC日志。不同的JDK版本日志参数还不一样这个坑特别值得强调。JDK 8及以前-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintHeapAtGC -Xloggc:/path/to/gc.logJDK 9及以上日志参数统一改成了-Xlog-Xlog:gc*:/path/to/gc.log:time,uptime,level,tags注意在JDK 11环境里再用-XX:PrintGCDetailsJVM会直接忽略或者启动报错因为参数名已经变了。这种新版本里老参数失效的问题是升级JDK后最常遇到的。GC日志本身读起来并不复杂。拿一次Minor GC日志举例关键信息就几个GC前后的堆占用比如2208K-389K、耗时0.0009054 secs、以及allocation failure这类触发原因。看日志时你需要关注的是Minor GC的频率有没有异常升高每次GC后存活对象有没有快速增长Full GC是不是频繁被触发这些问题都能反映内存压力的真实水平和趋势。5.2 监控与堆转储三件套除了日志JVM本身自带了一套命令行监控工具在jvm调优工具的清单里这几个最常用jps查看当前机器上所有Java进程的PID。这是所有排查工作的起点。jps -ljstat看JVM运行统计信息是排查GC性能最核心的工具。常用组合jstat -gcutil pid 1000 10这条命令每秒输出一次GC统计共10次。输出里的S0/S1是Survivor区的使用率E是Eden区使用率O是老年代使用率M是元空间使用率YGC/YGCT是Young GC次数和累计耗时FGC/FGCT是Full GC次数和累计耗时。如果你观察到FGC的数字在快速上涨说明老年代一直在触发Full GC老年代空间压力极大。而YGCT增速快说明Minor GC的STW已经明显拖垮应用。jmap导出堆转储快照。这个工具用起来要格外小心在生产环境谨慎使用因为dump堆的过程会触发STW影响线上业务。一般建议在低峰期操作或者优先考虑用阿里开源的Arthas进行在线排查避免直接dump。jmap -dump:live,formatb,fileheap.bin pidjstack输出线程快照。排查死锁、线程卡死、CPU飙高问题的利器。配合top -Hp找准线程ID后转16进制在jstack输出里搜索nid就能定位到是哪个线程出问题。jvisualvm / JConsole图形化监控工具适合本地开发环境使用可以看到堆内存、GC数据的实时曲线。Arthas阿里巴巴开源的Java诊断工具强烈推荐每一位Java开发者在本地装上。它能在不重启应用的情况下在线查看类加载信息、方法调用耗时、甚至反编译线上代码排查OOM时极其有用。它的dashboard命令能看到实时的内存和线程概况heapdump命令能在线导出堆快照。5.3 一次真实OOM的排查复盘我讲一个自己的线上排查经历给你一个完整链路参考。现象某个订单服务在业务高峰时段请求超时率飙升团队收到大量告警日志里出现了java.lang.OutOfMemoryError: Java heap space。我的排查顺序是确认现象先把报错堆栈翻出来确认是heap空间OOM不是元空间、不是栈溢出、不是直接内存。这个区分太关键了因为不同区域的OOM对应完全不同的解决思路。采集GC指标执行jstat -gcutil pid 1000发现老年代使用率一直在95%以上且FGC次数持续增长说明老年代空间确实打满了。看GC日志翻看gc.log发现每间隔几分钟就出现一次Full GC且每次Full GC后老年代占用只能降一点点是典型的回收不动状态——说明老年代里有大量对象是存活的没有被正常回收。dump堆在确认影响可控的窗口期用jmap -dump:live导出堆快照再用MATMemory Analyzer Tool分析。定位泄漏点MAT的Leak Suspects报告显示一个名为RequestContext的对象占用了80%以上的堆内存被一个static final的ThreadLocal持有。顺着引用链查下去发现是某个拦截器在请求进栈时往ThreadLocal里塞了全量请求参数但是拦截器的afterCompletion方法里没有执行remove()Tomcat的工作线程是复用的下一次请求还会复用这条线程而它的ThreadLocalMap里的Entry的key是弱引用value却是强引用——线程存活期间value永远无法回收。于是每个请求压进来ThreadLocalMap都被塞进一份大对象线程池规模越大内存增长越快日积月累直接打爆。修复在afterCompletion中显式调用remove()清理上线后观察GC指标老年代占用恢复平稳Full GC频率从每几分钟一次降到每天几次。这个故事里的核心教训有两个。第一ThreadLocal务必在finally块里remove否则在高并发、线程复用的容器Tomcat、Jetty里必出内存泄漏。第二排查OOM要做数据驱动每一步都用工具确认而不是靠猜。很多人一看到OOM就急着加大堆内存结果治标不治本内存泄漏的根还在那里加多少都是给它续命而已。6. 日常开发里的GC陷阱从IDEA内存设置到线程池配置最后一章专门讲开发过程中最常遇到的几个GC相关实际问题。这些细节看起来很小但每一件都在真实地影响你的开发效率和线上稳定性。6.1 IDEA的OOM问题真不是JetBrains的锅不少同学用IDEA开发时遇到OutOfMemoryError: Java heap space第一反应是加内存。IDEA本身是Java写的它的JVM内存配置在安装目录的idea.vmoptions文件里常见设置为-Xms和-Xmx。修改方式很简单Help - Edit Custom VM Options然后把-Xmx调大比如-Xmx2048m或者-Xmx4096m。但我要说的是调整IDEA内存之前先看看你的机器总内存和项目规模。如果你8G内存开一堆微服务应用IDEA分配2G、Spring Boot应用每个再吃掉几百兆其他应用直接没内存了。真正的合理做法是IDEA只分配够用的内存比如-Xmx2g同时把启动时不需要加载的插件禁用掉给其他进程多留空间。换机器扩容内存是更根本的解法而不是在一个内存紧张的机器上挤压每个JVM进程的空间。另外IDEA里跑单元测试或本地启动Spring Boot时也经常会OOM这种情况的根因很可能是-Xmx太小但也可能是JDK版本升级后默认GC行为变了。比如从JDK 8切到JDK 11默认收集器从Parallel变成G1G1启动初期对Region的划分和记忆集的维护会占用一部分额外内存你没调大堆的话反而更容易OOM。6.2 线程池最大线程数等于JVM剩余线程数别被热词带偏网上有个说法线程池设置最大线程数是JVM剩余可用线程。这个观点我不止一次在网上看到但它是被过度简化甚至带偏的。线程池的大小设置和JVM可用线程数压根不是一回事。JVM能创建多少线程取决于操作系统层面的资源限制比如Linux下ulimit -u限定的进程最大线程数也取决于每个线程默认的栈大小-Xss默认1MB而不是某个JVM剩余线程数的指标。线程池大小设计的目标通常是围绕CPU密集型还是IO密集型选型CPU密集型设CPU核心数1IO密集型设CPU核心数 * 2或者更高配合队列长度来调。网上那些一行公式在特定业务场景下可能勉强能用但你要真按它设我建议先做压测验证而不是盲信结论。有一个冷知识倒是和GC有关每创建一个线程JVM会在堆外为线程栈分配内存同时也可能在堆内分配线程对象。如果线程池开得巨大堆满后也会触发OOM。所以线程池参数和GC参数其实是有联动的——线程数过大会加剧内存压力间接引发GC次数上升。6.3 G1和ZGC时代的调优落地建议最后给一个务实的jvm调优结论不要把调优想成几个参数搞定一切。真正的调优是三步走搞清楚当前状态用jstat和GC日志掌握GC频率、堆占用、停顿时间的现状。确定核心目标你的业务是要吞吐量还是要低延迟选收集器和参数时目标要统一。单变量改变验证效果每次只改一个参数放在压测环境里跑用数据对比调优前后的差异。针对大多数微服务应用我提供一个相对稳妥的起步模板还没细化看数据之前的基线不是最终配置java -Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/这个模板的要点-Xms和-Xmx设为相同值避免JVM在运行过程中动态扩缩容引发不稳定的GC表现加上HeapDumpOnOutOfMemoryError可以保证OOM发生的那一刻自动留下堆快照这是事后排查最重要的证据。根据我个人的经验真正的jvm调优很少一上来就追求极致参数多数情况只是确认三件事堆设置合理、没有明显内存泄漏、GC频率在可接受范围内。如果你已经把这三件事用工具验证过那你的JVM已经比绝大多数线上服务稳了。剩下的就是业务代码的质量问题了——毕竟最贵的垃圾回收机制也回收不掉程序员自己写的逻辑问题。