CPU 使用率 100% 怎么排查？
五个经典回答示范
四步：top 找进程——按 P 排序定位；进程内看线程——top -H 或 pidstat -t 找热点线程；分析构成——us 高是应用计算、sy 高是系统调用频繁、wa 高其实不是 CPU 问题是 IO；工具下钻——strace 看系统调用、perf top 看函数热点、Java 用 jstack 看线程栈。同时确认业务表现：是全量异常还是单进程。
我讲一次 Java 服务 CPU 100%：top 定位进程，pidstat -t 找到两个线程各吃 45%；jstack 导栈，线程号转十六进制对应栈帧——是正则回溯爆炸（用户输入超长字符串触发灾难性回溯）；临时止血加输入长度限制，根因修复改用非回溯正则并加单测覆盖恶意输入。这个案例我的习惯总结：应用层 CPU 异常十有八九能在栈里直接看到答案，关键是别怕导栈分析。
资深视角：CPU 100% 的分类学决定处置路径。业务正常型——流量高峰真需要算力：扩容与限流保护，顺便看单请求成本是否劣化（版本对比）；业务异常型——死循环、正则回溯、GC 风暴（CPU 高但线程都空，jstat 看 GC 频率）、序列化异常：先保留现场（栈、dump、日志）再处置；安全型——异常进程吃 CPU 且名字陌生：挖矿木马排查（crontab、异常外联、/tmp 可执行文件），先隔离网络取证。诊断纪律：变更与监控对齐时间线。
追问『GC 频繁怎么确认』：jstat -gcutil 看 O 与 F 次数增速，频繁 Full GC 配合 dump 分析大对象来源；『容器里 CPU 100% 怎么回事』：确认是 limit 被打满还是宿主机争抢——cgroup 的 throttle 计数区分，应用看到的使用率与 limit 口径不同；『不能装工具怎么办』：/proc 是最后武器——stat、stack、sched 信息都能手工读。
『CPU 满了就 kill 掉最占的进程，让服务自动拉起，不行就重启服务器，反正有负载均衡兜底。』——点评：kill 掉的可能正是核心服务——随机杀进程是俄式轮盘赌；不保留现场的处置让根因永远沉没，下次同样问题换台机器再爆。
- 打开 模拟练习，选择「运维/DBA」方向，限时 3 分钟作答本题。
- 对照上方答题框架，逐点检查：哪些要素没覆盖、哪里表达啰嗦。
- 用自己项目的真实经历替换框架中的占位内容，重讲一遍并录音回听。
这类题在真实面试中常被追问细节，
建议进入限时模式练一遍。