批处理的做法是「攒一批作业、一口气跑完」，中间没人能插进来。 它的短板不是慢，是「不响应」——提交完只能干等整批结束。
1.1 讲完了网络能干什么，1.2 开始讲它是怎么一步步变成现在这样的。 批处理是这七个阶段里第一个，也是最反直觉的一个——它连「交互」这个概念都没有。
一、那个年代的机器长什么样
1950 年代的计算机没有终端、没有键盘屏幕，输入靠打孔的卡片或纸带，输出靠打印机。 所以「一个人守着机器敲命令」这件事在当时根本不成立——机器太贵，贵到必须一刻不停地跑。
| 环节 | 做法 | 耗时占比 |
|---|---|---|
| 准备 | 程序员在卡片上打孔 | 人的时间，不算机器时间 |
| 装入 | 整叠卡片读进磁带 | 几分钟 |
| 运行 | 连续跑完所有作业 | 机器时间的主体 |
| 输出 | 结果打到打印纸 | 几分钟 |
第一行那个「不算机器时间」是关键：批处理的设计目标就是「让机器别闲着」， 人的等待被彻底排除在优化目标之外。 这就是为什么它后来必然被淘汰——机器越来越便宜、人越来越贵，优化目标反过来了。
二、周转时间怎么算
衡量批处理好坏的核心指标叫「周转时间」：从提交到出结果，一共等了多久。
| 指标 | 定义 | 批处理下的表现 |
|---|---|---|
| 周转时间 | 完成时刻 − 提交时刻 | 等于排队时间加运行时间 |
| 平均周转 | 所有作业周转的平均 | 取决于作业顺序 |
| 响应时间 | 提交到第一次出反馈 | 等于周转时间 |
第三行那个「等于」最能说明问题：批处理里根本没有「响应」这个概念， 第一次反馈就是最后结果。 所以作业顺序影响巨大：短的排后面，平均周转时间会被拉得很长。 这就是后来「短作业优先」调度算法的由来。
三、为什么这条路走不下去
三个矛盾同时压过来：
| 矛盾 | 表现 | 后果 |
|---|---|---|
| 机器贵 vs 人少 | 一人一机不划算 | 只能攒批 |
| 调试难 | 一个错要等整批跑完 | 改一行等一天 |
| 无法交互 | 没有实时反馈 | 不适配新用途 |
第二行那个「改一行等一天」是当年的真实痛点：卡片打错一个孔，整叠要重打、重排、重跑。 所以一旦硬件便宜到能「一人一机」， 批处理立刻被分时系统取代——不是因为批处理效率低，是因为它不把人当回事。 这个教训在后面反复出现：技术路线的胜负，往往取决于它把谁的成本算进去了。
四、动手 Demo：批处理为什么会被淘汰
拿 5 个作业算一笔账：作业按提交顺序一个接一个跑，看每个作业的周转时间， 以及「最短的那个等了多久」。 这个 Demo 里最短的作业 D 只算 40 毫秒，却排在第四个。
jobs = [('A', 120), ('B', 80), ('C', 200), ('D', 40), ('E', 60)]
clock = 0
total = 0
for name, dur in jobs:
start = clock
clock += dur
total += clock # 周转时间 = 完成时刻（提交时刻都是 0）
print('%-2s 运行%4d 开始%4d 完成%4d 周转%4d'
% (name, dur, start, clock, clock))
print('平均周转 %.1f' % (total / len(jobs)))
实跑输出：
--------------------------------------------------------------------
批处理为什么会被淘汰
--------------------------------------------------------------------
**批处理的做法是「攒一批作业、一口气跑完」**，**中间没人能插进来。**下面拿 5 个作业算一笔账。
作业 运行时长 开始时刻 完成时刻 周转时间
---------------------------------------------------------
A 120 0 120 120
B 80 120 200 200
C 200 200 400 400
D 40 400 440 440
E 60 440 500 500
**平均周转时间 332.0 毫秒**，
**而且作业 D 只算 40 毫秒，却等了 400 毫秒才开始。**
**批处理的问题不是慢，是「不响应」**：**提交完就得等整批跑完，人拿不到中途的反馈。**
**所以下一步必然走向分时——把 CPU 切成小片轮流给，让每个人都能很快看到反应。**
平均周转 332 毫秒这个数，换个顺序会完全不同。 如果把 D 提到第一个： 5 个作业的完成时刻变成 40／160／240／440／500，平均 276 毫秒——少了 56 毫秒，作业一个没变。 所以「调度算法」不是学术游戏：同样的工作量，顺序不同，用户体验差一截。 这也是操作系统课里「短作业优先」永远排在前面的原因。
30 秒实验
- 把
jobs按运行时长从小到大排序再跑一次，看平均周转时间变成多少。 - 把作业数加到 20 个、时长随机，比较「原顺序」与「短作业优先」的平均周转差多少倍。
- 给每个作业加一个「提交时刻」（错开到达），再看周转时间的定义要不要改。
常见误区
- 以为批处理效率低。 它的机器利用率其实很高，因为机器一刻不停。它低的是「人的效率」。
- 以为批处理就是「脚本批量执行」。 两回事：批处理是没有人机交互的作业流， 今天的 shell 脚本随时可以看输出、随时可以打断。
- 以为周转时间越短越好就一定对。 还要看公平性，短作业全排前面， 长作业可能永远轮不到（饥饿）。
自测三问（点开对答案）
1. 批处理最大的问题是什么？ —— **不是慢，是不响应**。提交后拿不到任何中途反馈，出错也要等整批跑完才知道。 **第一次反馈就是最后结果。** 2. 同样的 5 个作业，换个顺序平均周转时间会不会变？ —— **会，而且变得不少**。本例按原顺序是 332 毫秒，把最短的 D 提前到 276 毫秒。 **总工作量一样，体验不同。** 3. 为什么说「技术的胜负取决于它把谁的成本算进去了」？ —— 批处理优化的是**机器时间**，把人的等待排除在外； 等硬件便宜了、人变贵了，**优化目标一换，批处理立刻失势**。下一节就是取代它的那一个：把 CPU 切成小片轮流给，让每个人都能很快看到反应。
- ☐ （本节完，下一节 1.2.2 分时系统）