生产环境Java应用性能劣化 无profiler排查高CPU内存诱因

不需要挂载额外性能剖析工具，用JDK自带原生命令、操作系统内置统计工具就能完成验证，所有操作无需重启应用、无需注入agent，符合绝大多数生产环境的管控要求。

CPU侧验证步骤 #

• 先拆分CPU消耗构成：执行top -Hp <Java进程PID>查看进程内所有线程的CPU占比，先区分高CPU消耗来自业务线程、GC线程还是内核系统调用。如果是业务线程占比高，连续执行3次jstack <PID>（每次间隔2秒），对比三次快照中始终处于RUNNABLE状态的线程栈，多次重复出现的栈帧就是持续占用CPU的代码路径。这个操作是JVM原生支持的安全点采样，单次停顿毫秒级，不属于需要额外挂载的profiler工具。
• 验证CPU排队对耗时的影响：执行vmstat 1查看运行队列长度（r列数值）和CPU steal值，如果运行队列长度持续超过物理CPU核心数的1.2倍，说明大量线程在排队等待CPU调度，排队等待的时长会直接叠加到业务操作的总耗时上。你可以直接对比非生产环境同等压力下的运行队列长度，两边的排队时长差基本就是业务耗时差的核心组成部分。
• 关注CPU态占比：如果内核态CPU占比超过30%，说明存在大量锁竞争、频繁系统调用（比如海量网络IO、磁盘刷盘），这种场景哪怕CPU总利用率没到100%，线程在内核态的等待时间也会明显拉长业务耗时。

内存侧验证步骤 #

• 先看GC行为：执行jstat -gcutil <PID> 1000 10连续采集10次GC统计数据，重点关注两个指标：一是Full GC的触发频率、单次停顿耗时，二是Young GC的平均停顿时间、对象晋升老年代的比例。如果Full GC每分钟触发1次以上、单次停顿超过500ms，或是Young GC停顿比非生产同压力下高3倍以上，GC停顿的时间会直接计入业务操作耗时。
• 确认内存供给是否充足：观察jstat输出的老年代占用率，如果老年代占用持续高于90%，说明内存空间已经接近耗尽，JVM会投入大量CPU资源尝试GC回收空间，甚至会出现并发模式失败、晋升失败，触发长时间STW，直接导致应用阶段性卡顿、业务耗时整体抬升。
• 排查内存换页：执行vmstat 1看si/so列的swap换入换出数值，配合free -h查看系统可用内存，如果存在持续的swap交换，说明物理内存不足，JVM堆内存被换出到磁盘，内存访问延迟会从纳秒级升到毫秒级，这是内存不足导致性能骤降的典型特征。

交叉验证排除干扰 #

• 对比生产和非生产的JVM启动参数，重点核对堆内存大小、GC收集器类型、JIT编译相关参数，不少场景下生产环境堆配置比非生产小、或是用了完全不同的GC算法，本身就会放大高资源占用下的性能差异。
• 做耗时拆分：如果业务日志有分阶段时间戳，直接把单次业务操作的耗时拆成本地计算、数据库访问、缓存调用、下游服务调用几个部分，如果本地计算、停顿等待的占比是耗时上涨的主要来源，就能排除外部依赖慢的干扰，确认是本地CPU/内存资源问题。
• 低峰期对照压测：在凌晨等业务低峰期，用和非生产压测一致的压力打对应接口，如果此时CPU、内存利用率处于低位，接口耗时降到和非生产环境基本一致的水平，就能直接确认高CPU/内存占用是性能下降的根因，这个方法不需要任何额外工具，对业务影响最小。

注意：上述提到的jstack、jstat都是JDK默认自带的运维工具，属于JVM原生提供的观测能力，不需要挂载任何外部profiler，也不需要修改应用启动参数，只要有进程的属主权限就能执行，符合多数生产环境的操作规范。

内容的提问来源于stack exchange，提问作者Nitin Kumar