1. 为什么我们需要JVM调优？
第一次在生产环境遇到JVM性能问题时，我盯着监控面板上那条不断攀升的内存曲线，手心全是汗。那是一个普通的周二下午，我们的订单系统突然开始出现间歇性卡顿，而当时距离618大促只有两周时间。这就是我真正开始系统学习JVM调优的契机——当理论遇上现实的火花。
JVM调优本质上是在做三件事：第一是让应用跑得更快（吞吐量），第二是让应用停顿更少（延迟），第三是让应用更稳定（避免OOM）。听起来简单，但每个目标背后都有一整本故事书那么厚的知识点。比如你调整了新生代大小，可能改善了GC频率，却导致单次GC时间变长；你增加了堆内存，可能缓解了OOM，却引来了更长的Full GC。
重要提示：在没有明确性能问题指标前就开始调优，就像在没有诊断报告时就开药——可能适得其反。
2. JVM内存模型：调优的地基
2.1 运行时数据区详解
JVM内存模型就像一栋精心设计的公寓楼，每个区域都有特定用途。堆内存是最大的共享空间，存放所有对象实例；方法区存储类信息、常量等元数据；虚拟机栈、本地方法栈和程序计数器则是线程私有的工作空间。
最常出问题的就是堆内存，它又分为：
- 新生代（Young Generation）：新对象的摇篮，分为Eden区和两个Survivor区
- 老年代（Old Generation）：长期存活对象的养老院
- 元空间（Metaspace）：JDK8取代永久代的存在
// 通过代码验证内存分配 public class MemoryAllocation { public static void main(String[] args) { byte[] allocation1 = new byte[28000*1024]; // 直接进入老年代 } }2.2 指针碰撞与空闲列表
当我们需要在堆中创建新对象时，JVM有两种内存分配策略：
- 指针碰撞（Bump the Pointer）：适用于规整的内存布局，简单移动指针即可
- 空闲列表（Free List）：适用于不连续内存，需要维护可用内存块列表
选择哪种方式取决于垃圾收集器的选择。比如Serial、ParNew等收集器采用指针碰撞，而CMS这类基于标记-清除算法的收集器则使用空闲列表。
3. 垃圾收集器：JVM的清洁工团队
3.1 主流收集器对比
下表是常见收集器的特性对比：
| 收集器 | 算法 | 适用区域 | 线程 | 特点 |
|---|---|---|---|---|
| Serial | 复制 | 新生代 | 单线程 | 简单高效，适合客户端 |
| ParNew | 复制 | 新生代 | 多线程 | Serial的多线程版 |
| Parallel Scavenge | 复制 | 新生代 | 多线程 | 吞吐量优先 |
| Serial Old | 标记-整理 | 老年代 | 单线程 | Serial的老年代版 |
| Parallel Old | 标记-整理 | 老年代 | 多线程 | Parallel Scavenge的老年代搭档 |
| CMS | 标记-清除 | 老年代 | 多线程 | 低延迟优先 |
| G1 | 分区算法 | 全堆 | 多线程 | 平衡型，JDK9默认 |
| ZGC | 染色指针 | 全堆 | 多线程 | 超低延迟 |
3.2 CMS收集器的三色标记
CMS收集器的工作过程就像垃圾分类：
- 初始标记（Stop The World）：快速标记GC Roots直接关联对象
- 并发标记：与用户线程并行，遍历对象图
- 重新标记（Stop The World）：修正并发标记期间的变动
- 并发清除：清理垃圾对象
# 启用CMS的JVM参数示例 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly4. 实战调优：从参数到监控
4.1 基础参数设置
一个电商应用的典型配置：
-Xms4g -Xmx4g # 堆大小固定避免动态调整开销 -XX:NewRatio=2 # 新生代与老年代比例 -XX:SurvivorRatio=8 # Eden与Survivor区比例 -XX:+UseG1GC # 使用G1收集器 -XX:MaxGCPauseMillis=200 # 目标暂停时间 -XX:InitiatingHeapOccupancyPercent=45 # 触发并发GC的堆占用率4.2 监控工具链
- jps：查看Java进程
jps -lvm - jstat：实时监控GC情况
jstat -gcutil <pid> 1000 10 - jmap：堆内存分析
jmap -histo:live <pid> | head -20 - VisualVM：图形化分析工具
- Arthas：线上诊断神器
5. 常见问题排查手册
5.1 CPU飙升问题
排查步骤：
- top命令找到高CPU进程
- top -Hp 定位高CPU线程
- printf "%x\n" 转换线程ID为16进制
- jstack | grep -A 20 查看线程栈
5.2 OOM问题
不同类型OOM的应对策略：
- Java heap space：增加堆大小或查找内存泄漏
- GC overhead limit exceeded：优化GC策略或代码
- Metaspace：调整-XX:MaxMetaspaceSize
- Unable to create new native thread：减少线程数或调整系统限制
6. 高级调优技巧
6.1 逃逸分析与栈上分配
JVM会分析对象作用域，对于未逃逸出方法外的对象，可能直接在栈上分配，减少GC压力。可以通过-XX:+DoEscapeAnalysis开启（默认开启）。
// 适合栈上分配的例子 public void method() { User user = new User(); // 未逃逸对象 user.setName("test"); System.out.println(user.getName()); }6.2 大对象直接进入老年代
通过-XX:PretenureSizeThreshold参数可以设置大对象的阈值（仅对Serial和ParNew收集器有效）。
-XX:PretenureSizeThreshold=3145728 # 3MB以上的对象直接分配在老年代7. 时区问题：那些年踩过的坑
在JDBC连接MySQL时，时区不一致会导致时间字段出现令人困惑的偏差。解决方法：
// JDBC连接字符串添加时区参数 jdbc:mysql://localhost:3306/db?serverTimezone=Asia/Shanghai同时确保JVM时区配置正确：
-Duser.timezone=GMT+088. 我的调优心得
经过多次线上事故的洗礼，我总结了三条黄金法则：
- 调优前先收集足够的数据指标，没有监控就不要调优
- 每次只改变一个参数，并记录前后对比
- 生产环境变更要走灰度发布，准备好回滚方案
最深刻的教训来自一次盲目增加新生代大小的操作。原本想减少Minor GC频率，结果导致单次GC时间翻倍，反而让接口超时增多。后来通过G1收集器的Region设计完美解决了这个问题——这就是为什么理解原理比记住参数更重要。