Java进程CPU或内存占用过高，如何快速定位根因？

Question

Java进程CPU或内存占用过高是线上故障高频场景。快速定位根因需分步排查： 1. **确认异常进程**：用 `top -Hp ` 查看线程级CPU占用，或 `jps -l` + `jstat -gc ` 初判内存压力； 2. **抓取线程快照**：`jstack > threaddump.log`，结合高CPU线程ID（转十六进制）定位热点方法； 3. **分析堆内存**：`jmap -histo:live ` 快速识别大对象/泄漏嫌疑类；必要时 `jmap -dump:format=b,file=heap.hprof ` 配合JProfiler/Mat分析； 4. **动态监控辅助**：Arthas（`thread -n 5`、`dashboard`、`ognl`）可无侵入实时诊断。 关键口诀：“先看线程再看堆，结合GC日志判代际，善用Arthas提效，避免盲目重启”。定位常聚焦于死循环、频繁GC、未关闭连接、静态集合缓存膨胀等典型问题。

Answer 1

```html

一、现象层：识别“谁在吃资源”——进程级异常初筛

线上Java服务响应变慢、超时陡增，第一反应不是改代码，而是确认“是否进程本身已失控”。使用top -c定位高CPU/内存的Java进程PID；再用top -Hp <pid>切换至线程视图，按Shift+P排序，快速锁定TOP 3高耗线程TID（十进制）。内存侧则组合jps -l查应用PID，配合jstat -gc -h10 <pid> 1000持续采样GC行为：若YGC频次＞50次/分钟且EU（Eden使用率）长期＞95%，或OU（老年代使用率）持续攀升逼近阈值，即存在内存压力信号。

二、线程层：解码“热执行路径”——线程快照深度归因

• 执行jstack <pid> > threaddump.log获取全量线程快照（建议连续抓3次，间隔5秒，排除瞬时抖动）；
• 将top -Hp中高CPU线程ID（如12345）转为十六进制：printf "%x\n" 12345 → 3039；
• 在threaddump.log中搜索nid=0x3039，定位对应线程栈；重点关注RUNNABLE状态下的堆栈顶层方法（如java.util.HashMap.get高频调用、org.springframework.web.servlet.DispatcherServlet.doDispatch阻塞、或自定义while(true)循环）。

三、堆内存层：追踪“谁在占空间”——对象分布与泄漏溯源

命令	作用	关键指标解读
jmap -histo:live <pid>	统计当前存活对象类分布	关注前三列：#instances（实例数）、bytes（总字节）、class name；若byte[]、java.lang.String、com.xxx.cache.DataCache持续霸榜且增长快，即高危信号
jmap -dump:format=b,file=heap.hprof <pid>	生成完整堆转储快照	需配合MAT（Memory Analyzer Tool）打开，使用Leak Suspects Report自动识别泄漏链，或手动分析dominator_tree中Retained Heap最大的对象及其GC Roots引用路径

四、动态诊断层：实现“不重启的手术”——Arthas实时观测闭环

当无法复现或需验证修复效果时，Arthas成为黄金工具：

# 实时查看最耗CPU的5个线程及完整堆栈
thread -n 5

# 全局监控：线程数、JVM内存、GC、系统负载等仪表盘
dashboard

# 动态执行OGNL表达式，验证静态集合状态（如检查缓存大小）
ognl '@[e-mail]()'

# 追踪指定方法调用耗时（定位慢SQL/远程调用）
trace com.example.service.UserService getUserById '{params,return,throw}'

五、根因模式库：高频问题映射与防御清单

1. 死循环/无限递归：线程栈显示同一方法反复嵌套（如computeIfAbsent触发自身），常伴CPU飙高但内存平稳；
2. 频繁Young GC + 老年代缓慢增长：典型内存泄漏特征，常见于未关闭的InputStream、Connection，或静态ConcurrentHashMap无清理机制；
3. 大对象直接分配到老年代：如单次上传100MB文件未分块，触发ParNew晋升失败后Full GC；
4. Finalizer队列阻塞：大量重写了finalize()的对象堆积，导致Finalizer线程RUNNABLE但实际卡在锁竞争；
5. G1 Mixed GC参数失配：MaxGCPauseMillis设过低致GC线程过度抢占CPU，反而拖慢业务。

六、诊断流程图：结构化决策路径

graph TD
  A[CPU/内存告警] --> B{CPU高？}
  B -->|是| C[用 top -Hp 找高TID → jstack 定位热点方法]
  B -->|否| D[用 jstat -gc 判GC压力 → jmap -histo 查对象分布]
  C --> E[检查循环/锁争用/正则回溯]
  D --> F[用 MAT 分析 heap.hprof 的 Retained Heap]
  E --> G[代码修复 + 单元测试验证]
  F --> G
  G --> H[上线后 Arthas dashboard 持续观察72小时]

```