微软系统的进程管理，无法就是打开任务管理器，查看进程、结束进程、或者创建进程。但是在Linux系统中进程管理是一件比较复杂的工作了。本文就来详细介绍一下Linux系统进程管理。

　　普通调度算法

　　FCFS

　　First Come First Service。FIFO方式的调度策略，先来后到的服务方式。

　　这种方式的优势是实现简单，也是最容易想到的调度方案。但是有两个重大问题：

　　1.对短进程的运行不利

　　短进程必须等到前面长进程执行完毕了之后才能运行，可能会等待较长时间。

　　2.对IO密集型运行不利

　　IO密集型比短进程还惨。还不容易排队等到他运行了，结果没运行一会儿就因为IO阻塞去了，等IO操作完毕了之后，还得重新排队。

　　所以这个算法对IO密集型的进程运行效率是极其低下的。

　　RR

　　Round Robin。轮询调度算法为每个进程分配固定的时间片，时间片用完了就必须重新到队尾去排队。

　　这样的设计解决了FCFS的第一个问题，相对而言也部分解决了第2个问题。

　　但是对IO密集型进程依然解决得不太好，有一个优化的方案就是设计两个队列，将因为IO阻塞的进程单独放一个队列，在选择下一个运行进行的时候对这个队列的进程提权。

　　FCFS还有另外一个比较复杂的问题就是如何选择时间片。时间片过长就退化成FCFS算法了，过短又会造成切换开销太大。

　　Prediction

　　基于预测的算法。这类预测算法都是假设我们知道每个进程总共所需要的时间，以及IO占比信息。 上一页12345下一页共5页

　　假设我们能收集到这些信息，可以有如下几种调度算法：

　　1.最短运行时间优先

　　2.最短剩余时间优先

　　3.综合已经运行时间和剩余时间来排序

　　但是在真实世界中，一般这个信息是无法预测的。即使是同一个进程，之前运行的情况对当前运行的进程也不一定有参考价值。比如cat程序，不同参数对运行时间影响很大。

　　Feedback

　　这个是基于Prediction来优化的。如果说Prediction是需要预测将来进程还需要多少资源的话，Feedback算法就是基于已经消耗了的资源来判断优先级。

　　一般来说，也就是运行时间越长，优先级越低的调度算法。

　　Unix调度算法

　　老版调度算法

　　这是2.6版本之前的调度算法，该算法采用优化的RR算法，每个进程的优先级算法如下：

　　p（i） = base（i）+nice（i）+cpu（i）

　　其中base和nice值都是静态固定的，可以由用户指定的。

　　cpu是随着进程占用CPU时间越长权重就越低的调整因子，该因子调整逻辑如下：

　　cpu（i） = cpu（i-1）/2

　　也就是每次进程被选中调度一遍之后，下次对应的cpu因子的值都会被除以2，降低下次运行的权重。

　　新版调度算法

　　内核2.6版本之后重写了调度算法。也叫O（1）算法。

　　该算法针对普通进程，设置了100~139共40个优先级，进程属于哪个优先级的计算跟老版调度算法类似。系统再存储了一个位图，每个位图代表一个优先级是否有等待的进程。然后每次都选择优先级最高的且有进程的那个队列选取第一个进程来运行。

　　SMP的调度

　　对于多处理器的处理，跟上面的调度算法类似，只是在选择出进程之后，需要再判断一下给哪个CPU合适。

　　一般来说，考虑到CPU的本地cache，所以尽量将进程调度到之前运行的CPU上运行。当然，考虑到CPU本身的均衡性，所以肯定还是会有迁移的工作。 上一页12 345下一页共5页

　　线程相关

　　用户线程&内核线程

　　线程从一开始诞生就有两个分类：用户级线程 和 内核级线程。

　　我们在Linux上常见的是内核级线程， 即线程调度相关操作都在内核里实现， 不太常见的是用户级线程。

　　用户级线程的优势是：

　　1.线程切换成本低，不用内核操作

　　2.用户可以自定义线程调度策略

　　3.跟操作系统无关，可以很快移植到另外一台机器上

　　但是用户线程也有如下问题：

　　1.一个线程的阻塞会影响其他线程，因为操作系统看不到别的线程

　　2.不能很好的利用多核能力，因为操作系统会把一个内核进程放到一个CPU上

　　目前Linux上只使用内核级线程， Solaris上面两者都提供。

　　线程切换

　　一个进程的上下文主要有如下几个部分的信息构成：

　　1.程序计数器

　　2.寄存器信息

　　3.栈信息

　　一个进程切换的过程包含：

　　1.保存当前进程的上下文

　　2.将当前进程加入操作系统对应队列

　　3.通过调度算法选择另外一个进程

　　4.调整虚存映射

　　5.加载新进程的上下文

　　但是线程切换就不一样了，之需要切换PC寄存器指向的代码地址就好，其他操作都不用做，所以线程切换的成本比进程切换低多了。

　　互斥和同步

　　简介

　　当多个进程需要对同一个资源进行访问的时候， 为了避免同时使用这个资源造成的混乱， 所以需要考虑进程间的互斥。

　　典型的互斥实现方案如下：

　　方案介绍

　　中断禁用

　　杀敌一千， 自损八百。虽然能实现互斥， 但是大大降低了处理器的执行效率。而且再多处理器体系结构中， 他还不能达到互斥

　　专用机器指令

　　往往是通过一个不可中断的指令， 用于原子修改内存中的值， 常见的两个指令是testset和exchange， 其对应的demo代码如下图。该方案的好处是实现简单， 坏处是使用了忙等待， 可能出现饥饿， 可能死锁， 需要操作系统层进行管理和避免。 上一页123 45下一页共5页

　　死锁的避免

　　死锁出现有4个必要条件：

　　1.互斥： 资源只能同时被一个进程使用

　　2.占有且等待： 一个进程在等待别的资源的时候， 将继续占有其拥有的资源

　　3.非抢占： 不能强行抢占别人占有的资源

　　4.循环等待： 在满足如上3个条件的情况下， 出现循环等待即出现死锁

　　要避免死锁也是从这4个条件上下手：

　　1.互斥： 这个是为了资源功能正常运转， 无法避免

　　2.占有且等待： 让进程一开始就申请所有资源才能运行。问题是效率低下， 进程可能要等待很长时间， 资源可能被控制很长时间， 程序也需要最开始就知道需要使用哪些资源;

　　3.非抢占： 根据进程优先级让申请资源的进程释放自己之前拥有的资源或者抢占别的进程的资源， 靠谱， 唯一的问题在于资源的使用不一定有那么容易的保存和恢复（很多硬件不像处理器那样可以随意切换使用进程的）

　　4.循环等待： 给资源定义一个序列， 进程只能按照序列申请资源， 会导致进程执行效率大大降低， 所以主流做法是如下两种

　　如上几种避免办法都有各种各样的问题， 所以一般不采用， 现在采用最多的方案还是从第4点出发， 只不过不预先避免， 而是动态探测：

　　1.如果一个进程启动或者新增资源需求会导致死锁， 则不允许此分配

　　典型的算法如银行家算法， 此方法的弊端是需要知道一个进程将来所需要占用的资源

　　2.允许所有请求， 周期性的进行检测死锁

　　动态检测， 运行效率高， 但是如果出现死锁频率比较高， 则系统运行效率会比较低。

　　综合所有的死锁避免的方法的对比如下：

　　编程界面

　　多进程之间的互斥与同步方案有了如上提到的系列硬件支持之后， 就需要考虑操作系统对有并发编程的程序员们提供的编程界面了。

　　信号量

　　信号量是在内存中维护了一个int， 每次操作对该int进行++或者--。

　　对操作者提供了两个接口：

　　1.semWait

　　该接口检查int值， 如果该值大于0， 就将该值--， 并进入临界区; 否则就阻塞检测该值知道大于0;

　　2.