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 操作
