- 正确答案：Hang（程序无响应、卡死、假死）在校园招聘技术面试中常作为系统级问题考察候选人对操作系统、并发编程、资源管理及调试能力的综合理解。常见原因包括：死锁、无限循环/递归、阻塞式I/O未超时、线程饥饿、信号量/互斥锁误用、内存耗尽导致频繁GC或OOM前卡顿、CPU密集型任务长期占用单线程（如UI线程）、系统调用陷入不可中断睡眠（D状态）、文件描述符/连接池耗尽、JVM safepoint竞争、glibc malloc 竞争（多线程高频小内存分配）、内核模块故障或硬件异常（如坏盘DMA hang）。每类需对应不同排查路径。 - 解答思路：排查hang应遵循“由外而内、由表及里、动静结合”原则——先观察现象（进程是否存活、CPU/内存占用、响应性），再采集静态快照（堆栈、内存、fd、锁状态），最后结合动态追踪（系统调用、函数级采样、锁等待链）。关键是要建立完整证据链：进程状态 → 线程级上下文 → 内核态行为 → 资源依赖关系。 - 深度知识讲解： 1. 死锁（Deadlock）： - 底层原理：多个线程/进程循环等待彼此持有的不可剥夺资源（如互斥锁、信号量），形成有向等待环。POSIX线程中pthread_mutex_lock()在已持有锁时再次加锁（非递归锁）会导致未定义行为，但常见实现是阻塞；Java中synchronized嵌套或ReentrantLock.lock()未配unlock()易引发死锁。 - 排查方法： • Linux下：kill -3 （对Java进程）输出线程堆栈，查找WAITING/BLOCKED且持有锁又等待锁的线程；或用jstack -l 查看详细锁信息。 • 原生进程：gdb attach → thread apply all bt，检查各线程阻塞点；配合pstack 快速抓栈。 • 自动检测：Java可启用-XX:+PrintConcurrentLocks；Linux可使用systemd-coredump配合coredumpctl debug分析历史core。 - 代码示例（Java死锁模拟）： ``` public class DeadlockDemo { private static final Object lockA = new Object(); private static final Object lockB = new Object(); public static void main(String[] args) { Thread t1 = new Thread(() -> { synchronized (lockA) { try { Thread.sleep(100); } catch (InterruptedException e) {} synchronized (lockB) { } // 等待lockB } }); Thread t2 = new Thread(() -> { synchronized (lockB) { try { Thread.sleep(100); } catch (InterruptedException e) {} synchronized (lockA) { } // 等待lockA → 形成环 } }); t1.start(); t2.start(); } } ``` 2. 无限循环/递归（Infinite Loop/Recursion）： - 底层原理：CPU持续执行某段代码，不触发调度（尤其在禁用抢占内核或实时调度策略下），导致其他线程无法获得CPU；栈溢出时可能触发SIGSEGV，但若未开启栈保护或被信号处理掩盖，则表现为高CPU+无响应。 - 排查方法： • top / htop看CPU占用率，若单核100%且进程状态为R（Running），优先怀疑。 • perf record -g -p && perf report -g 查看热点函数和调用栈深度。 • 对Java：jstack看是否有RUNNABLE线程长时间停留在同一行（如while(true)或for(;;)）；jstat -gc 确认是否伴随GC停顿（排除GC导致的假hang）。 - 注意：编译器优化（如-O2）可能导致循环被优化为跳转，gdb中需用disassemble定位汇编级死循环。 3. 阻塞式I/O无超时（Blocking I/O without timeout）： - 底层原理：read()/write()/accept()/connect()等系统调用在内核中进入可中断睡眠（S状态），等待设备就绪。若网络对端宕机、磁盘故障、NFS服务器离线，可能阻塞数分钟甚至更久（TCP重传超时默认约15~30分钟）。 - 排查方法： • strace -p -e trace=network,io 查看最后阻塞的系统调用。 • ss -tulnp | grep 检查socket状态（SYN_SENT、FIN_WAIT2、CLOSE_WAIT等异常状态）。 • lsof -p 查看打开的文件描述符类型及对应inode/device。 • 对Java：检查Socket.setSoTimeout()、HttpURLConnection.setConnectTimeout()是否设置；Netty中ChannelOption.CONNECT_TIMEOUT_MILLIS是否配置。 - 根本解决：强制使用非阻塞IO（O_NONBLOCK）+ epoll/kqueue，或至少设置SO_RCVTIMEO/SO_SNDTIMEO。 4. 线程饥饿（Thread Starvation）与锁竞争（Lock Contention）： - 底层原理：公平锁（如ReentrantLock(true)）虽保证FIFO，但高并发下入队/唤醒开销大；非公平锁虽吞吐高，但可能导致低优先级线程长期得不到锁。glibc malloc在多线程下使用per-arena mutex，高频malloc/free易引发arena锁竞争（perf record -e 'syscalls:sys_enter_brk,syscalls:sys_enter_mmap'可验证）。 - 排查方法： • Java：jstack查看大量线程处于BLOCKED on java.util.concurrent.locks.AbstractQueuedSynchronizer$Node，或WAITING on java.util.concurrent.ThreadPoolExecutor$Worker。 • Linux：perf record -e sched:sched_stat_sleep,sched:sched_stat_wait -p 统计线程等待调度器时间。 • 使用async-profiler（-e alloc）分析内存分配热点，定位高频锁区域。 5. 内存耗尽与GC相关hang： - 底层原理：JVM Full GC时STW（Stop-The-World），G1/CMS等收集器虽有并发阶段，但FinalReference处理、元空间回收、GC Roots枚举仍需STW；Native内存耗尽（如DirectByteBuffer未清理）导致mmap失败，进程可能hang在系统调用中。 - 排查方法： • jstat -gc 观察YGC/FGC频率与耗时；jstat -gccapacity查看各代容量变化。 • jmap -histo:live 查看对象分布；jmap -dump:format=b,file=heap.hprof 后用Eclipse MAT分析内存泄漏。 • Linux：free -h、cat /proc/meminfo | grep -E "MemAvailable|SwapFree"、dmesg | tail -20 查看OOM Killer日志。 6. 不可中断睡眠（D状态hang）： - 底层原理：进程在内核态执行不可中断的系统调用（如读取故障硬盘、NFS硬挂载、某些驱动bug），此时ps显示D状态，无法被kill -9终止，只能重启。 - 排查方法： • ps aux | grep ' D ' 查找D状态进程。 • cat /proc//stack 查看内核栈（需debuginfo内核符号），定位卡在哪个driver函数（如nfs_wait_event、ext4_io_submit、ahci_port_wait). • iostat -x 1 观察await、%util是否异常高；dmesg检查硬件错误（ATA errors、UC/CE memory errors）。 7. JVM Safepoint竞争： - 底层原理：JVM执行GC、JIT去优化、thread dump等操作需所有线程到达safepoint。若某线程长时间运行无安全点（如长循环未包含方法调用、JNI临界区、自旋等待），则其他线程等待其到达safepoint，表现为整体hang。 - 排查方法： • JVM启动参数添加-XX:+PrintGCApplicationStoppedTime -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1，观察Stop Time及最慢线程。 • 使用async-profiler -e wall -d 60 采样，若发现大量线程堆栈为"no Java stack"或停留在native方法，需检查JNI或循环内联情况。 8. 其他深层原因： - 文件描述符耗尽：ulimit -n 查看限制；lsof -p | wc -l 对比；错误日志中出现"Too many open files"。 - DNS阻塞：getaddrinfo()默认同步解析，无超时；应改用异步DNS（如netty-resolver-dns）或设置resolv.conf options timeout:1 attempts:2。 - 信号处理阻塞：sigprocmask()屏蔽了SIGCHLD等关键信号，导致子进程僵死，父进程wait()永远阻塞。 - 扩展建议（校招面试加分项）： • 提及现代工具链：bpftrace（tracepoint:syscalls:sys_enter_read）、eBPF程序（如opensnoop、tcplife）实现无侵入监控； • 强调SRE理念：将hang视为SLO违规，需建立黄金指标（延迟P99、错误率、饱和度）告警，而非仅事后排查； • 举例线上Case：某服务因Log4j2 AsyncLoggerConfig使用RingBuffer满后阻塞生产者线程（而非丢弃日志），导致业务线程hang在logger.info() —— 本质是线程模型与背压机制不匹配。综上，hang排查不是单一技巧，而是融合OS原理、语言运行时、硬件特性的系统工程能力。校招中能清晰分层（应用层→JVM/运行时→系统调用→内核→硬件）、熟练使用至少3种诊断工具（strace/jstack/perf）、并能从代码写出潜在风险点（如未设timeout的IO、非原子的共享变量读写），即体现扎实基础。

快手ai infra二面

全站热榜

创作者周榜