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