获课：aixuetang.xyz/4860/

Java线上性能排查全流程：CPU与内存泄漏定位实战学习指南

对于Java后端开发者来说，线上性能排查是从CRUD开发走向架构决策的核心能力，也是职业跃迁路上必须啃下的硬骨头。很多人遇到CPU飙高、内存溢出的告警就慌神，本质是没有建立一套从现象到根因的标准化排查思维，把零散的工具命令串联成体系化的实战流程，就能大幅降低线上故障的排查耗时。

CPU异常飙升的分层排查思路

拿到CPU使用率告警的第一步，不要直接钻进代码翻找问题，先通过基础命令把CPU的时间开销拆解清楚。用top命令先区分用户态us、内核态sy、IO等待wa和软中断si的占比，就能快速缩小排查范围：如果us占比过高，说明是业务代码在消耗计算资源；如果sy异常偏高，大概率是系统调用过于频繁，或是内核中断处理过载；wa占主导则说明CPU大部分时间在等待磁盘IO，问题根源不在计算逻辑而在存储访问效率。

定位到进程级别的异常后，再用top -H参数展开到线程维度，很多时候进程整体CPU使用率看似平稳，实则某个线程已经把单核资源跑满，进程级别的监控会掩盖这类局部热点。接下来用async-profiler生成低开销的CPU火焰图，横向宽度代表方法的耗时占比，纵向堆叠展示完整调用链，就能直观找到最“热”的执行路径。这里要特别注意区分真正的CPU计算瓶颈和I/O等待、锁阻塞的假热点：如果火焰图里大量线程停在socketRead0方法，说明是下游接口响应慢拖慢了整体流程，不是本地代码的计算问题；如果大量线程卡在Unsafe.park方法，就要结合jstack导出的线程栈，确认是锁竞争激烈还是线程池耗尽。

内存泄漏的递进式定位方法

很多开发者一看到内存使用率上涨就直接判定为内存泄漏，这是排查路上最常见的误区。正确的做法是先通过GC日志确认特征：观察老年代的使用率是否持续缓慢上升，每次Full GC之后的内存回收量极少，同时老年代GC的频率越来越高、耗时越来越长，只有满足这些特征，才能确认是对象该回收却没有被回收的真泄漏，而不是正常的业务内存占用。

确认泄漏存在后，用jmap导出带live参数的堆转储快照，只保留存活对象能大幅减少快照体积，降低分析工具的负载。把快照导入Eclipse MAT工具后，优先查看Dominator Tree按保留堆内存排序的对象列表，再结合MAT自动生成的Leak Suspects报告，顺着Path to GC Roots路径追踪对象的强引用链。实战中80%以上的内存泄漏都来自四类高危场景：没有清理机制的静态集合、线程池场景下未调用remove的ThreadLocal、注册后没有注销的事件监听器，还有未关闭的数据库连接和文件流资源，排查时优先聚焦这几类代码结构，不用通读整个项目就能快速定位根因。

完成修复后不要直接上线，要通过压测模拟线上流量运行一两个小时，用jstat持续观察老年代的内存曲线是否回归平稳，再对比重启前后的两次堆快照，确认泄漏对象的数量不再异常增长，才算完成完整的闭环验证。这套从粗到细的排查流程练熟之后，哪怕遇到线上突发的性能告警，也能做到不慌不乱，快速定位问题恢复服务。

需要我为你整理‌这套排查流程对应的常用命令速查表‌吗？便于你线上故障时快速对照使用