面试官好，遇到 Linux 系统卡死、卡顿、假死、完全无响应这类问题，我会从上层应用 → 系统资源 → 内核层 → 硬件层由浅入深逐层排查，核心先区分：是业务进程卡死、局部锁死，还是整个操作系统内核级死机。一、先快速判断卡死范围（第一步）
- 能 ping 通、但业务无响应：应用层 / 进程 / 死锁 / IO 阻塞问题
- ping 不通、SSH 连不上、控制台无反应：内核挂死、内存崩溃、硬件故障
- 1.进程负载与僵死进程
- 查看整体负载：
top / htop，观察 CPU 100%、Load Average 过高 - 查看僵尸进程：
ps -ef | grep defunct，大量僵尸进程会耗尽进程表 - 查看进程状态：D 状态（不可中断 IO 阻塞）、Z 僵尸、S 休眠异常进程
- 2.线程死锁 / 死循环
- 多线程程序卡死优先排查：互斥锁顺序颠倒、递归锁滥用、条件变量等待不唤醒
- 排查命令：
pstack 进程ID、gstack 查看线程堆栈，定位卡死在哪个锁 / 函数 - C/C++ 程序可结合
gdb attach 回溯调用栈，定位死锁位置
- 3.磁盘 IO 阻塞
- 进程长期处于 D 状态，大概率磁盘、NFS 挂载、U 盘 / 外设 IO 卡死
- 命令：
iostat -x 1 查看磁盘使用率、% util 打满
- 中断、软中断过高：
top 观察 si、hi 占用，外设驱动异常导致频繁中断
- 文件句柄打满：
ulimit -n 查看限制，lsof | wc -l 统计句柄数 - 网络连接耗尽：
ss -s / netstat -an，大量 TIME_WAIT、CLOSE_WAIT 导致端口耗尽
- 查看内存：
free -h，确认内存耗尽、Swap 大量占用 - 查看 OOM 日志：
dmesg | grep -i oom，内核是否主动杀死进程 - 排查大内存占用进程：
sort -k4nr /proc/*/status，定位内存泄漏程序
- 3.CPU 资源耗尽
- 2.句柄 / 资源耗尽
- 1.内存溢出 / 内存泄漏
- 1.系统日志分析
- 系统日志：
/var/log/messages、/var/log/syslog - 内核日志：
dmesg、dmesg -w 实时查看报错 - 重点关键字：
error、failed、oom、BUG、soft lockup、watchdog
- 2.内核锁死与软死锁
- 常见内核问题：
soft lockup 软死锁、硬锁死、CPU 调度异常 - 开启内核 panic、watchdog 监控，定位 CPU 核卡死问题
- 内核模块 / 驱动异常：自研驱动、第三方内核模块 BUG 是嵌入式设备高发原因
- 3.文件系统异常
- 磁盘坏道、文件系统损坏：
dmesg 出现 ext4 error、IO error - 只读文件系统、日志分区满导致系统无法写入，业务卡死
五、网络层排查（网络设备 / 服务端场景）
六、硬件层排查（完全死机必查）
- 硬件资源：CPU 过热降频 / 保护停机、电源供电不稳定
- 嵌入式设备重点：DDR 内存不稳定、电压不稳导致内核随机崩溃
七、长期预防与定位手段（加分项）
- 部署定时监控：CPU、内存、IO、句柄、线程数监控
- 程序增加心跳保活、锁超时、异常捕获，避免单进程卡死整机
- 内核开启 dump、core 文件生成，卡死现场保留回溯
- 嵌入式产品：精简内核、裁剪无用驱动、稳定版本内核，减少内核 BUG
面试官你好，遇到 Linux 系统卡死，我会从上到下、由应用到内核再到硬件逐步排查。
第一，先判断卡死范围：能 ping 通、能登控制台，一般是应用层问题；完全连不上、终端无响应，就是内核或硬件级死机。
第二，排查应用与进程：先用 top 看 CPU、内存、负载是否打满，检查 D 态阻塞进程、僵尸进程；多线程程序重点排查死锁、死循环、IO 阻塞，可以用 gdb、pstack 打印线程栈定位卡点。
第三，检查系统资源：查看内存是否泄漏、是否触发 OOM 杀进程；检查磁盘 IO 占用、文件句柄、网络连接数是否耗尽，这类资源打满很容易造成系统卡顿卡死。
第四，分析内核日志：通过 dmesg、系统日志查看有没有软死锁、驱动报错、文件系统异常、内存损坏等内核报错，嵌入式场景很多卡死都是第三方驱动或内核模块 bug 导致。
最后排查硬件层面：检查 CPU 过热、供电不稳定、存储坏块、外设驱动冲突等硬件问题。
整体思路就是先定位是局部应用卡死还是整机内核卡死，逐层缩小范围，快速定位根因。
10个月宝宝每天需要喝多少奶粉？