linux进程D状态的原理是什么

本篇内容介绍了"linux进程D状态的原理是什么"的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

简单来讲

1）内核 每隔一段时间都会统一接受所有进程的请求（这里可能与CPU时间片有关系，需要进一步确认），如果发现有进程发起了请求，首先内核会去获取进程所需要的资源，然后把这个进程暂时放到一个 parking 队列里；这里类似于需求收集阶段。

2）在需求收集结束后，会把发起请求的进程放到一个runnable 队列里，等待执行。

3）把 runnable 队列里的进程依次执行。

进程的 D 状态（Uninterruptible Sleep）发生在需求收集阶段。试想在这个阶段，当内核去获取进程所需要的资源的时候，比如从磁盘读取某一个文件，这个时候突然磁盘驱动不干活了（可能因为取的数据太多驱动没反应过来，也可能因为磁盘出了故障），这个时候内核就为难了，场面变得比较尴尬。

1）首先驱动是工作在内核态的，内核对驱动有绝对的信任权；其次，

2）进程发起请求了，自己作为老大于情于理都应该应承；

3）但是进程所要求的数据实在拿不到怎么办呢？

4）这个时候内核只能把进程的状态临时转换为 D 状态，标明这个锅是内核自己的，内核正在尝试获取进程需要的资源，而且获取资源的途径是内核可控的（内核必须对全局的资源拥有控制权限，否则也不要当内核了）。

上面的情况，如果进程所需要的数据很快就被内核拿到了还好（大部分情况下都是如此），进程会从 D 状态转到可运行的状态；如果拿不到（比如真的磁盘出现了故障，而驱动代码又没有考虑到这种情况，或者驱动抛出了信号但是内核不承认），那么相应的进程就会一直处于 D 状态。非常戏剧性的是，只有处于可运行状态（Runnable）的进程可以接受终止信号（ kill 信号），处于 D 状态的进程是没有办法被 kill 掉的；这也让终止 D 状态的进程变得复杂--必须重启服务器才能把 D 状态的进程杀掉……不过想一想也好理解，因为流程卡在内核那里，这个时候内核与进程是绑定的状态，内核限制进程不接受被 kill 的信号也是理所当然的（我的理解是，这里的内核过于自信了，我的故障机是4.4.0内核版本，或许高版本的已经没有这个问题了）。

参考：

https://jingwei.link/2018/12/23/linux-cpu-load-d-process.html

"linux进程D状态的原理是什么"的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站，小编将为大家输出更多高质量的实用文章！