happy最紧要很多面试官喜欢在最后环节抛出一道“线上问题排查”的开放题，比如“线上服务CPU飙到100%，你怎么处理？”“接口突然变慢了，你从哪儿查起？”这种问题没有标准答案，但恰恰最能拉开候选人的差距。我面过不少候选人，背了一堆JVM参数和命令，真到这种场景题上，思路混乱、东一榔头西一棒子，几句话就露馅了。
这篇文章我不打算罗列题库，而是把“线上问题排查”这一类面试题背后的考察逻辑、高频场景的完整排查链路，以及面试官真正想听的回答框架拆开讲清楚。无论你是在准备面试，还是日常工作中遇到类似问题不知道从何下手，这篇内容都值得仔细看一遍。
1. 面试官抛出这道题，真实意图是考察什么
先想清楚一个问题：面试官问“线上出问题了你怎么排查”，他到底想听到什么？
很多人以为这是一道考命令的题，于是疯狂背诵top、jstack、jmap这些工具的参数。但实际上面试官根本不关心你背了多少命令，他关心的是你面对未知问题时的思维路径。线上故障的特点是：现象明确、根因未知、信息碎片化。你能不能从一堆看似无关的指标里找到那条主线，能不能在压力下保持有序操作，这才是考察的核心。
具体来说，面试官心里有四个打分维度。
第一个是排查思路是否成体系。候选人是从“现象→假设→验证→结论”这样推进，还是想到什么查什么。我记得有个候选人回答“CPU高就先重启”，当时面试官脸都黑了。重启确实能解决问题，但没找到根因，下次还会再犯，这在面试里属于“负分操作”。
第二个是工具是否熟练且理解原理。不光知道jstack能看线程栈，还得知道线程号为什么要转成十六进制才能匹配上。只会敲命令不理解输出含义的，一追问就卡壳。
第三个是是否有实战经验。真正处理过线上问题的人，开口第一句往往是“我会先看一下监控报警，确认影响范围”，而不是直接跳到执行命令。这种“先评估影响再动手”的肌肉记忆，只有真实经历过才能形成。
第四个是沟通和优先级意识。线上故障分秒必争，是先恢复服务还是先定位根因，这需要判断。有经验的人会先做止损操作，再慢慢查，这个决策过程本身就是面试官考察的重点。
所以，准备这类面试题的正确姿势不是背题，而是建立一套自己的排查框架，然后用实战经验去填充它。面试官问任何一道场景题，你都能把问题装进框架里，输出一套逻辑自洽的回答。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. CPU飙升与内存溢出的排查链路拆解
线上问题里，CPU飙升和内存溢出是两类最经典的高频考题，几乎每场技术面试都会碰到。这两类问题的排查链路成熟、工具明确，也是最容易考察候选人基本功的地方。
2.1 CPU飙升：从top到线程栈的四步定位
先说你接到告警“CPU使用率100%”时的标准操作。第一步不是抓线程，而是看进程。登录服务器执行top，按CPU排序找到那个占用率异常的Java进程，记下PID。这一步很多人会跳过去直接jstack，但多进程场景下不先定位进程，后面全部白做。
第二步是找线程。执行top -Hp PID，这时候能看到这个进程内部所有线程的CPU占用情况。你会发现在100%的进程里，往往只有一两个线程在疯狂消耗CPU，其他线程都很安静。记下那个CPU占用最高的线程号，比如10234。
第三步是线程号转十六进制。这里有个细节很多新手会卡住：jstack输出的线程ID（nid）是十六进制的，而top -Hp给出的是十进制的PID。需要自己转换，比如printf "%x\n" 10234，得到27fa。
第四步是jstack PID | grep -A 30 '27fa'，直接看这个线程的堆栈信息。堆栈会明确告诉你这个线程在执行什么代码，是死在某个while(true)循环里，还是卡在GC线程里，或者是在做密集的正则匹配。看到具体业务代码之后，排查基本就完成了大半。
这里要补充一个常见误区。CPU高不一定是业务代码死循环，也可能是GC频繁导致的。如果jstack发现大量线程都在GC task thread或者VM Thread里，这时候要看的是GC日志和堆内存，而不是业务代码。判断方式就是看堆栈里是不是一堆java.lang.Thread.State: RUNNABLE但都在等锁，或者干脆一堆GC线程在跑。
2.2 内存溢出：区分场景比急着dump更重要
内存问题面试题套路更固定，基本就是OOM（OutOfMemoryError）怎么排查。但经验丰富的候选人会先问一句：“是哪种OOM？”因为堆内存溢出、元空间溢出、栈溢出，三个场景的排查手段完全不同。
最常见的堆内存OOM，标准链路是：先确认启动参数里有没有-XX:+HeapDumpOnOutOfMemoryError，如果配置了，OOM发生时JVM会自动生成java_pidXXX.hprof文件，这个文件就是现场。先用jstat -gcutil PID 1000看各内存区域的使用率和GC频率，确认是老年代满了还是新生代晋升太快，再用jmap -dump:format=b,file=heap.hprof PID手动导出一份堆快照。
拿到dump文件后用MAT或者JProfiler分析。分析时重点看两样东西：占比最大的对象是什么、被谁引用。大部分OOM要么是某个大集合没有清理，要么是缓存设计不合理导致对象无法被GC回收。定位到代码位置后，解决方案基本就清楚了，通常是加容量限制、改弱引用、或者优化查询逻辑。
元空间OOM现在问得也很多，通常和动态生成类有关，比如反射、CGLIB代理、热部署加载了大量Class。这种问题靠堆dump分析不出来，要看jstat -gcutil里的M区使用率，再用-XX:MaxMetaspaceSize限制上限，配合分析动态代理代码。
栈溢出相对少，典型错误是无限递归。如果报错是StackOverflowError，直接看堆栈里重复出现的调用链就能定位。
提示：面试时回答内存排查，如果能主动说出“先确认是哪种内存溢出再选择工具”，会显得特别有经验，因为面试官见过太多一上来就dump堆的候选人。
3. 接口响应变慢：从表象到根因的定位思路
“线上接口突然变慢了”这道题也是面试高发题。相比CPU和内存问题，这个问题隐蔽性更强，因为慢的原因非常多，而且往往是多个因素叠加的结果。面试官想听的，是你有没有一套快速分流的判断逻辑。
拿到这个问题，我一般先把可能的原因分成四类：外部依赖变慢、内部计算变慢、锁竞争、GC停顿。分类完之后逐个排除。
外部依赖变慢，指的是接口调了数据库、Redis、第三方HTTP服务，对方响应慢导致整个接口被拖垮。定位最快的方式是看trace，不管是SkyWalking、Zipkin还是公司自研的链路追踪系统，调用链上每一段的耗时都清清楚楚。如果发现耗时集中在某个Redis调用或者某个数据库查询上，问题基本就锁定了。
内部计算变慢就是代码逻辑本身耗时高。到大接口里做耗时的循环、加解密、大量数据序列化，这些都会导致接口变慢。定位方式可以用Arthas的trace命令，直接跟踪方法的每个子调用耗时：
bash复制trace com.example.OrderService getOrderInfo
它会打印这个方法内部每一行代码的耗时分布，一分钟内就能找到耗时最高的那个子方法。
锁竞争在面试题里出现频率很高，尤其是多线程面试问完之后顺手问一句线上问题。回答这个问题要知道一个特征：锁竞争导致的慢，接口的TP99会明显上升，但CPU占用不一定高，因为大量线程在等待，处于BLOCKED或WAITING状态。用jstack多抓几次线程栈，看是不是大量线程卡在同一个锁对象上，如果是，基本可以确定是锁竞争。典型场景是数据库连接池不够用、或者代码里用了单例锁做复杂计算。
GC停顿导致的慢，特点是响应时间呈周期性尖刺，不是一直慢，是每隔一段时间突然抖动一下。用jstat -gcutil PID 1000观察GC的频率和耗时，看到频繁的Full GC，基本就指向堆内存问题了。
最后说一个很多人容易忽略的排查起点：先确认是不是真的变慢。有时候是调用方超时时间设置太短，服务本身没问题；有时候是网络抖动，从客户端到服务端的链路延迟；还有时候是监控系统自己出了问题。先看全局监控，再往下钻，能避免很多无效排查。
4. 一套能应对追问的通用排查方法论
前面讲的都是具体场景，但要真正扛住面试官的连环追问，需要一套通用的方法论。这套方法论可以套在任何线上问题上，让回答立刻显得有章法。
我把这套方法论总结为五步：确认现象、评估影响、止损恢复、定位根因、验证复盘。
第一步确认现象。不要一上来就登录服务器，先看监控大盘，确认问题是否真实存在、影响范围多大。是某个接口超时率上升，还是整个服务不可用？是单机问题还是全局限流？这一步决定了后续所有操作的优先级。
第二步评估影响。如果只影响少量非核心请求，可以慢一点排查；如果是核心链路挂了，那就要立刻启动止损流程。
第三步止损恢复。线上原则是“先恢复，再定位”，宁可先重启服务让业务恢复，也不能为了保留现场让故障持续。止损手段就是大家常说的“三板斧”：重启、回滚、扩容。每个手段都有自己的适用场景。重启适合内存泄漏、连接数耗尽这类状态污染问题；回滚适合新发布版本引入的缺陷；扩容适合流量突增导致的资源不足。这里有个加分项，说明确说出每个操作的副作用，比如“重启会导致所有内存态缓存失效，可能引发缓存雪崩，所以重启前要确认有降级方案”。
第四步定位根因。这就是前面章节讲的各类具体排查手段。止损之后留出了时间窗口，可以用jstack、jmap、Arthas等工具慢慢查。
第五步验证复盘。修复完成后要验证是否真的解决，同时思考同类问题在其他服务是否也存在。面试时能提到这一步，说明你有闭环意识，这是高级工程师和初级工程师的明显区别。
提示：面试官大概率会根据你的回答追问细节，比如你说“先重启再定位”，他会问“重启之后现场没了怎么定位”。提前想好这种追问的回应，比如“重启前先保留线程栈和堆dump”，就能从容应对。
5. 一次服务假死事件的完整复盘
方法论讲多了容易觉得空洞，我用一个真实的案例把前面的链路串起来。这是我之前处理过的一次线上事故，特别适合作为面试题来讲解。
现象是：服务告警，接口成功率掉到60%，大量请求超时，但CPU和内存指标都正常。这个现象很迷惑人，因为CPU不高、内存不高，看起来不像典型的资源耗尽。
当时我的第一步是看线程状态。top确认进程存活，然后jstack抓线程栈，发现大量业务线程都卡在获取数据库连接上，线程栈里都是waiting for connection。看到这个信息，怀疑对象立刻指向数据库连接池。
第二步看连接池监控，发现活跃连接数打满，池子里的连接全部被占用且长时间不释放。连接池满意味着新的请求拿不到连接，只能排队等待，表现就是接口大面积超时。
第三步排查为什么连接不释放。从数据库慢查询日志入手，发现有两条SQL的执行时间超过30秒。持续执行慢SQL导致事务长时间不提交，连接一直被占用。
第四步顺着慢SQL查执行计划，发现一张大表的关联查询没有走索引，全表扫描。正常情况下这个SQL是毫秒级，但当天业务高峰期数据量暴涨，SQL执行计划退化导致扫描行数暴增，单个SQL拖了几十秒。
根因清楚了：数据量增长导致SQL执行计划劣化，慢SQL占满连接池，连接池耗尽导致所有请求阻塞，服务假死。
整个过程每步都有据可查，不存在玄学。这个案例放在面试里怎么说呢？重点讲“CPU正常、内存正常，但服务不可用”这种场景下你的排查思路是“看线程状态找阻塞点”，这个思路比直接报命令有价值得多。
修复动作也不复杂：临时扩容连接池和数据库资源，让服务先恢复；优化SQL走索引；加慢SQL告警避免再犯。复盘阶段补了一个连接池监控，当连接使用率达到80%时触发告警，提前干预。
这个案例里最能体现经验的是第一步的思路：CPU和内存都不高的时候，问题往往不在计算资源上，而在等待上——等锁、等IO、等连接。这是排查线上问题必须建立的本能反应。
6. 面试答法上的差异点：这些细节能加分
最后聊一个很实际的话题：同样一道“线上问题排查”的题，为什么有人答完面试官频频点头，有人答完场面尴尬？差别就在几个细节上。
第一个细节是主动提监控和告警。面试官描述完问题之后，有经验的人会说“我先看一下监控，确认影响范围”，而不是直接开始执行命令。这一句话就把你和“只会背命令的选手”区分开了。
第二个细节是把“恢复”和“定位”分开讲。优秀回答的结构通常是“我会先做止损操作让服务恢复，然后再排查根因”，而普通回答只讲怎么排查，完全没提恢复。面试官听到“先恢复”这三个字，就知道你处理过真实事故。
第三个细节是能说出工具的局限性。比如jmap dump在大堆内存场景下会触发一次Full GC，可能造成服务短暂停顿，所以生产环境操作要谨慎，最好配合-F模式或者在低峰期执行。这种细节虽然不起眼，但非常能体现实战深度。
第四个细节是复盘意识。回答的最后一句如果落在“问题解决后我会整理一份事故报告，把后续的监控优化点列出来”，这个收尾会非常加分。它传递的信息是你不只是修了一个bug，你有完整的工程闭环思维。
我再给一个直接可用的回答话术，把一道CPU飙升题的完整回答示范出来，你可以参考这个结构来组织自己的答案：
首先我会登录服务器用
top确认是哪个进程的CPU飙高，然后top -Hp PID定位到具体线程。把线程号转成十六进制之后，用jstack抓线程栈，看这个线程在做什么。如果是在执行业务代码，直接看代码逻辑有没有死循环或者正则回溯。如果是GC线程导致，就要看堆内存的使用情况和GC频率，可能就是内存快满了触发频繁GC。定位到根因之后，先做止损，比如重启或者扩容，再根据根因做代码修复或参数调整。修复完成后我还会观察一段时间，确认CPU指标平稳，并复盘这次问题的监控盲点，避免下次同类问题再次发生。
这个回答的逻辑是通的：现象→定位→根因→止损→修复→复盘，每一步都踩在考察点上。面试官如果顺着追问“GC频繁怎么定位”，你就把前面jstat和jmap那套东西砸出来，基本就稳了。
我在实际面试别人时，最看重的一点是：候选人面对问题的第一反应是不是有序的。技术深度可以培养，工具可以学，但没有章法的应激反应才是最难的。把排查思路内化成自己的本能，遇到任何线上问题都能条理清晰地推进，这才是准备这类面试题最核心的目标。希望这篇内容能帮你把这个本能建立起来。