调优结论应能回到现场证据让排查顺序能被下一次复用服务问题出现时先保存请求特征、实例状态和配置版本再动参数。限流、超时、连接池和缓存会相互影响一次同时修改多项后面很难判断哪项起了作用。小范围变更后观察一个完整业务周期结论才有可比性。确认恢复时也别只看控制台绿了。检查客户端是否收到明确结果、后台任务是否停止占用资源、指标和日志是否回到正常基线。把这些检查写成固定顺序遇到同类故障就不用从零开始。虚拟机里的堆、线程和容器限制彼此影响单次 GC 日志或一次 CPU 峰值不足以下结论。先记录发生时的容器配额、负载类型和线程栈再决定是否改参数。没有上下文的“建议值”很容易在另一台机器上造成更坏的结果。长稳测试关注趋势而非某个瞬时数字。资源是否回落、类加载器是否持续增长、队列是否积压比短跑得分更说明问题。虚拟机性能调优的分层验证单元测试能证明逻辑分支是否正确却不能说明长时间运行后的堆、线程和连接是否稳定。性能验证要覆盖真实的数据规模和资源限制。单元测试无法覆盖的资源问题以大批量导出为例小数据单测只能验证文件格式和异常分支。进入集成或压测阶段后还要确认每批数据是否及时释放、并发导出是否受限以及堆占用能否在请求结束后回落。分层验证的职责划分为了在代码进入生产前拦截 JVM 故障我们必须重新界定三层测试的职责划分。单元测试代码逻辑与边界校验定位验证算法正确性、异常分支处理。虚拟机关注点不在单测里下性能结论如需比较热点方法可使用 Java 微基准工具记录吞吐与局部对象分配。集成测试资源释放校验定位验证数据库连接池、Redis 客户端、 ThreadPoolExecutor 资源是否按预期回收。JVM 关注点重点排查ThreadLocal是否遗漏了remove()调用以及InputStream/OutputStream是否正确关闭。长稳压测观察堆与回收趋势定位使用 JMeter 或 Locust 施加 2 倍峰值流量持续压测 4 至 8 小时。JVM 关注点观察 GC 打印日志GC Log监测老年代内存使用率Old Gen Utilization是否呈“锯齿状”正常回落。如果老年代占用随着时间推移呈线性上升趋势即便没有报 OOM也必定存在内存泄漏。线上排查的取证顺序收到虚拟机暂停或 CPU 异常告警时先根据容量和故障等级判断是否需要止损。条件允许时应优先采集线程、堆和运行日志再进行重启或扩容操作。正确的现场排查步骤常用诊断命令挂载 Arthas 后首先排查是否存在死锁或者 CPU 狂飙的代码块# 1. 查找消耗 CPU 最高的 3 个线程堆栈 thread -n 3 # 2. 检查是否有 ThreadLocal 导致的类加载器内存泄漏 sc -d org.apache.catalina.loader.WebappClassLoader # 3. 监控热点方法的入参与内存占用 watch com.example.service.OrderService exportExcel {params, returnObj} -n 5 -x 3如果确认堆内存溢出使用 Eclipse MAT (Memory Analyzer Tool) 打开 Dump 文件直奔Dominator Tree支配树查找持有大量引用的根节点GC Roots。参数设置要结合容器限制生产环境的 JVM 参数必须显式声明绝不能依赖默认配置JAVA_OPTS-server \ -Xms4g -Xmx4g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -XX:InitiatingHeapOccupancyPercent45 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/var/log/jvm/java_ram_oom.hprof \ -Xlog:gc*:file/var/log/jvm/gc.log:time,uptime,level,tags:filecount5,filesize50M要点解析-Xms与-Xmx必须设为完全一致防止 JVM 在高并发请求涌入时因为动态扩容堆内存而向操作系统申请空间造成额外的性能开销与抖动。评估后开启堆转储容器空间、敏感数据和写入路径允许时可开启内存溢出时的堆转储便于后续分析引用链。单元测试之外还需要长稳压测和可检索的运行证据。这样才能判断资源问题是否来自代码、配置或真实负载。