进程调度算法

FCFS调度算法属于不可剥夺算法。从表面上看，它对所有作业都是公平的，但若一个长作业先到达系统，就会使后面许多短作业等待很长时间，因此它不能作为分时系统和实时系统的主要调度策略。但它常被结合在其他调度策略中使用。例如，在使用优先级作为调度策略的系统中，往往对多个具有相同优先级的进程按FCFS原则处理。

FCFS调度算法的特点是算法简单，但效率低； 对长作业比较有利，但对短作业不利（相对SJF和高响应比）；

FCFS调度算法有利于CPU繁忙型作业，而不利于I/O繁忙型作业。

​ 短作业优先调度算法是一个非抢占策略，他的原则是下一次选择预计处理时间最短的进程，因此短进程将会越过长作业，跳至队列头。该算法即可用于作业调度，也可用于进程调度。 但是他对长作业不利，不能保证紧迫性作业（进程）被及时处理，作业的长短只是被估算出来的。

缺点：

该算法对长作业不利，SJF调度算法中长作业的周转时间会增加。更严重的是，如果有一长作业进入系统的后备队列，由于调度程序总是优先调度那些 (即使是后进来的）短作业，将导致长作业长期不被调度（“饥饿”现象，注意区分“死锁”。后者是系统环形等待，前者是调度策略问题）。

该算法完全未考虑作业的紧迫程度，因而不能保证紧迫性作业会被及时处理。

由于作业的长短只是根据用户所提供的估计执行时间而定的，而用户又可能会有意或无意地缩短其作业的估计运行时间，致使该算法不一定能真正做到短作业优先调度。

SJF调度算法的平均等待时间、平均周转时间最少。

高响应比优先调度算法既考虑作业的执行时间也考虑作业的等待时间，综合了先来先服务和最短作业优先两种算法的特点。

该算法中的响应比是指作业等待时间与运行比值，响应比公式定义如下：

响应比 =（等待时间+要求服务时间）/ 要求服务时间,即RR=（w+s）/s=1+w/s，因此 响应比一定是大于等于1的。

短作业与先后次序的兼顾，且不会使长作业长期得不到服务。

响应比计算系统开销，增加系统开销。

高响应比优先调度算法适合批处理系统，主要用于作业调度。

为了实现 RR 调度，我们将就绪队列视为进程的 FIFO 队列。新进程添加到就绪队列的尾部。CPU 调度程序从就绪队列中选择第一个进程，将定时器设置在一个时间片后中断，最后分派这个进程。

接下来，有两种情况可能发生。进程可能只需少于时间片的 CPU 执行。对于这种情况，进程本身会自动释放 CPU。调度程序接着处理就绪队列的下一个进程。否则，如果当前运行进程的 CPU 执行大于一个时间片，那么定时器会中断，进而中断 *** 作系统。然后，进行上下文切换，再将进程加到就绪队列的尾部，接着 CPU 调度程序会选择就绪队列内的下一个进程。

采用 RR 策略的平均等待时间通常较长。

在 RR 调度算法中，没有进程被连续分配超过一个时间片的 CPU（除非它是唯一可运行的进程）。如果进程的 CPU 执行超过一个时间片，那么该进程会被抢占，并被放回到就绪队列。因此， RR调度算法是抢占的。

算法描述

1、进程在进入待调度的队列等待时，首先进入优先级最高的Q1等待。

2、首先调度优先级高的队列中的进程。若高优先级中队列中已没有调度的进程，则调度次优先级队列中的进程。例如：Q1,Q2,Q3三个队列，当且仅当在Q1中没有进程等待时才去调度Q2，同理，只有Q1,Q2都为空时才会去调度Q3。

3、对于同一个队列中的各个进程，按照FCFS分配时间片调度。比如Q1队列的时间片为N，那么Q1中的作业在经历了N个时间片后若还没有完成，则进入Q2队列等待，若Q2的时间片用完后作业还不能完成，一直进入下一级队列，直至完成。

4、在最后一个队列QN中的各个进程，按照时间片轮转分配时间片调度。

5、在低优先级的队列中的进程在运行时，又有新到达的作业，此时须立即把正在运行的进程放回当前队列的队尾，然后把处理机分给高优先级进程。换而言之，任何时刻，只有当第1~i-1队列全部为空时，才会去执行第i队列的进程（抢占式）。特别说明，当再度运行到当前队列的该进程时，仅分配上次还未完成的时间片，不再分配该队列对应的完整时间片。

前两天做 *** 作系统作业的时候学习了一下几种进程调度算法，在思考和讨论后，有了一些自己的想法，现在就写出来，跟大家讨论下。，或者说只有有限的CPU资源，当系统中有多个进程处于就绪状态，要竞争CPU资源时， *** 作系统就要负责完成如何分配资源的任务。在 *** 作系统中，由调度程序来完成这一选择分配的工作，调度程序所使用的算法即是调度算法。调度算法需要考虑的指标主要有尽量保证CPU资源分配的公平性；按照一定策略强制执行算法调度；平衡整个计算机系统，尽量保持各个部分都处于忙碌状态。而根据系统各自不同的特点和要求，调度算法又有一些侧重点和目标不同，因此，算法按照系统差异主要分为三大类：批处理系统中的调度算法，代表调度算法有：先来先服务、最短作业优先、最短剩余时间优先。交互式系统中的调度算法，代表调度算法有：轮转调度、优先级调度、多级队列、最短进程优先、保证调度、**调度、公平分享调度。实时系统中的调度算法，代表调度算法有：速率单调调度、最早最终时限优先调度。下面就上述提到的调度算法中挑出几个进行重点分析：保证调度保证调度是指利用算法向用户做出明确的性能保证，然后尽力按照此保证实现CPU的资源分配。利用这种算法，就是定一个进程占用CPU的时间的标准，然后按照这个标准去比较实际占用CPU的时间，调度进程每次使离此标准最远的进程得到资源，不断满足离所保证的标准最远的进程，从而平衡资源分配满足这个标准的要求。保证调度算法的优点是：能很好的保证进程公平的CPU份额，当系统的特点是：进程的优先级没有太大悬殊，所制定的保证标准差异不大，各个进程对CPU的要求较为接近时，比如说系统要求n个进程中的每个进程都只占用1/n的CPU资源，利用保证调度可以很容易的实现稳定的CPU分配要求。但缺点是，这种情况太过理想，当系统的各个进程对CPU要求的紧急程度不同，所制定的保证较为复杂的时候，这个算法实现起来比较困难。**调度**调度这种算法的大意是指向进程提供各种系统资源如CPU资源的**，当系统需要做出调度决策时，随机抽出一张**，由此**的拥有者获得资源。在**调度系统中，如果有一个新的进程出现并得到一些**，那么在下一次的抽奖中，该进程会有同它持有**数量成正比例的机会赢得奖励。进程持有的**数量越多，则被抽中的可能性就越大。调度程序可以通过控制进程的**持有数量来进行调度。**调度有很多优点：首先，它很灵活，系统增加分给某个进程的**数量，就会大大增加它占用资源的可能性，可以说，**调度的反应是迅速的，而快速响应需求正是交互式系统的一个重要要求。其次，**调度算法中，进程可以交换**，这个特点可以更好的保证系统的平衡性，使其各个部分都尽可能的处于忙碌状态。而且利用**调度还可以解决许多别的算法很难解决的问题，例如可以根据特定的需要大致成比例的划分CPU的使用。速率单调调度速率单调调度算法是一种可适用于可抢占的周期性进程的经典静态实时调度算法。当实时系统中的进程满足：每个周期性进程必须在其周期内完成，且进程之间没有相互依赖的关系，每个进程在一次突发中需要相同的CPU时间量，非周期的进程都没有最终时限四个条件时，并且为了建模方便，我们假设进程抢占即刻发生没有系统开销，可以考虑利用速率单调算法。速率单调调度算法是将进程的速率（按照进程周期所算出的每秒响应的次数）赋为优先级，则保证了优先级与进程速率成线性关系，这即是我们所说的速率单调。调度程序每次运行优先级最高的，只要优先级较高的程序需要运行，则立即抢占优先级低的进程，而优先级较低的进程必须等所有优先级高于它的进程结束后才能运行。速率单调调度算法可以保证系统中最关键的任务总是得到调度，但是缺点是其作为一种静态算法，灵活性不够好，当进程数变多，系统调度变得复杂时，可能不能较好的保证进程在周期内运行。最早最终时限优先调度最早最终时限优先调度算法是一个动态算法，不要求进程是周期性的，只要一个进程需要CPU时间，它就宣布它的到来时间和最终时限。调度程序维持一个可运行的进程列表，按最终时限排序，每次调度一个最终时限最早的进程得到CPU。当新进程就绪时，系统检查其最终时限是否在当前运行的进程结束之前，如果是，则抢占当前进程。由于是动态算法，最早最终优先调度的优点就是灵活，当进程数不超过负载时，资源分配更优，但也同样由于它的动态属性，进程的优先级都是在不断变化中的，所以也没有哪个进程是一定可以保证满足调度的，当进程数超过负载时，资源分配合理度会急速下降，所以不太稳定。

Quartz是一款由java写成的作业调度框架，在大量javase/javaee应用中被用来做定时任务，它功能强大而又不失使用简单性。

Quartz的原理不是很复杂，只要搞明白几个概念，然后知道如何去启动和关闭一个调度程序即可。

1、Job

表示一个工作，要执行的具体内容。此接口中只有一个方法

void execute(JobExecutionContext context)

线程运行Job时会把JobDataMap封装到JobExecutionContext里作为execute方法的参数，jobdetail是对job的封装，里面有Job的class，对应的数据， 名称，分组等

2、JobDetail

JobDetail表示一个具体的可执行的调度程序，Job是这个可执行程调度程序所要执行的内容，另外JobDetail还包含了这个任务调度的方案和策略。

3、Trigger代表一个调度参数的配置，job下次什么时候执行存放在trigger中。

4、Scheduler代表一个调度容器，一个调度容器中可以注册多个JobDetail和Trigger。当Trigger与JobDetail组合，就可以被Scheduler容器调度了。

5、QuartzSchedulerResources相当于调度的资源存放器，包含了JobStore, ThreadPool等资源，调度都是通过QuartzSchedulerResources获取相关属性的。

6、jobStore是任务和触发器存储地方，它里面提供大量类似于增删改的 *** 作任务方法。

5、QuartzSchedulerThread是一个调度线程，ThreadPool是一个执行线程池，下图是运行后的线程栈：

Quartz是通过对用户暴露出Scheduler来进行任务的 *** 作，它可以把任务JobDetail和触发器Trigger加入任务池中，可以把任务删除，也可以把任务停止，scheduler把这些任务和触发器放到一个JobStore中，这里jobStore有内存形式的也有持久化形式的，当然也可以自定义扩展成独立的服务。

它内部会通过一个调度线程QuartzSchedulerThread不断到JobStore中找出下次需要执行的任务，并把这些任务封装放到一个线程池ThreadPool中运行，它的组件结构如下图：

各类的调用关系如下图：

下面看看quartz的简单实现：

首先是一个调度管理类：

接下来实现job接口：

测试主函数如下：

运行结果如下：

进程调度的方式有非剥夺方式和剥夺方式。

非剥夺方式：

分派程序一旦把处理机分配给某进程后便让它一直运行下去，直到进程完成或发生某事件而阻塞时，才把处理机分配给另一个进程。

剥夺方式：

当一个进程正在运行时，系统可以基于某种原则，剥夺已分配给它的处理机，将之分配给其它进程。剥夺原则有：优先权原则、短进程优先原则、时间片原则。

进程调度算法：

1、先进先出算法（FIFO）：

算法总是把处理机分配给最先进入就绪队列的进程，一个进程一旦分得处理机，便一直执行下去，直到该进程完成或阻塞时，才释放处理机。

举例：有三个进程P1、P2和P3先后进入就绪队列，它们的执行期分别是21、6和3个单位时间，对于P1、P2、P3的周转时间为21、27、30，平均周转时间为26。可见，FIFO算法服务质量不佳，容易引起作业用户不满，常作为一种辅助调度算法。

2、最短CPU运行期优先调度算法(SCBF--Shortest CPU Burst First)：

该算法从就绪队列中选出下一个“CPU执行期最短”的进程，为之分配处理机。

举例：在就绪队列中有四个进程P1、P2、P3和P4，它们的下一个执行进程调度期分别是16、12、4和3个单位时间，P1、P2、P3和P4的周转时间分别为35、19、7、3，平均周转时间为16。该算法虽可获得较好的调度性能，但难以准确地知道下一个CPU执行期，而只能根据每一个进程的执行历史来预测。

3、时间片轮转法：

前几种算法主要用于批处理系统中，不能作为分时系统中的主调度算法，在分时系统中，都采用时间片轮转法。简单轮转法：系统将所有就绪进程按FIFO规则排队，按一定的时间间隔把处理机分配给队列中的进程。这样，就绪队列中所有进程均可获得一个时间片的处理机而运行。

4、多级反馈队列：

多级队列方法：将系统中所有进程分成若干类，每类为一级。　多级反馈队列方式是在系统中设置多个就绪队列，并赋予各队列以不同的优先权。

时间触发的多任务调度原理是基于时间片的轮转调度算法，即每个任务都有一个时间片，每个时间片都会被分配给一个任务，当时间片用完时，系统会将其分配给下一个任务，以此类推，直到所有任务都完成。

Goroutine调度是一个很复杂的机制，下面尝试用简单的语言描述一下Goroutine调度机制，想要对其有更深入的了解可以去研读一下源码。

首先介绍一下GMP什么意思：

G ----------- goroutine: 即Go协程，每个go关键字都会创建一个协程。

M ---------- thread内核级线程，所有的G都要放在M上才能运行。

P ----------- processor处理器，调度G到M上，其维护了一个队列，存储了所有需要它来调度的G。

Goroutine 调度器P和 OS 调度器是通过 M 结合起来的，每个 M 都代表了 1 个内核线程，OS 调度器负责把内核线程分配到 CPU 的核上执行

模型图：

避免频繁的创建、销毁线程，而是对线程的复用。

1）work stealing机制

  当本线程无可运行的G时，尝试从其他线程绑定的P偷取G，而不是销毁线程。

2）hand off机制

  当本线程M0因为G0进行系统调用阻塞时，线程释放绑定的P，把P转移给其他空闲的线程执行。进而某个空闲的M1获取P，继续执行P队列中剩下的G。而M0由于陷入系统调用而进被阻塞，M1接替M0的工作，只要P不空闲，就可以保证充分利用CPU。M1的来源有可能是M的缓存池，也可能是新建的。当G0系统调用结束后，根据M0是否能获取到P，将会将G0做不同的处理：

如果有空闲的P，则获取一个P，继续执行G0。

如果没有空闲的P，则将G0放入全局队列，等待被其他的P调度。然后M0将进入缓存池睡眠。

如下图

GOMAXPROCS设置P的数量，最多有GOMAXPROCS个线程分布在多个CPU上同时运行

在Go中一个goroutine最多占用CPU 10ms，防止其他goroutine被饿死。

具体可以去看另一篇文章

Golang详解go语言调度机制 抢占式调度

当创建一个新的G之后优先加入本地队列，如果本地队列满了，会将本地队列的G移动到全局队列里面，当M执行work stealing从其他P偷不到G时，它可以从全局G队列获取G。

协程经历过程

我们创建一个协程 go func()经历过程如下图：

说明：

这里有两个存储G的队列，一个是局部调度器P的本地队列、一个是全局G队列。新创建的G会先保存在P的本地队列中，如果P的本地队列已经满了就会保存在全局的队列中；处理器本地队列是一个使用数组构成的环形链表，它最多可以存储 256 个待执行任务。

G只能运行在M中，一个M必须持有一个P，M与P是1：1的关系。M会从P的本地队列d出一个可执行状态的G来执行，如果P的本地队列为空，就会想其他的MP组合偷取一个可执行的G来执行；

一个M调度G执行的过程是一个循环机制；会一直从本地队列或全局队列中获取G

上面说到P的个数默认等于CPU核数，每个M必须持有一个P才可以执行G，一般情况下M的个数会略大于P的个数，这多出来的M将会在G产生系统调用时发挥作用。类似线程池，Go也提供一个M的池子，需要时从池子中获取，用完放回池子，不够用时就再创建一个。

work-stealing调度算法：当M执行完了当前P的本地队列队列里的所有G后，P也不会就这么在那躺尸啥都不干，它会先尝试从全局队列队列寻找G来执行，如果全局队列为空，它会随机挑选另外一个P，从它的队列里中拿走一半的G到自己的队列中执行。

如果一切正常，调度器会以上述的那种方式顺畅地运行，但这个世界没这么美好，总有意外发生，以下分析goroutine在两种例外情况下的行为。

Go runtime会在下面的goroutine被阻塞的情况下运行另外一个goroutine：

用户态阻塞/唤醒

当goroutine因为channel *** 作或者network I/O而阻塞时（实际上golang已经用netpoller实现了goroutine网络I/O阻塞不会导致M被阻塞，仅阻塞G，这里仅仅是举个栗子），对应的G会被放置到某个wait队列(如channel的waitq)，该G的状态由_Gruning变为_Gwaitting，而M会跳过该G尝试获取并执行下一个G，如果此时没有可运行的G供M运行，那么M将解绑P，并进入sleep状态；当阻塞的G被另一端的G2唤醒时（比如channel的可读/写通知），G被标记为，尝试加入G2所在P的runnext（runnext是线程下一个需要执行的 Goroutine。）， 然后再是P的本地队列和全局队列。

系统调用阻塞

当M执行某一个G时候如果发生了阻塞 *** 作，M会阻塞，如果当前有一些G在执行，调度器会把这个线程M从P中摘除，然后再创建一个新的 *** 作系统的线程(如果有空闲的线程可用就复用空闲线程)来服务于这个P。当M系统调用结束时候，这个G会尝试获取一个空闲的P执行，并放入到这个P的本地队列。如果获取不到P，那么这个线程M变成休眠状态， 加入到空闲线程中，然后这个G会被放入全局队列中。

队列轮转

可见每个P维护着一个包含G的队列，不考虑G进入系统调用或IO *** 作的情况下，P周期性的将G调度到M中执行，执行一小段时间，将上下文保存下来，然后将G放到队列尾部，然后从队列中重新取出一个G进行调度。

除了每个P维护的G队列以外，还有一个全局的队列，每个P会周期性地查看全局队列中是否有G待运行并将其调度到M中执行，全局队列中G的来源，主要有从系统调用中恢复的G。之所以P会周期性地查看全局队列，也是为了防止全局队列中的G被饿死。

除了每个P维护的G队列以外，还有一个全局的队列，每个P会周期性地查看全局队列中是否有G待运行并将其调度到M中执行，全局队列中G的来源，主要有从系统调用中恢复的G。之所以P会周期性地查看全局队列，也是为了防止全局队列中的G被饿死。

M0

M0是启动程序后的编号为0的主线程，这个M对应的实例会在全局变量rutimem0中，不需要在heap上分配，M0负责执行初始化 *** 作和启动第一个G，在之后M0就和其他的M一样了

G0

G0是每次启动一个M都会第一个创建的goroutine，G0仅用于负责调度G，G0不指向任何可执行的函数，每个M都会有一个自己的G0，在调度或系统调用时会使用G0的栈空间，全局变量的G0是M0的G0

一个G由于调度被中断，此后如何恢复？

中断的时候将寄存器里的栈信息，保存到自己的G对象里面。当再次轮到自己执行时，将自己保存的栈信息复制到寄存器里面，这样就接着上次之后运行了。

我这里只是根据自己的理解进行了简单的介绍，想要详细了解有关GMP的底层原理可以去看Go调度器 G-P-M 模型的设计者的文档或直接看源码

参考： (>

以上就是关于进程调度算法全部的内容，包括:进程调度算法、几种进程调度算法分析、quartz作业调度的应用和原理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！