操作系统如何管理CPU资源？细说操作系统进程与多任务模型问题

进程是操作系统的核心概念，是正在运行的程序的一个抽象，那么我们有必要进行深入的分析了。

现代操作系统都是多道程序设计，意思是：我们的单核心cpu也可以“同时”运行多个程序，比如你可以一边qq，一边酷狗听歌或者再干点别的。

事实真的这样吗？你可能会说，事实真的就这样啊！那我告诉你，那是你的世界，在cpu的世界里，事实不是这样的。在cpu看来，他们是依次循环进行的（这里我们只考虑单核心）。就是说在某一个时刻，只能有一个任务在运行，要不qq，要不酷狗，但就是不能一起运行，因为它只有一个大脑。跟我们人类类似，我们的大脑在同一个时刻，也只能思考一件事情，现在的你在思考什么呢？因为cpu的运算速度非常快，在不同进程之间切换，从而给我们造成了他们一起运行的错觉，说白了就是：微观上串行，宏观上并行。有点像我们看电影，电影的微观世界里，是一帧一阵的静态图像，只是因为连续的切换，我们才看到了动态的影像。

既然进程是程序运行的实体，那么一个进程需要哪些信息呢?先来举个做菜的例子吧，我暂时没想到更好的。这就需要考虑好多东西了，首先你得确定你要做几道菜，3道5道还是100道。每一道菜都有自己的名字；每一道菜都需要不同的原材料；每一道菜都是不同的制作手法；其实执行几个程序，跑几个进程，跟做菜没什么两样，我在怀疑这些科学家们是不是个个都是做菜的好手，俗话说的好嘛：会生活的人才会工作！呵呵

如果执行了2个进程，那么这两个进程的名字肯定是不一样的了，我们就需要用一个唯一的标示符来区分他们；两个不同进程肯定执行的内容是不同的吧，那他们需要的运算数据肯定也不同，比如计算器需要的是大量数字计算，酷狗就只需要歌曲信息解码了；菜的制作手法就等价于进程的算法了。

说这么多，还差一点！既然我们知道cpu的微观世界，进程是串行进行的。那到底是怎么串行的呢？

举个例子：进程a：计算（34+54）*38；进程b：解码播放“假如你做了别人的小三儿”。以cpu时间为运行尺度。0-10ms：计算（34+54）= temp；10-30ms：解码播放“假如你做了”；30-40ms：计算temp*38 = 结果；40-60ms：解码播放“别人的小三儿”。至此，cpu在0-60ms内干了俩活儿，这么短的时间，估计我们是感觉不到俩活的切换的，满足了我们在听歌的同时顺便写写数学作业的要求！

既然涉及到了进程切换，那都切换些什么呢：

进程是程序的一次有效执行流，在10ms的瞬间，cpu把进程a移出到内存；30ms瞬间，cpu又把进程a移入到寄出去；为了保证计算的正确性，操作系统自己就要确保，当移出a时，必须保存a的当前计算位置（其实就是PC值），以便下次运行时接着上次暂停的地方运行，有点像我们读书时用的书签；有了计算位置还不够，还有保存进程a移出之前的状态信息和数据，例如临时数据如temp等等（进程上下文，说着叫进程运行环境）。

操作系统对进程的切换，对进程来说是透明的。就是说：进程并不知道，自己被操作系统给换来换去的，断断续续的执行，进程一直以为自己操作系统的唯一，没曾想被卖了还得替人家数钱呢！专业话叫做：从概念上说，每个进程拥有它自己的虚拟cpu，实际上真正的cpu在各个进程之间来回切换。

假设内存中有4道程序，每个进程都有自己的控制流（PC指针），各个进程都相互透明，即谁也不知道谁，但都正确的执行着。这怎么有点像我们的某些包2奶8奶的父母官啊，家里红旗不倒，外面彩旗飘飘的！看来他们是真正掌握操作系统精髓，并能熟练运用炉火纯青的人哪！实际的cpu只有一个物理PC，某个进程在运行时，它的逻辑PC值就被装入物理PC中，物理PC值运行并更新；当下一个进程要运行之前，该物理PC的值就又一次写回到当前进程的逻辑PC中，以保存执行位置（其实还保存了其他状态信息）。

操作系统就这么的来回切换运行进程，你说他累不累啊！

多进程执行，一定比单进程好吗？就一点问题没有吗？

进程是程序的一次执行过程，操作系统以进程为单位调度任务；

多个进程共享CPU，每个进程都有自己的虚拟CPU，物理CPU就在这些虚拟CPU之间来回切换，构成多任务模型。

其实从单个任务的角度看，他们是不喜欢甚至讨厌操作系统的！

为什么？因为进程跟人一样，是贪得无厌的，而操作系统剥夺了他们独占硬件资源的权力！
注意：

由于CPU在各个进程之间来回快速切换，所以每个进程执行其运算的速度是不确定的；而且当同一个进程再次运行时，他的运算速度通常不可再现；所以，在对进程编程时决不能对时序做任何确定的假设。

分析：

1.由于硬件资源CPU有限，各个进程轮流运行，那么从单个任务的角度，他的执行过程就要受到其他任务的影响，比如其他任务的优先级，任务数量的多少等等！就像开车一样，你的奔驰能开250，但是也得路况满足才行，如果你在北京的路上，估计最多25了，呵呵！谁都想开的更快点，但是道路有限，别的车也得跑不是。所以你开车速度的多少（进程速度），就不取决于你自己了，取决于：道路的宽窄（CPU能力）、其他车的多少（进程数量），特权车的多少（优先级）。

2.再以北京交通为例，同一条道路，每一天的交通路况都不相同，取决于：车数量的多少，天气情况，是否有交通事故等等。那么你开同样一辆车，同样的道路，不同时间走得快慢就不一样，所以用的时间就不同了，这个很好理解。

3.正因为你不能对外界环境做非常精准的预期，同样你不能对自己的开车速度和开车时间做精准预期。天气多变，尾号限行，严重的你一晚上都未必能到家，比如说前两天北京的大暴雨，有的人3点才能到家，而有的人根本就到不了家了，哎！他们有错吗？他们没有区别，区别的是外部环境。祝福那些到不了家的人吧，更祝福你们的家人！

本质：

其实这种现象的造成，是有本质原因的。在于操作系统和单个进程本身，他们是一对矛盾体，各自存在的目的是不同的！

操作系统的存在：计算机那么多硬件资源，每次只让其中一个干活，其他人歇着太浪费了，我得把他们组织起来，谁都不能偷懒。有点资本家的味道，呵呵！

进程的存在：我有我的任务，就是最快的把我这边的工作完成，好向老板要奖励，我才不管他们之间谁歇着呢，只要我交给他们的活儿，一直没停就行。苦命的码农啊！

即：操作系统是为了宏观上硬件利用率的最大化，减小瓶颈损失；单个进程是为了独占资源，快速运行。一个全局一个个体，目的不同，矛盾产生！

既然矛盾天然形成，那么我们就只能最大化的避开。

注意：

当一个进程具有严格的实时要求时，也就是一些特定事件一定要在所指定的若干毫秒内发生，那么就必须采取特殊措施保证他们一定在这段事件中发生。但是，通常大多数进程并不受CPU多道程序设计或者其他进程相对速度的影响。

例如：进程A延时3S，操作系统就会让其阻塞，调度其他进程运行；等3S时间到，并不是说这个进程就能马上运行，而是操作系统把A再次放入就绪队列，产生调度中断。问题就在这里，调度中断并不能保证A一定运行，这跟调度算法有关了，其实就是刚开始说的问题了。如果想马上运行，就必须在优先级上，在调度策略上进行优化了！说了半天，又转回来了，其实就是一个问题。