1 · 读书笔记：操作系统导论

Operating Systems: Three Easy Pieces

https://book.douban.com/subject/33463930/

• 是什么（What）— 一本从机制到策略讲解操作系统核心问题的入门书，主线是三个主题：虚拟化（CPU/内存）、并发（线程/同步）、持久化（文件系统/磁盘）
• 为什么（Why）— 操作系统把硬件细节藏在 API 背后，但性能、隔离性、崩溃恢复、死锁、调度延迟这些真实问题都来自 OS 的设计权衡；不懂 OS，很多程序行为只能“碰运气”
• 怎么做（How）— 围绕“抽象 + 机制 + 策略”学习：先理解进程、地址空间、文件这些抽象，再理解调度、分页、锁、日志等机制，最后比较不同策略的代价和适用边界

1.1 · 核心观点：

操作系统的本质不是“提供一堆系统调用”，而是以一组精心设计的抽象和机制，把一台复杂、有限、会出故障的物理机器，变成一个看起来更简单、更安全、更可共享的计算环境。 它一边做资源虚拟化，一边做隔离与协调，还要在性能、公平性、可靠性之间持续权衡。

• OS 首先是资源管理者：CPU、内存、磁盘、网络都必须被多个程序安全共享。
• OS 也是抽象层：进程让我们觉得自己独占 CPU，虚拟内存让每个进程像拥有连续且私有的地址空间，文件系统让持久化存储看起来像层级化命名空间。
• 学习操作系统不能只背概念，更要区分机制（mechanism）和策略（policy）。机制回答“能不能做到”，策略回答“该怎么选”。
• 很多系统设计问题都没有绝对最优解，只能在吞吐、延迟、公平、复杂度、可靠性之间做权衡。
• 操作系统最值得学的，不只是知识点本身，而是它提供了一套分析复杂系统的通用框架：抽象、隔离、并发控制、失败恢复、性能评估。

1.2 · 启发点（关键洞察）：

1. 虚拟化是 OS 的第一性原理：单核 CPU 通过时分复用“假装”同时运行多个程序，内存通过地址转换“假装”每个进程都有独立空间，文件系统通过命名和权限“假装”数据天然有序且可长期保存。
2. 抽象从来不是免费的：进程切换有上下文切换成本，虚拟内存有页表与 TLB 开销，文件系统有缓存一致性和崩溃恢复问题。抽象简化了编程模型，但把复杂度移到了 OS 内部。
3. 机制与策略必须分开看：例如调度器的上下文切换是机制，而时间片长短、优先级、MLFQ 规则是策略。工程上常见的问题不是“没有机制”，而是策略不匹配工作负载。
4. 并发的难点不是“同时运行”，而是“正确协调”：线程让程序更高效地利用 CPU 和 I/O，但共享状态会引入竞态条件、死锁、饥饿等问题；同步原语的职责是约束交错执行。
5. 内存管理的核心不是分配，而是隔离、复用与局部性：分页解决了外部碎片和保护问题，但真正决定性能的往往是局部性、缺页率和替换策略，而不是抽象本身多优雅。
6. 持久化系统的难点在“故障时仍然正确”：磁盘会慢、缓存会乱序、写入会部分完成，所以文件系统设计必须考虑日志、检查点、崩溃一致性，而不是只考虑正常路径。
7. 间接层是系统设计中的万能工具：页表、inode、文件描述符、虚拟地址、调度队列，本质上都是通过间接层换取灵活性、共享能力和演进空间。
8. 评估系统不能脱离工作负载：任何调度算法、缓存策略、置换策略，看起来“聪明”与否，都要放回具体 workload、指标和约束下讨论。
9. 操作系统训练的是“面向现实约束设计”的能力：硬件有限、程序会出错、请求会冲突、故障一定发生，系统设计必须从这些不完美条件出发。

1.3 · 行动：

1. 写一个最小 shell，亲手练习 fork/exec/wait，把“进程”从概念变成可操作模型。
2. 用一个小实验分别观察 CPU 密集型和 I/O 密集型任务在不同调度策略下的表现，建立对吞吐、响应时间、公平性的直觉。
3. 手动画出虚拟地址到物理地址的转换过程，把页表、TLB、缺页中断串成完整链路。
4. 遇到线程 bug 时，不只盯着业务代码，也主动检查共享状态、锁粒度、锁顺序和条件变量使用方式。
5. 以后设计缓存、任务队列、限流或重试机制时，刻意套用 OS 的视角思考：资源是谁的、如何隔离、谁来仲裁、失败后怎么恢复。
6. 找机会做一次文件系统或数据库 WAL 的源码阅读，把“崩溃一致性”从书本概念映射到真实工程实现。

1.4 · 金句：

1. 操作系统最重要的工作，是把复杂硬件变成可管理、可共享、可依赖的抽象。
2. Virtualization lets one physical resource look like many.
3. Concurrency is not just about speed; it is about coordination.
4. Persistence is easy in the normal case, hard in the crash case.
5. Separate mechanism from policy.