面试官抛出“线上CPU飙到90%怎么办”，很多人第一反应是“重启”。这个答案在面试官眼里等于交白卷。场景题考的不是你知道多少命令，而是你有没有一套排查问题的思维框架。下面这五道题，答不上来基本就凉了。
线上CPU飙高，你怎么定位？
先用top找到CPU最高的进程，再top -Hp 进程号定位到具体线程，把线程ID转成十六进制，最后jstack打印线程栈，搜索这个十六进制ID，就能看到是哪个方法在跑。常见原因：死循环、频繁GC、正则回溯。排查的核心不是命令，是路径。先定位进程，再定位线程，再定位代码，层层缩小。面试官接着会问：如果是GC导致的CPU高，怎么看？答jstat -gcutil看GC频率和耗时，再看堆内存趋势。
内存泄漏怎么查？
先看监控：老年代占用持续上升，Full GC后降不下来，这就是泄漏的典型特征。用jmap -dump:live,format=b,file=heap.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，高并发下可以关闭死锁检测，用超时机制兜底。
这五道场景题的共同点是：面试官不关心你背了多少命令，关心你有没有在生产环境真正排查过问题。没排过，就说不出来；说不出来，简历再漂亮也不敢要。下次面试前，别光刷算法，把这五道题的排查路径自己讲一遍。能讲清楚，才算真正会了。
