Jvm on Liangweidong's blog

JVM调优常用参数

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.4 JVM调优常用参数

考察意图：能否根据实际场景选择合适的JVM参数，而非无脑复制粘贴。

回答样板：

基础内存参数：

参数	含义	常见设置
`-Xms` / `-Xmx`	初始/最大堆大小	建议设为相同值，避免堆动态扩缩带来的GC抖动。4G服务通常 `-Xms4g -Xmx4g`
`-Xss`	线程栈大小	默认1MB。线程数多且调用栈浅可缩小（512k），递归深可加大
`-XX:NewRatio`	老年代:新生代比例	默认2（Old=堆的2/3，Young=1/3）。高并发短命对象可调为1
`-XX:SurvivorRatio`	Eden:Survivor比例	默认8（Eden:S0:S1=8:1:1）。大多数场景不需改
`-XX:MaxTenuringThreshold`	晋升老年代年龄阈值	默认15（CMS默认6）。值小则对象快速晋升但可能过早填满老年代
`-XX:MetaspaceSize` / `-XX:MaxMetaspaceSize`	元空间初始/最大大小	默认无上限（受物理内存限制）。动态生成类多的场景建议设上限防泄漏。典型256m-512m

GC日志参数：

1
2
3
4
5
6
7
8


# JDK 8 经典三件套
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log
-XX:+PrintHeapAtGC # GC前后打印堆快照（排查内存泄漏利器）
-XX:+PrintTenuringDistribution # 打印各年龄段的存活对象分布

# JDK 9+ 统一日志
-Xlog:gc*=info:file=/path/to/gc.log:time,level,tags:filecount=10,filesize=100M
# gc* 表示所有GC相关日志，info级别，滚动10个文件每个100MB

OOM排查必开：

参数	作用
`-XX:+HeapDumpOnOutOfMemoryError`	OOM时自动dump堆快照，生产环境必须开
`-XX:HeapDumpPath=/path/to/dumps`	dump文件路径，防止撑爆根目录
`-XX:OnOutOfMemoryError="kill -9 %p"`	OOM时执行自定义命令（注意安全隐患）

G1调优参数：

参数	含义	建议
`-XX:MaxGCPauseMillis`	期望最大停顿时间	默认200ms，不要设太低（比如10ms）——G1达不到会疯狂GC反而性能下降。服务端通常50-200ms
`-XX:G1HeapRegionSize`	Region大小	默认堆/2048，取值1/2/4/8/16/32M。大对象多可调大
`-XX:ConcGCThreads`	并发GC线程数	默认≈CPU核数的1/4。CPU资源紧张时减半
`-XX:InitiatingHeapOccupancyPercent`	触发并发标记的堆占用阈值	默认45%。堆占用达此值触发并发标记周期。值设太低频繁GC浪费CPU，太高预留不够触发Full GC

真实配置示例——安全生产平台（JDK 8, 4核8G）：

1
2
3
4
5
6
7
8
9


-Xms4g -Xmx4g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=100
-XX:G1HeapRegionSize=4m
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/logs/dumps
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/logs/gc-%t.log
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=50M

陷阱提示：把线上配置直接复制粘贴但说不清每个参数的业务取舍原因；设 MaxGCPauseMillis=10显得不专业；不知道生产环境必须开HeapDumpOnOutOfMemoryError。

JVM调优工具实战

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.5 JVM调优工具实战

考察意图：能否独立的在生产环境排查问题，使用合适的工具定位根因。

回答样板：

Arthas——线上诊断神器：

阿里开源的Java诊断工具，零侵入，直接attach到运行中的Java进程，线上排查首选。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 启动
java -jar arthas-boot.jar
# 选择目标Java进程即可

# 最常用命令
dashboard # 实时看板：线程/内存/GC/CPU
thread -n 5 # CPU最高的5个线程
thread -b # 找出死锁
jad com.xx.MyService # 反编译已加载的类，验证线上版本
watch com.xx.MyService myMethod "{params,returnObj,throwExp}" -x 3 # 监控方法入参/出参/异常
trace com.xx.MyService myMethod -n 5 # 追踪方法调用链路，找出哪个子步骤耗时最长
tt -t com.xx.MyService myMethod # 记录方法调用（TimeTunnel），支持重放
vmoption # 查看JVM参数
vmtool --action getInstances -c com.xx.MyClass --limit 10 # 获取堆中某类实例
monitor -c 5 com.xx.MyService myMethod # 监控方法调用次数/成功率/平均耗时

实际场景：一次线上接口变慢，用Arthas的trace一追踪，发现是下游规则引擎的Drools session创建占了80%耗时——KieSession没做池化每次new一个。加了KieSession对象池后恢复。

JDK自带工具——四件套：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# jps —— 列出Java进程
jps -lv # 列出所有Java进程，显示JVM参数和main类

# jstat —— JVM统计监控（实时看GC）
jstat -gcutil PID 1000 10 # 每秒打印一次GC统计，共10次
# 输出关键列：S0/S1(Eden+Survivor使用率), E(eden), O(old), M(metaspace), YGC/YGCT(youngGC次数/耗时), FGC/FGCT(fullGC)
# 解读：FGC频繁 + FGCT高 → 老年代不足或内存泄漏
# E接近100%然后骤降 → 正常Minor GC
# O持续增长不降 → 内存泄漏信号

# jmap —— 堆内存分析
jmap -heap PID # 堆内存概览（各区域大小和使用率）
jmap -histo:live PID | head -20 # 堆中存活对象统计（top 20，强制执行一次Full GC）
jmap -dump:format=b,file=heap.hprof PID # 堆dump（生产慎用，会STW）

# jstack —— 线程堆栈分析
jstack PID > thread.log # 打印线程堆栈
jstack -l PID # 额外打印锁信息
# grep查找：BLOCKED（锁等待）/ WAITING（等待唤醒）/ TIMED_WAITING（超时等待）/ RUNNABLE（正在执行）
# 看线程名：如果全是http-nio-xxx-WAITING → 数据库或下游服务慢

MAT（Memory Analyzer Tool）——堆dump分析：

1
2
3
4
5
6


# 先用 jmap dump 堆快照，然后用MAT打开分析
# MAT直接点"Leak Suspects Report" → 自动分析内存泄漏嫌疑
# 核心操作：
# 1. Histogram：按类统计对象数量和内存占用，找大对象
# 2. Dominator Tree：支配树——最大的内存持有者
# 3. Path to GC Roots：某个对象为什么没被回收（引用链追溯到GC Root）

实际场景：OOM排查，MAT打开dump→ Dominator Tree发现HashMap占3.2GB→ Path to GC Roots找到是定时任务的全量缓存→改成分页+本地缓存解决。

jinfo——查看/修改JVM运行时参数：

1
2


jinfo -flags PID # 查看所有参数（包括默认值）
jinfo -flag +PrintGC PID # 运行时动态开启GC日志（部分参数支持动态修改）

生产环境排查最佳路径：

遇到CPU飙升 → Arthas dashboard + thread -n 5 → 定位到具体线程 → jad反编译验证 → 改代码
遇到内存泄漏 → jstat -gcutil观察O区持续增长 → jmap -dump → MAT分析Dominator Tree → Path to GC Roots → 改代码
遇到死锁 → jstack -l → 搜DEADLOCK → 或Arthas thread -b
遇到接口变慢 → Arthas trace → 定位最耗时的子调用 → 深入分析

陷阱提示：只会用jps/jstat但说不清每列含义；线上 jmap -dump不提醒STW风险；不知道Arthas的attach机制（VirtualMachine.attach不需要Agent）。

JVM调优实战案例

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.6 JVM调优实战案例

考察意图：验证完整的排查→定位→解决→验证闭环能力。

案例一：定时任务导致Full GC：

危废平台上线后，每周固定时间接口响应从200ms飙升到5秒以上。排查：jstat -gcutil看发现老年代每周末凌晨突增 → jmap -dump堆内存用MAT分析 → Dominator Tree发现HashMap缓了几百万条危废联单数据 → 根因是定时任务没做分页，一次load全量数据。解决方案不是调JVM参数，而是改代码——Caffeine本地缓存（最大条目+过期时间），定时任务改分批。改完后Full GC停顿从1.2秒降到100ms以内。教训：JVM调优很多时候改代码比改参数更有效。

案例二：Metaspace溢出：

生产环境切流量后运行12小时左右突然 OOM: Metaspace。排查：jstat -gcutil看MU（Metaspace使用率）接近100% → jmap -clstats看加载的类数量异常高（正常几千，它几百万）→ Arthas vmtool查看发现大量 com.sun.proxy.$ProxyXXX类 → 定位到Groovy脚本引擎每次执行规则都 new GroovyClassLoader()但没关 → ClassLoader泄漏导致反复加载同类→ Metaspace撑爆。解决：GroovyClassLoader改单例复用，加 -XX:MaxMetaspaceSize=256m兜底限流。

案例三：G1停顿时间优化：

G1 GC后P99延迟偶尔飙到800ms。排查GC日志发现Mixed GC的Cleanup阶段耗时400ms——老年代Region中大对象过多。-XX:G1HeapRegionSize从2MB调到4MB（让大对象进Humongous Region而非普通Old Region），加上 -XX:+ParallelRefProcEnabled并行处理Reference对象，-XX:MaxGCPauseMillis=100让G1自动收紧回收范围。优化后P99压到300ms以内。

陷阱提示：只讲成功案例不讲失败教训；编造数据（面试官可能现场让你画内存布局图）。

JVM类型对比（HotSpot / OpenJ9 / GraalVM）

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.7 JVM类型对比（HotSpot / OpenJ9 / GraalVM）

考察意图：是否了解JVM生态的多样性，能根据场景推荐合适的JVM实现。

回答样板：

主流JVM实现有三个阵营：

HotSpot VM——Oracle/OpenJDK默认，绝对主流

市场份额：Java服务端90%+在用
核心优势：**C2编译器（Server Compiler）**做了二十多年极致优化，逃逸分析、内联、循环优化极其成熟；G1/ZGC等现代回收器最先落地；生态最完整
JDK 8起HotSpot与JRockit合并，吸收了JRockit的Mission Control、Flight Recorder（JFR）等运维工具
劣势：启动慢、内存占用高——Spring Boot应用空跑也要200MB+堆。不适合短生命周期场景（Serverless、FaaS）

OpenJ9（Eclipse OpenJ9）——IBM捐献，低内存场景

前身是IBM J9 VM，2017年捐给Eclipse基金会
核心优势：极低内存占用——同等应用比HotSpot少30-50%内存；启动速度快；Shared Classes Cache（SCC）——AOT编译缓存，多次启动复用编译结果
垃圾回收：GenCon（分代并发，类似G1）+ Balanced（针对大堆）+ Metronome（实时GC，可配置停顿上限）
劣势：生态和工具链不如HotSpot完善，部分框架兼容性问题；G1/ZGC等效方案不如HotSpot成熟
适用场景：云原生/Serverless（启动快、内存省）、微服务容器化部署（每个Pod省200MB很可观）、嵌入式设备

GraalVM——多语言+AOT编译

Oracle实验室项目，定位是"通用虚拟机"——不止跑Java，还能跑JavaScript、Python、Ruby、R、WASM
两大杀手级特性：
- Native Image（AOT编译）：将Java应用编译为独立二进制，毫秒级启动、内存占用几十MB，非常适合Serverless和容器化。Spring Boot 3.0+官方支持GraalVM Native Image
- Truffle框架：多语言互调用，Java代码直接调Python/JS函数，零JNI开销
两种模式：Community Edition（免费，Native Image支持有限）+ Enterprise Edition（收费，Native Image+PGO优化+多语言商业支持）
劣势：AOT编译限制——限制反射/动态代理/动态类加载（需要配置 reflect-config.json等元数据）；编译时间长（小项目几分钟，大项目几十分钟）；闭包分析可能漏掉运行时动态行为导致编译失败
适用场景：Serverless/FaaS（毫秒级冷启动）、CLI工具、嵌入式、微服务容器镜像瘦身

场景选型速览：

场景	推荐JVM	原因
传统服务端/企业应用	HotSpot	生态成熟、性能最稳定、GC方案最丰富
云原生/容器化微服务	OpenJ9 或 GraalVM	内存省、启动快、镜像小
Serverless/FaaS	GraalVM Native Image	毫秒启动、极低内存
多语言混合项目	GraalVM Truffle	Java+Python/JS/R互调
嵌入式/IoT	OpenJ9	内存占用可控
实时响应（金融/交易）	HotSpot + ZGC	亚毫秒停顿

陷阱提示：只知道HotSpot不知道有其他JVM实现；把GraalVM说成"就是编译成二进制的"忽略了多语言和Truffle；不知道GraalVM Native Image的限制（反射配置、编译时间）。

JVM内存模型

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.1 JVM内存模型

考察意图：是否理解各内存区域的职责、存储内容、以及OOM的发生场景。

回答样板：

JVM运行时数据区分为线程私有和线程共享两大类，共5个核心区域：

区域	共享性	存储内容	OOM场景
程序计数器	线程私有	当前线程执行的字节码行号指示器	唯一不会OOM的区域
虚拟机栈	线程私有	栈帧（局部变量表+操作数栈+动态链接+返回地址）	线程过多或递归过深：StackOverflowError
本地方法栈	线程私有	Native方法的栈帧	与虚拟机栈类似
堆（Heap）	线程共享	对象实例、数组	对象过多且GC无法回收：java.lang.OutOfMemoryError: Java heap space
方法区（元空间）	线程共享	类元数据、静态变量、常量池、JIT编译缓存	动态生成类过多或常量池溢出：OOM: Metaspace

JDK 8关键变化——永久代→元空间：

JDK 7及之前，方法区用永久代（PermGen）实现，属于JVM堆内存的一部分，受-XX:MaxPermSize限制。JDK 8移除了永久代，改用本地内存中的元空间（Metaspace），默认只受物理内存限制。好处：之前永久代大小难以预估（加载的类数量不确定），经常导致OOM: PermGen space。改用元空间后，类元数据放在堆外的本地内存，容量弹性更大。但风险是——如果不设-XX:MaxMetaspaceSize，动态类加载失控会吃光物理内存。

堆内存分代结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


┌───────────────────────────────────────────┐
│ 堆 (Heap) │
├─────────────────┬─────────────────────────┤
│ 新生代(Young) │ 老年代(Old) │
│ ┌────┬────┬───┐│ │
│ │Eden│ S0 │ S1││ │
│ │ 8 │ 1 │ 1 ││ │
│ └────┴────┴───┘│ │
│ 默认比例 8:1:1 │ │
├─────────────────┴─────────────────────────┤
│ 新生代:老年代 ≈ 1:2 (默认 NewRatio=2) │
└───────────────────────────────────────────┘

新生代：新创建的对象。Eden区（80%）+ Survivor 0（10%）+ Survivor 1（10%）
老年代：长期存活对象。经历多次Minor GC仍存活的对象晋升至此
对象晋升流程：Eden分配 → 首次Minor GC存活进S区 → 每次Minor GC存活Age+1 → Age达到MaxTenuringThreshold（默认15）→ 晋升老年代。动态年龄判定：S区中同龄对象总大小超过S区50%时，该年龄及以上对象直接晋升

为什么需要两个Survivor区？ 解决内存碎片化——每次Minor GC，将Eden+From Survivor存活对象copy到To Survivor，然后清空Eden和From，From和To角色互换。始终保持一块Survivor为空，避免碎片化。这就是复制算法在新生代的落地。

陷阱提示：说不清各个区域存什么；把方法区和元空间等同（元空间是实现，方法区是规范）；不知道永久代→元空间的JDK 8变化。

垃圾回收算法

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.2 垃圾回收算法

考察意图：理解各算法的原理、优缺点和适用分代，能结合业务场景说明选型理由。

回答样板：

四种基础算法，JVM根据分代特性组合使用：

1. 标记-清除（Mark-Sweep）——最基础

流程：标记阶段遍历GC Roots标记存活对象 → 清除阶段回收未标记对象
优点：算法简单，不移动对象
缺点：内存碎片化——清除后产生大量不连续的空闲内存。碎片严重时，即使总空闲内存足够，也可能无法分配大对象，触发Full GC
适用：老年代的基础算法（CMS的标记-清除阶段）

2. 标记-复制（Mark-Copy）——新生代首选

流程：将存活对象复制到另一块空白区域 → 原区域整块清空
优点：无内存碎片，整块清空效率极高，只需移动存活对象
缺点：浪费50%空间（需要一块空白区域做副本）。不过新生代对象98%朝生夕死，实际只需要很小的Survivor空间
适用：新生代Minor GC。8:1:1的Eden:Survivor比例就是基于这个假设——Survivor只需要留新生代10%的空间。如果Survivor不够放存活对象，通过分配担保机制直接晋升老年代

3. 标记-整理（Mark-Compact）——老年代兜底

流程：标记存活对象 → 将所有存活对象移到内存一端 → 清理边界外的内存
优点：无内存碎片，不需要浪费额外空间
缺点：移动对象需要STW，且需要更新所有指向被移动对象的引用——停顿时间与堆中存活对象数量成正比
适用：老年代（Serial Old、Parallel Old）

4. 分代收集（Generational Collection）——JVM的顶层策略

不是独立算法，而是"不同分代用不同算法"的策略组合
核心假设：弱分代假说——绝大多数对象朝生夕死（新生代用复制算法）；强分代假说——熬过多次GC的对象一般不会轻易死亡（老年代用标记-清除/标记-整理）
几乎所有JVM垃圾回收器都基于分代假设设计

记忆集（Remembered Set）与卡表（Card Table）：

分代收集的致命问题：跨代引用。新生代对象被老年代引用时，Minor GC只扫新生代，无法通过GC Roots找到这个老年代引用，导致存活新生代对象被误清。解决方案：老年代维护一张卡表——将老年代内存按512字节分块（Card），有老年代引用指向新生代时，对应Card标记为"脏"。Minor GC扫描时除了GC Roots还扫描卡表中的脏Card，避免全堆扫描。CMS和G1都在写屏障（Write Barrier）中维护这张卡表，性能开销约5%-10%。

陷阱提示：四种算法的优缺点和应用分代背串；不知道跨代引用问题和卡表机制；以为复制算法就是新生代的全部。