大家好，我是苏貝，本篇博客带大家了解Linux进程（8）：Linux真正是如何调度的，如果你觉得我写的还不错的话，可以给我一个赞👍吗，感谢❤️

---

之前我们讲过，在大部分操作系统课本里面，进程的调度是将进程的pcb依次链入一个运行队列中，那Linux也是这样调度的吗？如果是这样的话，进程的优先级有什么用呢？

事实上，Linux调度不是将进程的pcb依次链入一个运行队列中。让我们来了解一下Linux是如何调度进程的

Linux系统中，每个CPU都有一个运行队列runquene

我们先看蓝色框框，nr_active: 总共有多少个运行状态的进程。
quene[140]，它会为我们维护有140个队列的数组，它的完整结构是task_struct* queen[140]。Linux采用的是分时操作系统，在分时操作系统中，该数组只使用下标[100,139]这40个队列。你不觉得很巧合吗，Linux的优先级也有40个数字[60,99]（默认的优先级是80，nice的范围是[-20,19]）

下标为100的队列放的是优先级为60的进程，下标为101的队列放的是优先级为61的进程……下标为139的队列放的是优先级为99的进程（队列的下标和进程的优先级之间差40）

所以如果有一个优先级为60的进程，那么先加40=100，然后将进程链入下标为100的队列中，有多少进程就往后链入多少进程

所以如果我们想找到一个优先级为60的进程，那么直接+40=100，找到下标为100的队列，再从链入该队列的进程中一个一个往后找就可以了。可是如果我们想找一个进程，v它的优先级是80，，我们难道就要从下标为100的队列开始遍历，一直遍历到下标为120的队列才可以吗？

不需要。Linux中还为我们准备了bitmap[5]，也是在蓝色框框里，它的完整结构是long bitmap[5]。为什么有5个元素呢？

为什么要与140比呢？不要将long理解成类型，将它理解为32个比特位，每个比特位都代表对应下标的队列中有没有链入进程，如果有，那么该比特位为1；如果没有，则为0。我们上面的图里只画了对应下标[100 ,139]的比特位。

可能有人会说了，那这不还是要遍历吗，看每一个下标对应的比特位是否为0？其实不用，我们可以32位一起查，如果bitmap[0]==0，说明前32个比特位全为0，所以对应下标的队列都没有进程。

Linux中以上述方法查找进程，它的时间复杂度几乎为O(1)

再来看红色框框，我们发现，红色和蓝色框框怎么是一样的？其实它们是同一个结构体的2个变量array[0]和array[1]

运行队列runquene中还有2个指针需要我们了解：active和expired。active指针默认指向array[0]，expired指针默认指向array[1]。CPU在找进程的时候，不是直接访问array[0]或array[1]的quene[140]的，而是找到active指针，指针指向的是哪个，CPU就访问哪个的quene[140]。这么说，难道active指针还会变化，指向array[1]吗？是的，让我们接着往下看

假如此时active指针指向array[0]，那么CPU调度进程时，就访问array[0]的quene[140]，这时array[0]的quene[140]的队列只出不进：进程结束，就从CPU上剥离进程的pcb；时间片到了，不再链入本quene[140]，而是链入另一个quene[140]对应的队列；如果有新的进程，那么也不再链入本quene[140]，而是链入另一个quene[140]对应的队列

等到本quene[140]中没有进程了，就将active指向array[1]，让empired指向array[0]，CPU运行进程时，就访问array[1]的quene[140]，此时它就变成了只出不进，另一个就是只进不出

---

好了，那么本篇博客就到此结束了，如果你觉得本篇博客对你有些帮助，可以给个大大的赞👍吗，感谢看到这里，我们下篇博客见❤️