直接答案：先测应用在真实数据和峰值请求下的CPU时间、堆工作集、Metaspace、线程栈、直接内存、GC暂停和连接池，再给操作系统、页缓存、代理和故障转储留空间。-Xmx不能等于机器内存；容器limit与JVM自动识别也需实际核对。连接池上限应由数据库可承载并发决定，不应随Web线程无限放大。
本文于 2026 年 9 月按官方文档核对。命令和配置只展示判断方法，不代表可在任意生产环境直接复制；发行版、云平台、网络拓扑和业务写入不同，执行前必须确认对象、权限、备份和带外恢复入口。
专属资产：JVM总内存预算与GC验收表
| 现象/阶段 | 要判断什么 | 需要的证据 | 安全边界 |
|---|---|---|---|
| Java Heap | 对象工作集 | used after GC、分配速率 | Xmx覆盖峰值并留余量 |
| Metaspace | 类元数据 | loaded classes与增长 | 热部署泄漏需定位 |
| Thread Stack | 每线程栈内存 | 线程数与-Xss | 线程暴增会耗内存 |
| Direct/Native | NIO、压缩、JNI | NMT/指标 | 不计入普通heap |
| GC Pause | 回收对尾延迟影响 | p95/p99和GC日志 | 吞吐与暂停权衡 |
这张表要求每个结论至少有两个相互独立的证据，例如“服务监听+外部连接”“设备延迟+业务耗时”“备份文件+隔离恢复”。单一控制台绿灯、单次截图或一个User-Agent都可能误导，不能作为完成依据。
为什么常见的一键处理容易失败
运维问题通常跨越控制台、操作系统、应用和外部依赖。重启、全放行、清缓存或重装会改变多个变量，并可能清掉最有价值的现场。正确顺序是先定时间线和影响范围，再确认最靠近故障的证据层，最后做可回滚的最小动作。
对于有数据库、订单、表单、队列或用户上传的站点，还要先判断当前是否仍在写入。回滚旧快照、切回旧主机或恢复旧数据库前，必须处理变更期间的新数据；否则技术状态恢复了，业务数据却可能倒退。
六步安全执行流程
1. 确认对象与基线
固定JDK、Spring Boot版本、启动参数和容器/主机限制，记录CPU型号、内存与镜像；不同JDK的默认GC和容器识别不能混比。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
2. 保留恢复入口
在真实数据副本做阶梯负载，采集进程RSS、堆使用、after-GC、分配率、线程、直接内存、GC暂停、CPU和p95/p99。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
3. 取得直接证据
建立总预算：Xmx+Metaspace+线程栈+直接/本地内存+代码缓存+故障转储空间，再加系统、代理和页缓存；观察值与上限都要考虑。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
4. 只做最小变更
检查Web线程、异步执行器、队列和Hikari池；线程与数据库连接不应一一放大，连接池过大会把排队移到数据库并增加锁竞争。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
5. 验证业务与副作用
先修对象泄漏、阻塞调用、慢SQL和无限队列，再调堆与GC。只扩大Xmx可能延长暂停或让宿主OOM杀进程。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
6. 重启或跨峰复验
上线采用健康/就绪探针和优雅停机，限制滚动批次；在相同峰值跨过GC周期、连接峰值和故障切换，确认无OOM、暂停和连接雪崩。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
不应直接照做的五种处理
- Xmx设置为全部机器内存
- 只看堆不看进程RSS
- 连接池等于Web线程数
- 无界队列隐藏过载
- 生产临时更换GC且无基线
这些做法并非永远错误，而是缺少适用条件。若确需执行，应在变更单中写清目标、影响范围、停止阈值、备份位置、回滚命令和预计恢复时间；高风险动作先在副本或小流量上演练。
回滚触发与数据边界
出现核心写入失败、持续5xx、管理员入口丢失、数据校验不一致、尾延迟越过停止阈值或监控失明时，应停止继续扩大变更。回滚前确认新旧环境各自产生了哪些写入，保留日志和配置差异；回滚后用相同请求和同一时间窗口重测，而不是只看首页恢复。
如果故障根因尚未确认但必须先恢复服务，可以采用限流、摘除单节点、恢复上一配置或临时切流等缓解措施，并明确它只是临时处置。恢复后仍要完成根因分析和复发验证，不能把“重启后正常”写成最终原因。
验收清单
- [ ] JDK与参数已归档
- [ ] 总内存预算闭合
- [ ] after-GC稳定
- [ ] 无持续线程增长
- [ ] GC尾延迟达标
- [ ] 连接池不饱和
- [ ] OOM转储空间可用
- [ ] 优雅停机和回滚通过
验收应由另一位维护者按记录复现至少一项关键检查，并覆盖重启、真实高峰或等价受控负载。所有失败项都记录实际值与时间，不使用“基本正常”“应该没问题”作为关闭条件。
相关资料与隔离测试入口
站内可继续参考内存容量计算、监控告警指南、CPU100排查。需要搭建副本验证配置时，可查看美国轻量云和美国弹性云服务器的实时规格；先确认库存、价格和适用条件，不把测试环境当备份或生产容灾。
常见问题
2核4G能跑Spring Boot吗？
能否稳定取决于应用工作集、线程、连接和峰值。小服务可运行，但必须在目标负载下测RSS、GC和尾延迟。
Xms和Xmx要设一样吗？
有助于减少扩堆变化，但会立即保留更大承诺并影响密度。是否相同应基于启动、稳态和故障策略测试。
GC次数多就是有问题吗？
不一定。短暂停顿的小回收可能正常，更应看总CPU、暂停分位数、吞吐和after-GC趋势。
为什么堆没满却被OOM Kill？
宿主或容器看的是总RSS/limit，还包括Metaspace、线程栈、直接内存和其他进程。需要核对cgroup和内核OOM证据。
连接池越大吞吐越高吗？
超过数据库有效并发后会增加排队、锁和内存。用数据库吞吐与尾延迟找甜点区，并给管理任务留容量。