企业官网建设流程全解析

1. 为什么Java开发者必须懂垃圾回收：内存划分是理解GC的第一步

先抛一个反直觉的结论：JVM垃圾回收机制（GC）这个东西，大多数Java开发者以为自己懂，但一到线上出问题就抓瞎。Java和C++最大的区别就在于内存管理——C++程序员自己malloc自己free，Java程序员只管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引用所以计数不为0，B被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设计了一种高效的复制算法：

1. 新对象在Eden区出生。
2. 第一次Minor GC时，把Eden区存活的对象复制到To区，然后清空Eden区。
3. 下次GC时，把Eden+From区存活的对象复制到To区，清空Eden+From。
4. 周而复始，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 World：GC的代价从哪来

无论哪种收集器，在做回收时都无法避免一个现象：Stop The World（STW）。也就是说，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 Old，JDK 11和JDK 17默认G1。很多人问：到底该怎么选？答案永远取决于你的业务诉求——是要吞吐量，还是要低延迟。

4.1 经典四兄弟：Serial、Serial Old、Parallel、Parallel Old

Serial收集器是最老的，单线程工作。它在进行垃圾回收时，必须暂停所有工作线程，只用一个GC线程回收。它简单高效，但只在Client模式下有优势。Serial Old是Serial的老年代版本，两者配合就是"单线程打包"方案。

Parallel收集器（JDK 8默认），也叫吞吐量优先收集器。它把GC线程并行化了，能充分利用多核CPU，适合对吞吐量有要求但对停顿时间不敏感的场景，比如后台批处理系统、离线计算任务。配合的-XX:ParallelGCThreads设置GC线程数，-XX:MaxGCPauseMillis可以设置期望的最大停顿。这里有个容易误解的点：把期望停顿时间设得越小越好？不是。JVM会为了满足这个目标动态调整堆大小，片面的调小会导致GC频率变高，整体吞吐反而下降。调优要在吞吐量和停顿之间找平衡点，别指望一个参数解决所有问题。

4.2 CMS：并发标记清除的传奇与退场

CMS（Concurrent Mark Sweep）是JVM史上第一款并发收集器，目标就是低停顿。它的老年代回收过程拆成了四个阶段：

1. 初始标记（CMS initial mark）：STW，但只标记GC Roots能直接关联到的对象，很快。
2. 并发标记（CMS concurrent mark）：和应用线程同时跑，从GC Roots做可达性分析，耗时较长但不阻塞业务。
3. 重新标记（CMS remark）：STW，修正并发标记期间因用户线程继续运行而产生变动的对象记录，这也要停顿，时间也不短。
4. 并发清除（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后的新一代默认王者

G1（Garbage First）把堆划分成了一个个大小相等的Region（默认约2048个），每个Region在逻辑上可以独立是Eden、Survivor、Old区。它不再要求新生代和老年代物理连续，所以能用一种统一的方式同时管理年轻代和老年代。

G1最核心的设计是：它可以设定一个可预测的停顿时间目标，比如-XX:MaxGCPauseMillis=200，G1会在这个目标时间内，从回收收益最高的Region开始回收。这就是"Garbage First"命名的由来——优先处理垃圾最多的Region。

这个过程需要维护一张"记忆集（Remembered Set）"来记录跨Region引用，靠写屏障（Write Barrier）来更新。G1也用了并发标记、SATB（Snapshot-At-The-Beginning）等机制来减少停顿。

使用G1时，我建议你重点关注这几个参数：

• -XX:MaxGCPauseMillis：停顿目标，默认200ms。
• -XX:G1HeapRegionSize：Region大小，默认根据堆大小自动计算。
• -XX:InitiatingHeapOccupancyPercent（IHOP）：触发并发GC的堆占用百分比，默认45%。

实测下来，G1对大堆（比如堆内存超过4GB）和多核环境优化非常好，但对小堆、小内存环境反而可能比Parallel还慢。所以如果你的应用堆只有512MB，跑批处理性质的任务，用G1不见得优于Parallel。

4.4 ZGC和Shenandoah：低延迟时代的物种

ZGC（JDK 11引入实验，JDK 15转正）的目标是把STW时间控制在10ms以内，无论堆多大。它用染色指针（Colored Pointer）、读屏障等非常激进的机制，在应用线程运行的同时并发做几乎所有GC阶段，包括并发标记、并发转移、并发重映射。

但ZGC不是银弹，它有一个很明显的特点：为了换取极低的停顿，它牺牲了一部分吞吐量。对于高并发低延迟的在线业务（比如网关、实时交易），ZGC是很好的选择；但如果你的应用是计算密集型的批处理，吞吐量下降的影响会非常直接。

到了JDK 17时代，ZGC已经进入生产可用状态，很多互联网公司已经在线上跑ZGC了。不过我要提醒一句：不要为了追新技术而换收集器，换之前用压测和模拟流量验证，收集器这类基础设施切换，永远要把稳定性放在第一位。

下面用一个表格总结几代收集器的定位差异：

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.log

JDK 9及以上，日志参数统一改成了-Xlog：

-Xlog:gc*:/path/to/gc.log:time,uptime,level,tags

注意，在JDK 11+环境里再用-XX:+PrintGCDetails，JVM会直接忽略或者启动报错，因为参数名已经变了。这种"新版本里老参数失效"的问题是升级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 -l

jstat：看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,format=b,file=heap.bin <pid>

jstack：输出线程快照。排查死锁、线程卡死、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。

我的排查顺序是：

1. 确认现象：先把报错堆栈翻出来，确认是heap空间OOM，不是元空间、不是栈溢出、不是直接内存。这个区分太关键了，因为不同区域的OOM对应完全不同的解决思路。
2. 采集GC指标：执行jstat -gcutil <pid> 1000，发现老年代使用率一直在95%以上，且FGC次数持续增长，说明老年代空间确实打满了。
3. 看GC日志：翻看gc.log，发现每间隔几分钟就出现一次Full GC，且每次Full GC后老年代占用只能降一点点，是典型的"回收不动"状态——说明老年代里有大量对象是存活的，没有被正常回收。
4. dump堆：在确认影响可控的窗口期，用jmap -dump:live导出堆快照，再用MAT（Memory Analyzer Tool）分析。
5. 定位泄漏点：MAT的Leak Suspects报告显示，一个名为RequestContext的对象占用了80%以上的堆内存，被一个static final的ThreadLocal持有。顺着引用链查下去，发现是某个拦截器在请求进栈时往ThreadLocal里塞了全量请求参数，但是拦截器的afterCompletion方法里没有执行remove()；Tomcat的工作线程是复用的，下一次请求还会复用这条线程，而它的ThreadLocalMap里的Entry的key是弱引用，value却是强引用——线程存活期间value永远无法回收。于是每个请求压进来，ThreadLocalMap都被塞进一份大对象，线程池规模越大，内存增长越快，日积月累直接打爆。
6. 修复：在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变成G1，G1启动初期对Region的划分和记忆集的维护会占用一部分额外内存，你没调大堆的话反而更容易OOM。

6.2 线程池最大线程数等于JVM剩余线程数？别被热词带偏

网上有个说法："线程池设置最大线程数是JVM剩余可用线程"。这个观点我不止一次在网上看到，但它是被过度简化甚至带偏的。线程池的大小设置和JVM可用线程数压根不是一回事。

JVM能创建多少线程取决于操作系统层面的资源限制（比如Linux下ulimit -u限定的进程最大线程数），也取决于每个线程默认的栈大小（-Xss，默认1MB），而不是某个"JVM剩余线程数"的指标。线程池大小设计的目标，通常是围绕CPU密集型还是IO密集型选型：CPU密集型设CPU核心数+1，IO密集型设CPU核心数 * 2或者更高配合队列长度来调。网上那些"一行公式"在特定业务场景下可能勉强能用，但你要真按它设，我建议先做压测验证，而不是盲信结论。

有一个冷知识倒是和GC有关：每创建一个线程，JVM会在堆外为线程栈分配内存，同时也可能在堆内分配线程对象。如果线程池开得巨大，堆满后也会触发OOM。所以线程池参数和GC参数其实是有联动的——线程数过大会加剧内存压力，间接引发GC次数上升。

6.3 G1和ZGC时代的调优落地建议

最后给一个务实的jvm调优结论：不要把调优想成"几个参数搞定一切"。真正的调优是三步走：

1. 搞清楚当前状态：用jstat和GC日志掌握GC频率、堆占用、停顿时间的现状。
2. 确定核心目标：你的业务是要吞吐量，还是要低延迟？选收集器和参数时目标要统一。
3. 单变量改变，验证效果：每次只改一个参数，放在压测环境里跑，用数据对比调优前后的差异。

针对大多数微服务应用，我提供一个相对稳妥的起步模板（还没细化看数据之前的基线，不是最终配置）：

java -Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/

这个模板的要点：-Xms和-Xmx设为相同值，避免JVM在运行过程中动态扩缩容引发不稳定的GC表现；加上HeapDumpOnOutOfMemoryError，可以保证OOM发生的那一刻自动留下堆快照，这是事后排查最重要的证据。

根据我个人的经验，真正的jvm调优很少一上来就追求"极致参数"，多数情况只是确认三件事：堆设置合理、没有明显内存泄漏、GC频率在可接受范围内。如果你已经把这三件事用工具验证过，那你的JVM已经比绝大多数线上服务稳了。剩下的，就是业务代码的质量问题了——毕竟，最贵的垃圾回收机制，也回收不掉程序员自己写的逻辑问题。