CPU 单核频率到瓶颈了吗？人类就用多核芯来弥补单核处理器性能的不足，咱们的 CPU 不也升级到四核
现在最多能并行处理 4 个进程，效率比以前高多了，这还不好吗？”内存疑惑的问。
“好是好，可我每次上 CPU 运行的时候，都忍不住去想，要是单核频率不增加，我总的运行的时间不还是没有什么变化吗？以后的应用程序越来越大，越来越吃 CPU 资源，比如那些大型游戏进程，在短时间内需要进行大量计算，靠单核撑不住怎么办。
注：很明显单进程的运行时间是变小了的，不过这里主要强调的是进程占用 CPU 的时间。
“一个进程怎么并行？”进程调度器第一个发出疑问：“我总不能把一个进程放在四个核上吧，这样不仅毫无意义，还阻碍了其他进程的执行。”
操作系统见多识广，说：“把进程一次放在几个核上运行肯定是不可能的，我在想，咱们的目标，其实就是让多个核心不冲突地帮助一个进程运行嘛。那我们就得把进程「拆开」，然后放在几个核上。”
操作系统摇摇头：“不是拆成多个进程，进程切换的代价太大了，再说了，这些拆出来的函数，他们是共用一个地址空间的，天生就能够数据共享，如果拆成进程，我们还得再考虑进程之间的通信问题，那多麻烦。不过为了跟进程区分，就叫他们「线程（Thread）」吧”
进程调度器也慌了：“要是没了进程，我是不是也要被退休了？”
操作系统赶忙解释道：你们误会了，我要拆开的，是进程的执行流，进程不是包含了资源所有权和执行流吗，资源所有权还是由进程来把控，执行流就分给几个线程，就像这样：
在进程模型里，进程拥有对内存、I/O 通道、I/O 设备和文件等资源的控制权，称之为「资源所有权」。「执行流」可以看做进程在 CPU 上的执行过程（直观一点就是高级语言里的语句）。
进程恍然大悟：“也就是说我仍然是资源的掌控者，那些线程就相当于帮我干活的小弟？”
存发问了：“创建进程的时候，我要保存进程 PCB ，那为了创建线程，我是不是还得创建一个 TCB（Thread Control Block）？”
“当然了，线程切换需要的信息就得存在 TCB 里面。不过你放心，TCB 要比 PCB 小得多，所以线程切换会比进程切换快很多。”
但是操作系统面露难色，说：“线程模型只是我们的一个假想，贸然加进来的话，可能会出问题，系统崩溃可就不好了，还是要以稳定为主。。。但这个模型还是得试的，要不我们先创建一个线程库，靠一个用户级别的应用程序——线程调度器来管理这些线程吧。”
进程不解的问：“可是这样的话，我还是被分配在一个单独的核心上啊，即使是多线程，也只能在单核上运行。再说了，如果这些线程里有一个被阻塞，在你看来，是整个进程阻塞了，那其他线程，即使是就绪态，也得不到 CPU 资源。”
，用户级线程确实有这两个缺点，但相比起让内核来实现线程，用户级线程也有他的好处——线程切换不需要我进行状态转换（从用户态到内核态），开销小，除此之外，线程库可以有多个调度算法，能够为应用程序量身定做调度算法。”
有一种解决线程阻塞的方案叫 jacketing，他可以把一个产生阻塞的系统调用转化成一个非阻塞的系统调用，比如说，不直接调用系统级的 I/O 例程，而是让线程调用应用级的 I/O jacket 例程，这个 jacket 例程会检查 I/O 设备是否忙，如果忙的话，就不执行 I/O 操作，转而调度其他线程，避免了因等待 I/O 设备而造成的进程阻塞。
用户级线程很快投入使用，Linux系统中的 pthread（POSIX thread）库可以说是大获成功，操作系统做出了一项重大决定——支持内核级线程。
内核级线程解决了进程并行的问题，除此之外，由于内核看得到线程的存在，一个线程阻塞了，位于同一个进程中的其它线程仍然能够运行。
进程调度器是调度计算机内所有的进程，为他们分配 CPU 资源。
所谓 FCFS 就是「先来先服务（First Come First Serve）」，每个进程按进入内存的时间先后排成一队。每当 CPU 上的进程运行完毕或者阻塞，我就会选择队伍最前面的进程，带着他前往 CPU 执行。
FCFS 算法确实有这个缺陷——短进程的响应时间太长了，用户交互体验会变差。
「短任务优先」（Shortest Process Next，SPN）。每次选择预计处理时间最短的进程。因此，在排队的时候，我会把短进程从队列里提到前面。
这一次，短进程得到了很好的照顾，进程的平均响应时间大大降低，我和操作系统都很满意。
但长进程们不干了：那些短进程天天插队，导致他们经常得不到 CPU 资源，造成了「饥饿」现象。
取消 SPN 算法的呼声越来越高。
这可是个大问题。FCFS 虽然响应时间长，但最后所有进程一定有使用 CPU 资源的机会。但 SPN 算法就不一样了，如果短进程源源不断加入队列，长进程们将永远得不到执行的机会——太可怕了。
综合考量进程的两个属性：等待时间和要求服务时间——等待时间长，要求服务时间短（就是短进程）的进程更容易被选中。
响应比 = （等待时间+要求服务时间）/ 要求服务时间。响应比高的算法会先执行。我们称之为「高响应比优先」（Highest Response Ratio Next，HRRN）。
随着计算机的普及，个人用户大量增长，并发，即一次运行多个程序的需求出现了。这可难倒我了——处理器只有一个，怎么运行多个程序？
所幸 CPU 点醒了我：“我现在的运算速度既然这么快，何不发挥这项长处，弄一个「伪并行」出来？“
“伪并行？什么意思”
“就是看起来像并行，实际上还是串行。每个进程短时间交替使用我的资源，但在人类看来，这些进程就像在「同时」运行。
经过 CPU 的提醒，我很快制定出了新的调度算法——时间片轮转算法（Round Robin，RR）。
在这个算法里，每个进程将轮流使用 CPU 资源，只不过在他们开始运行时，我会为他们打开定时器，如果定时器到时间（或者执行阻塞操作），进程将被迫「下机」，切换至下一个进程。至于下一个进程的选择嘛，直接用 FCFS 就好了。
新的算法必然会面临新的问题，现在我的问题就是，时间片的长度怎么设计？
直观来看，时间片越短，固定时间里可运行的进程就越多，可 CPU 说过，切换进程是要消耗他不少指令周期的，时间片过短会导致大量 CPU 资源浪费在切换上下文上。时间片过长，短交互指令响应会变慢。所以具体怎么取，还得看交互时间大小（感觉像没说一样，但至少给了个标准嘛）。
这一阶段，我的工作量大大提升——以前十几秒都不用切换一次程序，现在倒好，一秒钟就得切换数十次。
时间片轮转算法看起来十分公平——所有的进程时间片都是一样的。但事实真是这样吗？
I/O 密集型进程不这么认为，他对我说：“调度器大哥，时间片轮转没有照顾到我们这类进程啊！我们经常在 CPU 没呆到一半时间片，就遇到了阻塞操作，被你赶下去。而且我们在阻塞队列，往往要停留很长时间。等阻塞操作结束，我们还得在就绪队列排好长时间队。那些处理器密集型进程，使用了大部分的处理器时间，导致我们性能降低，响应时间跟不上”
考虑到这些进程的要求，我决定为他们创建一个新的辅助队列。阻塞解除的进程，将进入这个辅助队列，进行进程调度时，优先选择辅助队列里的进程。
这就是「虚拟轮转法」（Virtual Round Robin，VRR）。
操作系统忽然找到我，神神秘秘的说：“调度器啊，你是知道的，我要给整个系统提供服务，可最近用户进程太多，导致我的服务进程有时候响应跟不上。我有点担心这会给系统稳定性造成影响。”
我一听，这可是个大事，系统不稳定那还得了？调度算法得换！
既然要让操作系统的服务得到足够的运行资源，那就，干脆让他们具有最高的 CPU 使用优先权吧。
优先级调度算法就此产生了。
我向大家做出了规定——每个进程将被赋予一个优先级，自己根据自己的情况确定优先级数值，但是，用户进程的优先级不准高于内核进程的优先级。
切换程序的时候，我会从优先级 1 的队列里选择一个进程，如果优先级 1 队列为空，才会选择优先级 2 中的进程，以此类推。
当然，为了保证低优先级进程不会饥饿，我会调高等待时间长的进程的优先级。
使用这个算法，我更忙碌了，不仅需要大量切换进程，还需要动态调节优先级。可能这就是能力越大，责任越大吧。
不过我知道，正是因为我的存在，人类才能在计算机上运行多道程序。
参考链接
https://mp.weixin.qq.com/s?__biz=MzUyMzU5ODczNA==&mid=2247483688&idx=1&sn=662216279b28c21366d8bcaa1f9e8d21&chksm=fa3b6fc9cd4ce6df357cd7a89265406b7c6febfc559d2fdace0f88006b782df05674db7c5671&scene=21#wechat_redirect
