面试官抛出“线上CPU飙到90%怎么办”很多人第一反应是“重启”。这个答案在面试官眼里等于交白卷。场景题考的不是你知道多少命令而是你有没有一套排查问题的思维框架。下面这五道题答不上来基本就凉了。线上CPU飙高你怎么定位先用top找到CPU最高的进程再top -Hp 进程号定位到具体线程把线程ID转成十六进制最后jstack打印线程栈搜索这个十六进制ID就能看到是哪个方法在跑。常见原因死循环、频繁GC、正则回溯。排查的核心不是命令是路径。先定位进程再定位线程再定位代码层层缩小。面试官接着会问如果是GC导致的CPU高怎么看答jstat -gcutil看GC频率和耗时再看堆内存趋势。内存泄漏怎么查先看监控老年代占用持续上升Full GC后降不下来这就是泄漏的典型特征。用jmap -dump:live,formatb,fileheap.bin 进程号导出堆快照再用MAT或JProfiler分析支配树找到占用最大的对象和引用链。最常见的原因是静态集合、ThreadLocal没remove、监听器没注销。面试官会追问如果dump文件几十个G怎么分析答先看直方图jmap -histo:live找可疑对象再针对性dump。接口突然变慢怎么排查第一步看日志是所有接口慢还是个别接口慢个别接口慢查该接口的SQL和下游调用。全部慢查数据库连接池、线程池、GC。用arthas的trace命令看方法耗时分布用watch看入参出参。接口变慢的元凶通常是数据库慢查询、锁等待、或者下游服务超时。别忘了看网络ping和traceroute确认是不是网络抖动。面试官最想听的是你有没有一套从入口到出口的链路追踪思路。消息队列积压了怎么处理先看积压量几万条还是几百万条几万条临时加消费者实例就能扛过去。几百万条先定位原因是消费逻辑变慢还是生产端突然暴增如果是消费逻辑慢优化代码、批量消费、异步处理。如果是生产暴增限流生产端同时扩容消费者。紧急情况下可以临时启用备用队列分流。面试官会问积压导致消息过期怎么办答设置死信队列过期消息转入死信事后补偿别丢数据。数据库死锁怎么处理先查information_schema.INNODB_TRX看当前运行的事务再查INNODB_LOCKS和INNODB_LOCK_WAITS看锁等待关系。找到死锁后KILL掉代价最小的事务。预防死锁的核心是按固定顺序访问资源缩短事务持有锁的时间避免大事务。面试官会追问MySQL怎么自动检测死锁答InnoDB有死锁检测机制发现死锁会回滚代价小的事务但检测本身消耗CPU高并发下可以关闭死锁检测用超时机制兜底。这五道场景题的共同点是面试官不关心你背了多少命令关心你有没有在生产环境真正排查过问题。没排过就说不出来说不出来简历再漂亮也不敢要。下次面试前别光刷算法把这五道题的排查路径自己讲一遍。能讲清楚才算真正会了。