0 前言

接上一篇文章：进程调度（2a）：SJF（短任务优先） 算法 原理与实践

1 前提铺垫

与上一篇同。

2 STCF 原理

STCF（Shortest Time-to-Completion First）最短完成时间优先。

2.1 算法

还记得上一个算法SJF吗？它是非抢占式的，只能傻傻地等着长任务A完成，这显然是“懦弱”的，并且降低了系统的效率，因此，让我们给它添加一个抢占功能吧！

抢占什么呢？当然是A了，还是用上次的例子

• A：100
• B：10
• C：20

A在0时刻到达并执行，B和C在10时刻到达。之前B和C只能等着A结束执行再按照B、C的顺序执行，现在，我们有抢占功能了！

在时刻10的时候，Scheduler（调度器）发现B和C的执行时间比A短，那么好，A你就不要再执行了，让B先来吧！ 这里，我们也使用到了上下文切换机制，先保存了A执行的状态，等B、C执行完，再让A继续执行。

一个问题：究竟是识别A剩余执行时间，还是全部执行时间，又或者什么呢？A、B和C的执行时间，系统又怎样得知？这些我们以后再谈，并且这设计到了具体实现的层次，现在，我们的假设还是运行时间是已知的，并且是在抽象层次在谈论。

这样，看起来就比之前的SJF棒多了！起码它学会了“抢车位”。

现在，Average Turnaround Time = （10 + 30 + 130）/ 3 = 56.67，要知道，之前可是110。

不过，这个算法也会有一些问题，我们下面说一下。

2.2 缺点：长任务“饥饿”

试想一下，对于一个长任务，如果有远远不断地短任务进入，那么这个长任务可能永远不会被执行了……（它也太惨了……）

不仅如此，对于一个交互型程序来说，与用户交互的响应时间（我们下一讲说这个指标，简单来说，就是用户发送命令，到看见屏幕产生变化的时间，这应该很快才对）就会非常长，想象一下，你敲击键盘的字母A后，等待10s才看见屏幕上显示了A……这简直让人发疯！

说明：在原书中没有给出STCF算法的模拟，因此暂时没有实践内容，不过因为该算法与SJF的区别就在于抢占，因此比较容易理解。

2.3 关注点：顺序执行的打破

我们之前看到的进程，都是从一开始执行，就一直执行到完成才停止，这个过程并不需要上下文切换机制（前面的篇章好像写错了……），而这一次，我们看到了任务A被分成了两段来执行，这时候就使用到了上下文切换机制了，被打断的A，必须要保存现场，然后下一次被执行的时候，恢复现场继续执行。

这也是我们第一次见到，多个任务不是顺序执行的，而是切换执行的，下一篇轮转算法，你将更清晰地体会到这一点！

3 核心思想

STCF与SJF本质是一样的，区别就是，前者是抢占式，后者是非抢占式的。

核心思想就是，让运行时间短的任务先执行。

这样做的缺点也分析过，长任务可能一直得不到执行，后续我们会解决这个问题的。

4 预告：进程调度（3）：RR（轮转） 算法 原理与实践

我们接下来会使用轮转算法解决交互式程序的响应时间问题。这样能让用户获得很好的体验。