在现代服务系统中，JVM 并不是一个"自动解决一切"的黑盒。
JVM 调优的本质，不是让 JVM 更快，而是让业务在资源约束下更稳定地达成目标。
JVM 自动内存管理解决的是 "对象生命周期管理" 问题，而不是 "业务性能保证" 问题。 一旦业务规模、并发模型、数据形态发生变化，默认策略就不再一定适配。
因此，调优的起点永远不在 JVM，而在业务。
所有 JVM 调优，都围绕两个不可消除、只能取舍的目标函数展开：
单位时间内，系统用于有效业务计算的比例
本质表达为：
吞吐量 = 用户代码执行时间 /（用户代码执行时间 + 垃圾回收时间）
吞吐量优先的系统通常具备以下特征：
用户可感知的最长暂停时间
响应时间敏感系统的核心诉求是：
吞吐量与响应时间天然对立，无法同时最优。
这是 GC “吞吐 / 延迟 / 内存”不可能三角（物理约束，与 RUM 猜想同构，权威源见 垃圾回收.html 「衡量 GC 的三大指标」）在调优目标上的投影：调优只能沿三角选一个取舍点，不能消除三角本身。
JVM 调优不是寻找“最强 GC”，而是为业务选择最合适的取舍点。
“GC = 可替换算法策略的组合体”这一本质，及各收集器（Serial / Parallel / CMS / G1 / ZGC）的机制定位，权威源见 垃圾回收.html 「垃圾收集器 = 策略组合体」。本篇不复述机制，只把“策略组合”转化为调优可操作的选型维度：
| 维度 | 核心问题 |
|---|---|
| 对象生命周期 | 对象是否呈现“朝生夕死”的分布 |
| 停顿模型 | 是否允许 STW |
| 并发能力 | 是否允许 GC 与用户线程并发 |
| 压缩策略 | 是否接受额外 CPU 换内存连续性 |
| 预测能力 | 是否能提前预估回收成本 |
不同 GC 只是 策略组合的不同实例；调优即在这五个维度上为业务选定组合。
分代的三条经验假说（弱 / 强分代、跨代引用）及其机制，权威源见 垃圾回收.html 「分代与对象行为假说」。本篇不复述，只取其调优推论：
分代收益依赖“大多数对象朝生夕灭”这一假设成立。
当假设不成立（大对象、缓存型、会话型业务），对象被过早晋升，GC 显著恶化：
GC 表现差，往往不是 GC 的问题，而是对象生命周期与分代假设不匹配。
因此调优的核心动作不是换 GC，而是验证业务的对象生命周期是否符合分代假设。
脱离业务目标谈 JVM 参数，本质是在制造技术噪音。
调优必须回答三个问题：
业务目标
↓
运行假设（对象分配、生命周期、并发模型）
↓
指标观测（CPU / 内存 / GC / 延迟）
↓
行为解释（为什么会这样）
↓
策略调整（GC / 架构 / 代码）
↑
└──────────反馈验证──────────┘
⚠️ 调优的核心能力不是“调参数”，而是“验证假设”。
CPU 飙高必须拆解为两个问题：
从 JVM 视角，CPU 消耗主要来源于：
调优目标不是“降 CPU”，而是减少无效计算。
内存异常增长通常意味着：
JVM 不会制造内存泄漏，只会暴露设计缺陷。
监控不是为了“看数值”，而是为了：
没有监控，调优就只能靠“感觉”。
| 特征 | 描述 |
|---|---|
| 表现 | 内存持续增长 |
| 根因 | 集合无容量上限 |
| 本质 | 生命周期设计错误 |
| 治理 | 引入淘汰策略 / 上限 |
| 特征 | 描述 |
|---|---|
| 表现 | OOM / 堆积 |
| 根因 | 背压缺失 |
| 本质 | 系统节奏失衡 |
| 治理 | 限流 / 队列 / 异步 |
| 特征 | 描述 |
|---|---|
| 表现 | Direct OOM |
| 根因 | 非托管资源 |
| 本质 | JVM 无法感知 |
| 治理 | 显式释放 / 统一管理 |
| 特征 | 描述 |
|---|---|
| 表现 | STW 时间异常 |
| 根因 | 非协作式线程 |
| 本质 | 安全点不可达 |
| 治理 | 避免长时间无 safepoint 代码 |
该问题表面是：
但根因并不在 GC。
真正的问题是：
GC 只是忠实地执行了你的对象语义。
JVM 调优正在发生结构性转变：
| 过去 | 现在 |
|---|---|
| 调参数 | 调模型 |
| 看 GC | 看业务行为 |
| 经验驱动 | 可观测性驱动 |
| JVM 问题 | 内存架构问题 |
JVM 调优不是一门参数技术，而是一门系统设计能力。
它要求工程师同时理解：
GC 从来不是敌人，它只是系统真实状态的放大器。