D状态进程需先用ps或/proc/PID/status确认，本质是等待I/O资源，应排查NFS、磁盘、设备等依赖并恢复，禁用kill -9，避免盲目重启。
确认进程确实处于 D 状态
先用 ps 查看进程状态，重点关注 STAT 列：
- D 表示 Uninterruptible Sleep（不可中断睡眠），常见于等待磁盘、NFS、设备驱动等底层 I/O 资源
- 执行
ps -o pid,ppid,stat,comm -p <pid></pid>或ps aux | grep <pid></pid>，确认状态为 D - 进一步验证：读取
/proc/<pid>/status</pid>，检查 State: 字段是否为D (disk sleeping)
优先排查并恢复资源依赖
D 状态本质是“卡在内核里等东西”，不是进程故障，而是它等待的资源没到位。强行杀无效，必须让资源可用：
- 若进程在访问 NFS 挂载点：检查服务端是否存活，网络是否连通，客户端是否仍挂载；尝试
umount -f强制卸载（部分场景需配合lazy） - 若涉及本地磁盘：用
smartctl -a /dev/sdX检查磁盘健康，dmesg | tail -50查看是否有 I/O 错误或 timeout 日志 - 若由存储设备（如 USB、iSCSI、RAID 卡）异常引起：重启对应设备或控制器，或拔插重连（生产环境需评估影响）
- 若因锁竞争（如多个进程争抢同一块设备或文件锁）：通过
lsof -p <pid></pid>和strace -p <pid></pid>辅助定位阻塞点
避免误操作，不推荐直接重启
重启系统虽能清除所有 D 进程，但属于“终极手段”。在关键业务中应尽量规避：
- 观察
vmstat 1中的 b 列（uninterruptible processes 数量），持续高位说明问题未解 - 检查
cat /proc/loadavg，若 load 长期高于 CPU 核数且伴随大量 D 进程，反映 I/O 子系统已严重受阻 - 不要对 D 进程反复执行
kill -9——它不起作用，还可能掩盖真实瓶颈 - 若确认是硬件故障（如坏盘、断链），及时隔离设备并切换备用路径，比等进程超时更可靠
特殊情况下的临时缓解
某些场景下无法立即修复资源，但需降低影响：
- 如果 D 进程是某个容器或虚拟机内部的，可尝试重启该容器或虚机（而非宿主机）
- 若进程属于某项服务（如数据库写盘线程），可临时停止该服务，待底层 I/O 恢复后再启
- 对长期卡死的 D 进程，Linux 内核一般会在资源超时后自动唤醒并报错退出；耐心等待几分钟有时比干预更稳妥
