先记住这个答案
进程处于 D 状态表示它正在内核态等待一个不可中断的 IO 事件，例如磁盘读写或 NFS 请求。此时信号无法被处理，因为进程没有机会回到用户态执行信号处理器，所以 kill -9 也无效。排查时先确认进程卡在哪个 IO 栈，查看 /proc/<pid>/stack 的函数调用链，用 dmesg 检查内核报错，再针对具体设备恢复（如重启 NFS 服务或切换磁盘路径），之后进程会恢复运行或按挂载选项返回错误退出。
- D状态等待IO，任何信号无法递送
- 查看stack与dmesg定位内核卡点
- 恢复设备IO或重启才能退出
D状态为何杀不掉
D 状态是 Linux 的不可中断睡眠，进程在内核模式执行系统调用，等待磁盘、网络等 IO 完成。内核把进程置入睡并将等待队列挂到设备驱动程序上，这个睡眠不带 TASK_INTERRUPTIBLE 标志，因此信号不会唤醒进程，也无法执行用户态的信号处理器。
当 kill 发送信号时，内核只会给进程挂一个待处理标记，进程必须在返回用户态时才有机会检查。但 D 状态的内核路径不会检查信号，所以进程永远停在原处。此时 SIGKILL 同样无效，因为它也需要进程进入内核的信号处理流程。
NFS 掉线导致进程卡死的排查
某服务器挂载了 NFS，NFS 服务器突然宕机。发现大量进程处于 D 状态，kill -9 无效。执行 ps -eo pid,stat,wchan:30,cmd，看到 wchan 为 nfs_wait_bit，确认卡在 NFS 等待。查看 /proc/<pid>/stack 显示 rpc_wait_bit_killable 等函数，dmesg 有 nfs: server not responding 错误。
处理时，若 NFS 为 soft 挂载，超时重试后进程会收到错误并退出；若为 hard 挂载，则不会超时返回，需恢复 NFS 服务器后 IO 完成，进程继续执行。对于无法及时恢复的场景，只能重启系统或强制卸载挂载点，重启前需备份进程数据。实际操作中先检查 IPC 层是否还有活动，避免盲目重启扩大损害。
D状态的可恢复边界
并非所有 D 状态都会永久卡死。若底层 IO 有超时机制（如磁盘 SCSI 超时），等待超过阈值后内核会报错唤醒进程，进程可能终止或重试。只有当驱动或硬件无超时机制，或挂载选项不返回错误（如 NFS hard 挂载）时，进程才会一直等待，这种场景多出现在网络文件系统或故障硬件上。
排查时需结合 /proc/<pid>/syscall 查看当前系统调用，判断是 read、write 还是其他等待。对可恢复的 D 状态，耐心等待即可；对长期不解除的，检查硬件健康或升级内核补丁。不能简单用 kill 或 sysrq 强制结束，可能破坏文件系统一致性。
容易答错的地方
- D状态进程等一会自己会醒
- 很多 D 状态是短暂的，比如磁盘 IO 高负荷时，进程可能睡眠几毫秒就恢复。若长时间不恢复且无超时，说明底层 IO 失效，需要人工干预，不能一律认为会自愈。观察
ps的时间戳来区分。 - kill -9 一定能杀掉所有进程
- SIGKILL 默认不可被屏蔽，但 D 状态进程因不返回用户态而无法响应，所以确实杀不掉。忽略会延误恢复。正确做法是定位 IO 依赖，恢复设备后自然退出。
面试官还会怎么问？
D 状态时进程能否被进程组信号唤醒？
不能。不可中断睡眠在内核等待队列中，信号只在进程被唤醒后检查，且 D 状态不设置 TASK_INTERRUPTIBLE，因此即使发信号也只挂起标记，无法提前唤醒。只有 IO 完成或错误才能唤醒。
如何确定进程是卡在磁盘还是网络？
用 cat /proc/<pid>/stack 看内核栈，若包含 ext4、scsi 等则是本地磁盘，含 nfs、rpc 则是网络；也可用 lsof 查看打开的文件，或 fuser -v 定位到挂载点。
D 状态进程占用 IO，为什么杀掉反而可能破坏数据？
进程在内核态等待 IO 时可能持有锁或正处于写盘中途，强制结束或重启系统不会回滚内核操作，可能留下不一致的元数据。正确做法是让底层 IO 返回失败，使进程自行退出，才能保证文件系统完整性。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。