linux进程CPU占用过高时，应先用top/htop定位高消耗进程及线程，再通过pidstat、perf或jstack深入分析热点函数，最后据死循环、频繁GC、锁竞争等根因针对性优化。
Linux进程CPU占用过高，先别急着重启服务，关键在快速定位和针对性优化。核心思路是：先找谁在吃CPU，再看它为什么吃，最后决定是调参数、改代码，还是加资源。
用top或htop快速揪出“罪魁祸首”
运行 top（或更直观的 htop，需安装），默认按CPU使用率降序排列。重点关注 %CPU 列，一眼锁定前几位高消耗进程。记下它的 PID 和 COMMAND。如果看到某个 java/python 进程持续占满一个核（接近100%），或者多个线程分散占多个核，就值得深挖。
- 在 top 中按 Shift+P 确保按 CPU 排序
- 按 H 可切换显示线程模式，识别是否是单进程内多线程争抢
- 记下 PID 后，用 ps -T -p [PID] 查看该进程所有线程及其线程ID（TID）
深入线程级分析：perf 或 pidstat 定位热点函数
如果 top 显示是某个进程整体高，但不确定是哪段逻辑导致，就得看执行时的热点。对运行中的进程，推荐用 perf（系统级火焰图基础）或轻量级的 pidstat。
- pidstat -t -p [PID] 1：每秒刷新一次，显示该进程各线程的CPU使用，快速判断是否某线程独占
- perf record -g -p [PID] -a sleep 10：采集10秒调用栈，再用 perf report 查看耗时最多的函数路径
- 若为Java应用，可直接用 jstack [PID] 抓线程快照，结合 top -H -p [PID] 找出高CPU线程对应的nid（十六进制），再在jstack输出中搜索对应线程栈
常见原因与对应处理建议
CPU飙高不是故障，而是信号——说明程序在密集计算、死循环、频繁GC、锁竞争或低效IO等待中的一种或多种。不同场景对策不同：
- 死循环或算法复杂度高：检查日志是否有重复报错、重试风暴；查看代码中是否存在无终止条件的 while 循环或 O(n²) 以上未优化的遍历
- 频繁垃圾回收（Java/go等）：用 jstat -gc [PID] 观察 GC 频率与停顿；增大堆内存或调整 GC 策略（如 G1 的 MaxGCPauseMillis）
- 锁竞争激烈：perf 输出若大量出现在 pthread_mutex_lock / futex_wait，说明线程在等锁；考虑减少共享状态、用无锁结构或分段锁
- 正则表达式回溯爆炸：尤其在 nginx、Java 或 Python 中处理恶意输入时常见；用更安全的正则引擎或加超时限制
临时缓解 + 长效改进
线上不能停？先限流保稳；查清根因后，再推进长期治理：
- 临时：用 cpulimit -p [PID] -l 50 将进程CPU限制在50%，避免拖垮整机（仅应急，不解决根本）
- 监控：在 prometheus + grafana 中配置进程级 CPU 告警，并关联线程数、GC 时间等指标，形成可观测闭环
- 上线前：增加压测环节，特别关注 CPU 使用率随QPS增长的曲线，识别拐点
- 编码习惯：避免在循环中做重复字符串拼接、反复序列化、未索引的数据库 in 查询等典型高CPU操作