📚 课程目录第2章操作系统启动流程分析

操作系统启动流程分析：从按下电源到系统就绪

说实话，很多人觉得启动就是「按电源 → 进桌面」，但真正的启动优化工程师眼里，这段过程其实藏着好几个性能瓶颈点。我个人习惯把启动流程拆成四个阶段：BIOS/UEFI 初始化、Bootloader 加载、内核解压与初始化、最后是 init 进程拉起用户空间。今天我们就一层一层剥开它。

BIOS 与 UEFI：老规矩与新范式

早期机器都用 BIOS，它负责上电自检（POST）、枚举硬件、然后按启动顺序读取磁盘第一个扇区（MBR）。但 BIOS 有个硬伤——它只能在实模式下工作，寻址空间只有 1MB。现在的 UEFI 就灵活多了，直接运行在保护模式甚至长模式下，还能支持分区表和大磁盘。

💡 我的一点经验
做嵌入式启动优化时，我曾用 UEFI 的快速启动（Fast Boot）功能跳过内存全检，直接把启动时间从 8 秒压到了 3.2 秒。不过要注意，跳过内存检测后如果硬件不稳定，可能会出现随机崩溃——这坑我踩过，后来加了条件判断：第一次启动或拆机后强制全检。

两者最核心的区别在于引导方式：BIOS 直接加载 MBR 中的 Bootloader，而 UEFI 会在 ESP（EFI 系统分区）中寻找 bootx64.efi 文件来启动。如果你想做启动调优，建议关注以下几点：

UEFI 启动顺序：禁用不必要的启动项，减少固件遍历开销
CSM 兼容性：纯 UEFI 模式比 CSM（兼容支持模块）快 200~500ms
Secure Boot：开启后会增加签名验证，但安全性收益远大于性能损失

Bootloader：内核搬运工

Bootloader 负责把内核从磁盘加载到内存，并传递启动参数。常见的 Bootloader 有 GRUB（x86）、U-Boot（ARM/嵌入式）、syslinux 等。我见过最夸张的优化案例是把 GRUB 的 timeout 从 5s 降到 0s，直接节省 5 秒启动时间——当然，你得确保默认项一直是正确的内核。

这里有个关键操作：内核压缩算法。GRUB 支持直接加载压缩过的内核（vmlinuz），它会在加载时自动解压。但如果你改用 LZ4 压缩而不是默认的 gzip，解压速度能提升 2~3 倍。我曾经在某个 IoT 项目上试过，内核从 3.2MB 压缩后 1.1MB，解压时间从 210ms 降到了 65ms。

⚠️ 注意
修改内核压缩方式需要重新编译内核，并且确保 Bootloader 支持新的压缩算法。GRUB 2.04+ 支持 LZ4，但旧版本只认 gzip。升级 Bootloader 前务必在测试环境验证。

内核加载：解压、初始化、挂载根文件系统

内核被 Bootloader 加载后，会经历几个阶段：

解压自身——从压缩的 vmlinuz 展开成原始内核
中断初始化——设置 IDT、GDT，开启分页
设备驱动枚举——PCI/ACPI/设备树等硬件扫描
挂载根文件系统——从 initramfs 或直接挂载磁盘分区

这里面最耗时间的往往是设备驱动初始化。我记得有一次调优，发现系统在 ACPI 表解析上花了 1.8 秒。后来通过内核参数 acpi=off 确认是 ACPI 的问题，最终通过裁剪 DSDT 表里的无用设备，把时间降到了 0.4 秒。

🔥 内核调优常用参数


# 跳过不必要的检测（生产环境慎用）
nowatchdog nolapic_timer
# 禁用 ACPI（仅调试用）
acpi=off
# 减少 initramfs 等待时间
rootdelay=0
# 设置内核日志级别（减少 console 输出开销）
loglevel=3

init 进程：用户空间的第一声啼哭

内核加载完根文件系统后，会执行第一个用户空间进程——/sbin/init（通常是 systemd 或 SysV init）。这个进程是所有后续服务的父进程。systemd 之所以成为主流，就是因为它的并行启动能力。

我曾经在 X86 服务器上做过对比：SysV init 串行启动 40 个服务需要 22 秒，而 systemd 利用 socket 激活和并行依赖解析，同样的服务只需要 6.5 秒。不过 systemd 的启动时间容易受 service 文件的 After 和 Wants 影响，如果写错依赖关系，反而会阻塞启动。

常见 init 系统对比
特性	SysV init	systemd	OpenRC
启动方式	串行	并行 + socket 激活	并行（依赖 CGroup）
依赖管理	启动顺序脚本	单元依赖图	runlevel 依赖
典型启动时间（40 服务）	~22s	~6.5s	~10s
调优手段	移除无用服务	`systemd-analyze blame`	调整依赖顺序

启动调优时我推荐先用 systemd-analyze time 查看总耗时，再用 systemd-analyze blame 找出最慢的单元。有一次我发现 NetworkManager-wait-online.service 占了 8 秒，后来直接改为 After=network-online.target 并且把超时设为 0，一下子就顺畅了。

✨ 避坑指南
我曾经遇到一个 case：修改了 systemd 服务依赖后，启动反而变慢。原因是 After=mysql.service 写成了 Requires=mysql.service，导致系统等 MySQL 完全就绪才启动后续服务。实际业务只需在连接前确保 MySQL 已启动即可，用 After 加 Wants 更合理。

最后总结一句：启动流程上的每个节点都值得你去抠一抠毫秒级的时间。下一层是具体的测量工具和分析方法，把这些基础吃透，后面调优才有方向。嗯，今天就先到这里。