企业官网建设流程全解析

1. 堆为什么是JVM内存结构里最该先啃下来的那块

1.1 一次凌晨告警引出的问题

线上服务平稳跑了三个月，某天凌晨监控开始疯狂推送告警，接口平均响应从八十毫秒一路涨到三秒多，紧接着日志里刷出一行java.lang.OutOfMemoryError: Java heap space。值班的同学第一反应是"机器内存不够了"，于是把容器内存从4G调到8G，重启，服务恢复。一周之后同样的报错又出现了，这次等了四十分钟才恢复，业务方已经打电话来问情况。这个场景在不少团队里都发生过，问题不在于调大内存对不对，而在于只调大内存，等于把问题往后推，而不是解决它。

JVM内存结构这个话题里，堆(Heap)是最容易被"知道"却最少被"真正理解"的一块。很多人能背出"堆是线程共享的、存放对象实例、是GC的主要区域"，但一到线上问题就发现这些结论不够用：为什么老年代一直涨？为什么Full GC之后内存没降下来？为什么配了8G堆还是OOM？这些问题都要求你把堆的内部结构、对象流转路径、参数之间的耦合关系捋清楚。这篇内容就是按这个思路走的——从分代设计的动机讲起，把对象从创建到回收的完整链路拆开，再把参数配置和排查手段落到能直接抄的程度。适合已经写过Java、想搞清楚运行时到底发生了什么的中级开发者，也适合被OOM和GC问题反复折腾的后端同学。

1.2 堆在运行时数据区中的位置与职责

先把坐标定准。JVM运行时数据区大致分成线程私有的程序计数器、虚拟机栈、本地方法栈，以及线程共享的堆和方法区(JDK 8之后由元空间Metaspace承接)。堆的职责非常明确：几乎所有对象实例和数组都在这里分配内存。注意"几乎"两个字，随着逃逸分析成熟，一部分对象可以在栈上分配或者被标量替换掉，但这是编译器优化的结果，不是你写代码时能依赖的常态。

堆的两条硬性特征决定了它的所有后续设计。第一，它是线程共享的，所以分配时必然存在并发竞争，这直接引出了TLAB(Thread Local Allocation Buffer)这套机制。第二，它是GC的主战场，所有分代、回收算法、参数调优，本质都是在回答"怎么用更小的停顿回收更多的垃圾"。理解了这两点，后面看到的各种设计就不会觉得是拍脑袋定的。

还有一个常被忽略的细节：堆在物理上可以不连续，只要逻辑上连续即可，这是它能弹性伸缩的基础。-Xms和-Xmx分别控制初始容量和最大容量，两者设成一样是生产环境的常规操作，原因在后面的参数章节会展开讲。

注意：方法区在JDK 8之前叫永久代(PermGen)，属于堆的一部分，JDK 8之后改为元空间并移出堆，用的是本地内存。如果你看到老资料说"永久代在堆里"，那不是错的，只是版本不对。

2. 分代设计：不是为了好看，是为了让回收更划算

2.1 弱分代假说与分代边界的由来

要理解堆为什么要分成新生代和老年代，得先接受一个经验规律：绝大多数对象都是朝生夕死的。这个规律在业界被称为弱分代假说(Weak Generational Hypothesis)，它不是定理，是大量实际系统统计出来的结论。Web请求里创建的DTO、临时拼接的字符串、方法内部的局部集合，生命周期往往只有毫秒级，方法一返回就没人引用了。

这个规律带来一个很实际的经济账。假设堆有4G，如果每次GC都要扫描全部4G，哪怕用最快的算法，停顿也压不下来。但如果把新创建的对象集中放在一块较小的区域(新生代)，每次只回收这块，扫描范围立刻缩小一个数量级。而真正活得久的对象(缓存、连接池、单例、Spring容器里的Bean)挪到另一块区域(老年代)，回收频率可以低很多。分代的本质是用"对象的年龄"给回收工作分级，把高频但低成本的活和低频但高成本的活分开干。

这里有三个容易混淆的概念需要先厘清。新生代(Young Generation)存放刚创建的对象，老年代(Old Generation/Tenured)存放熬过多次回收的对象。这两块加起来才是整个堆，别把新生代当成堆之外的独立区域。至于永久代/元空间，它们存放类元数据、常量池这些东西，不是对象实例，不在分代回收的主线上。

2.2 新生代的三区结构与复制算法

新生代内部又分成三块：Eden区和两个Survivor区，习惯上叫S0和S1或者From和To。默认比例是Eden : S0 : S1 = 8 : 1 : 1，由-XX:SurvivorRatio=8控制。为什么是这个比例？因为Survivor区的作用是"临时中转"，绝大多数对象在第一次Minor GC时就已经死了，真正需要在中转区停留的只是少数。把Eden做大，能让更多对象在Eden里就死掉，减少复制开销。

回收过程是这样的：新对象优先在Eden分配，Eden满了触发Minor GC，此时把Eden和当前正在用的Survivor(From)里还活着的对象，一次性复制到另一个空的Survivor(To)，然后把Eden和From整体清空。下一轮GC时，To变成From，原来的From变成To，两个Survivor角色互换。任意时刻只有一个Survivor有数据，另一个永远是空的，这一点非常关键，它保证了复制算法不需要额外的空闲空间做标记整理。

为什么新生代选复制算法而不是标记清除？因为新生代存活率低，通常不到10%，复制算法只需要搬运少量存活对象，代价极小；而且复制之后内存是连续的，没有碎片，分配时用指针碰撞(Bump the Pointer)一条指令就能完成，速度极快。反过来，如果新生代用标记清除，每次回收都会产生碎片，分配时还得维护空闲列表，得不偿失。

代价也很明显：Survivor区要浪费一块空间。默认配置下新生代只有90%的空间可用(Eden 80% + 一个Survivor 10%)。这块"浪费"是设计上的必要成本，不是配置失误。

2.3 老年代与标记整理、空间分配担保

老年代存放的是熬过多次Minor GC的对象。这里的对象存活率高，用复制算法就不划算了——假设存活率80%，复制算法要搬运80%的数据，还得预留同样大的空闲空间，直接崩盘。所以老年代一般用标记整理(Mark-Compact)或者标记清除(Mark-Sweep)，前者会移动对象消除碎片，后者不移动但会产生碎片。

与之配套的是空间分配担保机制。Minor GC之前，JVM必须先确认一件事：如果新生代里所有对象都活下来，老年代装不装得下？装不下就得提前触发一次Full GC腾地方。JDK 6u24之后，这个判断简化成：只要老年代的连续可用空间大于新生代所有对象总大小，或者大于历次晋升对象的平均大小，就可以放心做Minor GC，否则先做Full GC。这套逻辑解释了为什么有时候你只看到Minor GC的日志，紧接着就出现Full GC——那是担保失败触发的。

还有一个跨代引用的坑。老年代对象可能引用新生代对象，如果Minor GC只扫描新生代，就会漏掉这些引用，误杀活对象。解决办法是卡表(Card Table)：把老年代切成一个个固定大小的卡页，只要老年代对象引用了新生代对象，就把对应的卡标记为脏，Minor GC时只扫描脏卡对应的内存区域，不用遍历整个老年代。这就是所谓的记忆集(Remembered Set)思想。

实操心得：如果你的应用Full GC频率远高于预期，先别急着调参数，看看是不是有大批对象在Minor GC后几乎全部存活。这种情况说明新生代太小或者对象创建速率异常，调大新生代往往比调老年代更有效。

3. 对象的一生：从分配到晋升再到回收

3.1 分配路径与TLAB机制

对象创建时的内存分配，第一步不是直接进Eden，而是要解决并发安全问题。多个线程同时new对象，如果都用同一个指针碰撞，必然要加锁，性能直接垮掉。JVM的解法是TLAB(Thread Local Allocation Buffer)：在Eden区里给每个线程划一小块私有区域，线程在自己的TLAB里分配不需要任何同步。TLAB默认开启(-XX:+UseTLAB)，大小由JVM自适应调整，也可以用-XX:TLABSize指定初始值。

分配流程大致是这样的：先尝试在TLAB内部分配，空间够就直接返回；不够就申请一个新的TLAB；如果Eden剩余空间也不够新建TLAB，就在Eden的共享区域做一次带CAS的分配；再失败才触发Minor GC。这个大对象在TLAB里放不下的情况很常见，所以别以为开了TLAB就完全没有同步开销。

再往前一步，还有个逃逸分析(Escape Analysis)在起作用。如果JIT编译器分析出某个对象只在方法内部使用、不会逃逸到方法外，就可能把它拆散成若干标量直接放在栈上(标量替换)，或者干脆在栈上分配。这就是为什么有时候你没看到堆增长但对象确实创建了。不过逃逸分析依赖JIT编译，解释执行阶段不生效，而且分析本身有成本，所以它只是优化手段，不能作为你设计代码的依据。

3.2 晋升年龄与动态年龄判定

对象在Survivor之间每复制一次，年龄加一。年龄达到阈值就晋升老年代，这个阈值由-XX:MaxTenuringThreshold控制，默认15(因为对象头里存年龄的字段只有4位，最大值就是15)。CMS收集器下默认是6，因为CMS的老年代回收压力大，希望对象尽早过去。

但实际晋升并不完全按这个阈值走，还有一个动态年龄判定：如果在Survivor中，某个年龄及以下的所有对象大小总和超过了Survivor空间的一半，那么年龄大于等于这个值的对象直接晋升老年代，不用等到15。这个机制的初衷是避免Survivor被塞满导致对象频繁在两个Survivor之间来回复制。它的副作用是晋升时机变得不可预测，有时候你会看到一批"本不该这么早晋升"的对象跑到了老年代。

这就解释了为什么调优时SurvivorRatio很关键。Survivor设得太小，动态年龄判定会早早触发，大量对象提前晋升，老年代增长过快，Full GC频率上升；设得太大，Eden被压缩，Minor GC次数变多。这个平衡点没有普适答案，得看你的对象存活分布。

3.3 大对象直接进老年代与空间分配担保的联动

有一类对象不走常规路径——大对象。超过-XX:PretenureSizeThreshold阈值的对象直接在老年代分配，绕开新生代。原因是复制算法搬运大对象代价太高，一来一回可能顶得上好几次普通GC的开销。注意这个参数只对Serial和ParNew这类收集器有效，G1和ZGC的行为不同，不要生搬硬套。

典型的大对象包括长数组、大字符串、大的缓存条目。实际项目里见过最坑的一种是byte[]：某服务读取文件流时用了readAllBytes()，单个请求可能产生几十MB的数组，直接冲进老年代，导致老年代迅速膨胀。改成流式处理分块读取之后，问题立刻缓解。

最后串一下完整的对象生命周期：在Eden创建 → Minor GC后存活对象进S0 → 下次GC时S0存活对象复制到S1并年龄+1 → 反复在两个Survivor之间倒腾 → 年龄到阈值或触发动态年龄判定 → 晋升老年代 → 老年代满触发Full GC → 标记整理回收。整条链路上任何一环参数配错，最终都会表现为GC异常或者OOM。

4. 堆参数配置：从死记硬背到会算

4.1 核心参数速查表

参数配置最怕的是背了一堆参数却不知道它们之间怎么相互影响。下面这张表先建立基本印象，重点在后面的计算部分。

表格里有个容易踩的坑：-Xmn和-XX:NewRatio同时设置时，-Xmn优先级更高，NewRatio会被忽略。还有人以为-XX:MetaspaceSize是元空间的初始大小，其实它是"第一次触发元空间GC的阈值"，设小了会导致应用启动阶段频繁Full GC。

4.2 新生代比例与Survivor的实际可用空间

这里必须把账算清楚，因为很多"配了4G堆却只能用3G"的疑惑都出在这。假设-Xmx=4G，-XX:NewRatio=2，那么新生代 = 4G / (1+2) ≈ 1.33G，老年代 ≈ 2.67G。再往下，新生代里按SurvivorRatio=8分：Eden = 1.33G × 8/10 ≈ 1.07G，S0 = S1 ≈ 0.13G。

也就是说，新生代实际能用的只有Eden加一个Survivor，约1.2G，另外0.13G是常驻空闲的。如果你的应用创建对象速率极高，Minor GC会比你预期频繁得多。这时候增大SurvivorRatio(比如16)能扩大Eden，但Survivor会进一步缩小，动态年龄判定更容易触发，可能适得其反。

我的经验是先用默认值跑起来，通过jstat观察Eden的填充速率和Survivor的使用情况，再决定往哪个方向调。盲目拍一个"经验值"往往适得其反。

4.3 一个完整的容量计算实例

假设某服务部署在8核16G的容器里，堆计划给8G，采用ParNew + CMS组合，目标是Minor GC停顿控制在50ms内，Full GC尽量少。配置思路如下。

第一步定总堆。容器16G，堆给8G，剩下8G留给元空间、直接内存、线程栈、JVM自身开销以及操作系统的页缓存。-Xms8g -Xmx8g，两者相等避免运行期堆伸缩带来的额外GC。

第二步定新生代。ParNew下新生代太小会导致Minor GC频繁，太大会拉长单次停顿。经验上单次Minor GC停顿与存活对象数量成正比，8G堆给2.5G到3G新生代比较常见。这里设-Xmn3g，即新生代约3G，老年代5G。

第三步算Survivor。新生代3G，SurvivorRatio=8时Eden约2.4G，每个Survivor约300M。如果观察到jstat输出里S区使用率经常超过50%，说明存活对象偏多，可以考虑把比例调到6，让Survivor大一些。

第四步定元空间和直接内存。-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m，用NIO的服务再加-XX:MaxDirectMemorySize=1g。加起来8G + 0.5G + 1G = 9.5G，仍在16G以内，剩下6.5G留给其他部分，是安全的。

把这套配置写进启动脚本后，用jstat -gcutil <pid> 1000观察半小时，重点是看FGC那列有没有增长、老年代使用率(OU)在Full GC后是否回落到低位。如果回落后又快速爬升，那说明有对象在持续泄漏，参数再怎么调都没用。

提示：容器环境下必须用JDK 8u191及以上版本，并确认-XX:+UseContainerSupport生效(该版本后默认开启)。老版本JVM读不到cgroup限制，会按宿主机内存算默认堆大小，直接导致容器被OOM Killer干掉。

5. 排查定位：把"感觉内存不够"变成有据可查

5.1 常用工具的适用场景

排查堆问题，工具不在多而在用对。jps用来找进程号，是所有操作的起点。jstat -gcutil <pid> <间隔ms>是日常观察的主力，输出里S0、S1、E、O、M分别是两个Survivor、Eden、老年代、元空间的使用百分比，YGC/YGCT是新生代GC次数和总耗时，FGC/FGCT是老年代GC次数和总耗时。看一眼FGC的增长速度，基本就能判断问题严重程度。

jmap -histo:live <pid>能列出存活对象的数量和大小，按类型排序。注意加:live会强制触发一次Full GC，生产环境慎用，不加的话统计的是所有对象(包括垃圾)，数据参考价值有限。更稳妥的方式是jmap -dump:format=b,file=heap.hprof <pid>导出堆转储，拿到本地用MAT或者VisualVM分析，能看到对象的引用链，这才是定位泄漏的正道。

jstack是排查死锁和线程阻塞的，和堆内存问题不是一回事，但经常配合使用——比如某个线程持有大对象不放，从堆上看是对象一直存活，从栈上看才知道是谁拿着。

Arthas这类在线诊断工具在不能重启的场景下很好用，dashboard能实时看GC和内存，heapdump能按需导出。它的优势是不用提前配置JMX参数，但要注意它对性能有一定影响，排查完就退出。

5.2 典型场景与排查思路对照表

表格里最后一行值得多说一句。堆不是越大越好。堆越大，单次Full GC要扫描的对象越多，停顿越长。一个16G的堆，Full GC停顿可能到好几秒，这对在线服务是致命的。所以低延迟场景反而要控制堆大小，或者换成G1、ZGC这类能分区域回收、把停顿压到毫秒级的收集器。

5.3 内存泄漏和内存溢出的区别

这两个词经常被混用，但成因完全不同。内存溢出(OOM)是结果——堆确实装不下了。内存泄漏是原因之一——对象该被回收却因为被引用而无法回收。但也存在"不是泄漏的OOM"：比如一次性把十G的数据读进内存，或者并发量突增导致瞬时对象量暴涨，这种情况下没有对象"赖着不走"，只是量太大。

区分方法很直接：看Full GC之后老年代使用率。如果GC后回落到正常水平，然后慢慢涨上去，多半是泄漏；如果GC后依然很高，涨得又快又急，那更可能是瞬时压力或者单次大分配。前者要修代码，后者要调容量或限流。

我曾遇到过一个案例：某服务用了本地ConcurrentHashMap做缓存，key是用户ID，没有淘汰策略，日活涨上去以后map越来越大，Full GC后内存几乎不降。MAT里看支配树，最大的对象就是这个map。改成有容量上限的本地缓存并加上过期时间，问题解决。这件事给我的教训是：任何无上限的容器，在生产环境都是定时炸弹。

注意：导出heap dump会暂停应用(具体停顿时间取决于堆大小和磁盘速度)，生产环境导dump前先摘掉流量或者选低峰期。另外要确认磁盘空间足够，dump文件大小通常接近堆的实际使用量。

6. 那些文档里不会写的坑

6.1 参数层面的常见误区

第一个坑是把-Xms设得比-Xmx小，指望JVM自动扩容。这在测试环境没感觉，生产环境会导致堆反复伸缩，每次扩容都伴随Full GC，而且扩容后不一定缩回去，反而更容易触发OOM。生产环境直接两个值设成一样。

第二个坑是看见OOM就加内存。加到物理内存上限之后，问题会以更糟糕的形式出现——容器被OOM Killer杀掉，连线程栈都来不及打。正确的顺序是先确认是泄漏还是容量不足，再决定加内存还是改代码。

第三个坑是忽略元空间。JDK 8之后元空间默认没有上限，用CGLIB动态生成大量代理类、或者热部署频繁的应用，元空间会一直涨，最终耗尽物理内存。-XX:MaxMetaspaceSize必须设，一般给256M到512M。

第四个坑是直接内存。NIO的ByteBuffer.allocateDirect分配的内存不在堆里，-Xmx管不到它，但会占用物理内存。如果不设-XX:MaxDirectMemorySize，默认等于堆最大值，两者叠加很容易超容器限制。

6.2 容器环境的特殊处理

容器里跑JVM有一堆额外的坑。早期版本JVM按宿主机内存算默认堆大小，假设宿主机128G、容器限制4G，JVM会算出32G的默认最大堆，结果容器一启动就被杀掉。JDK 8u191之后默认开启容器感知，会读取cgroup的限制，但如果你在启动参数里写死了-Xmx，那就以你的参数为准，照样可能超限。

另一个细节是/proc/meminfo在容器里显示的可能是宿主机的数据，一些监控脚本会误判。判断容器的真实限制要看/sys/fs/cgroup/memory/memory.limit_in_bytes。另外JDK 10之后有-XX:MaxRAMPercentage，可以按容器内存的百分比设堆大小，比如-XX:MaxRAMPercentage=60.0表示用容器内存的60%做堆，比写死绝对值更适应不同规格的部署。

6.3 长期运维中沉淀的几条经验

第一条，GC日志必须开。-Xloggc:/path/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps，这些参数在出问题时就是唯一的现场记录。日志轮转也要配，不然几个月就把磁盘写满。很多团队出问题时才发现没开GC日志，只能靠猜，代价太大。

第二条，监控要盯趋势而不是绝对值。堆使用率70%不一定有问题，关键看它在Full GC后能不能回到低位、上涨斜率是否稳定。我习惯关注三个指标：Full GC频率、Full GC后老年代占用、单次Full GC耗时。这三个稳定，堆基本就是健康的。

第三条，别迷信调参。绝大多数堆问题的根因在代码：缓存没上限、批量查询没分页、大对象反复创建、流没关闭。参数调优能缓解症状，但把无上限的缓存调成"涨得慢一点的缓存"，只是在延后爆炸时间。

第四条，升级收集器比调参数更有效。如果一个服务堆在8G以上、对停顿敏感，与其在CMS上反复折腾，不如评估G1。G1把堆分成大小相等的Region，能根据停顿目标动态选择回收哪些Region，配置-XX:MaxGCPauseMillis=200之后，它会自己想办法达成目标，比手工算新生代比例省心得多。当然迁移前要压测验证，G1在超大堆和特定分配模式下表现不一定比老收集器好。

最后再分享一个排查小技巧：当你不确定某个对象为什么活着，用jmap -histo:live找到类的实例数量，再配合jstack看哪个线程正在处理这类对象，往往能快速锁定。这一步比直接导几个G的dump再慢慢分析要快得多，尤其适合线上紧急止血的场景。