01
经典五级 CPU 流水线与数据冒险转发机制
流水线不缩短单条指令的执行时间，而是成倍放大指令吞吐率。RAW（写后读）数据依赖通过硬件旁路“飞线”提前截获计算结果，消除流水线停顿。
01 · 流水线吞吐核心
指令时延未缩短，吞吐量由最慢阶段决定：$T_{\text{clk}} \ge \max(t_i) + t_{\text{latch}}$。五级平衡切片后理想 CPI 趋近于 1.0。
02 · 冒险类型与对策
RAW（写后读）最频繁。若无转发需停顿 2 个时钟周期；引入旁路直接从 ALU 输出飞线连接下一个周期 ALU 输入，实现 0 停顿计算。
03 · 考研与工程陷阱
Load-Use 冒险无法完全消除停顿！因为 LW 指令的数据直到 MEM 阶段末才就绪，后继指令若在 EX 立即使用，必须强制插入 1 个 Bubble 气泡。
02
存储金字塔与 Cache 组相联映射与替换机制
现代处理器 95% 以上的时钟周期耗费在等内存数据上。将主存地址拆解为 Tag/Index/Offset，利用组相联映射并行比对，用 64 字节缓存行换取空间与时间局部性。
01 · 组相联折中优势
直接映射冲突率高，全相联比较器硬件开销过大。8路/4路组相联是现代 CPU 的黄金平衡点，失效率逼近全相联，同时比较电路控制在极低延时。
02 · 空间与时间局部性
一次 Cache Miss 会将相邻 64 字节整行加载（空间局部性）；刚访问的数据被保存在 L1 高优先级槽位（时间局部性），支撑二维数组行优先遍历极快。
03 · 工程实战：伪共享 (False Sharing)
多核高并发场景下，若两个线程频繁修改位于同一 64B Cache Line 内的不同独立变量，会导致该行在各核 L1/L2 间不断失效颠簸，性能暴跌 10 倍以上！解决方案：内存对齐填充（Padding）。
03
虚拟内存穿透：多级页表、TLB 寻址与缺页异常
虚拟内存为每个进程制造拥有独立连续内存的错觉。通过 CR3 寄存器多级级联索引、TLB 高速旁路硬件缓冲以及内核缺页置换，实现空间隔离与物理内存按需分配。
01 · 多级页表省内存实质
32位单级页表需强制常驻 $4\text{MB}$ 连续物理内存；多级页表只为**实际使用的离散虚拟地址**建立次级页表，未分配的顶级 PDE 全填 0，极大节约页表自身内存。
02 · TLB 快表与上下文切换
TLB 命中只需 1 次访存（物理内存）；TLB 未命中需经过 2 次页表访存 + 1 次真实物理访存（共 3 次访存）。进程切换时若无 ASID 标签必须全量清空 TLB。
03 · 考研与实战：缺页中断特殊性
缺页中断属于**故障（Fault）**类异常，发生在指令执行期间，异常处理返回后**重新执行原指令**（而不是下一条指令）。高并发下频繁缺页会导致系统**颠簸/抖动 (Thrashing)**，CPU 都在忙于换页。
04
并发与同步互斥：PV 信号量机制与银行家死锁算法
并发执行带来不确定性。P/V 原语通过原子递减与阻塞队列守卫临界区；银行家算法在每次分配前推演安全序列，摧毁死锁循环等待链。
01 · PV 原语顺序绝不可逆
在生产者中，必须先 P(empty) 申请资源，再 P(mutex) 进临界区！若反过来写：当缓冲区满时生产者先锁住 mutex 再阻塞在 empty 上，消费者将永远无法获取 mutex 消费，直接死锁！
02 · 银行家算法安全状态
安全状态（存在至少一条安全序列）一定不会发生死锁；不安全状态未必立即发生死锁，但只要后续进程继续索求资源，死锁便不可避免。
03 · 工程实战：死锁四条件与破环
死锁 4 条件：互斥、占有且等待、不剥夺、循环等待。工程上最简单鲁棒的破除方案是**严格按照固定全局次序获取锁（Lock Ordering）**，打破循环等待环路（如 Java/Go 数据库分布式事务）。
05
CPU 调度核心：多级反馈队列 (MLFQ) 与动态抢占
操作系统无法提前预知进程需要运行多久。MLFQ 假设所有新进程都是交互型短任务，根据时间片消耗历史动态降级，并以抢占式高优先级响应突发 I/O。
01 · 短作业与交互响应优先
不需要提前知道任务总时长，将新任务先扔进顶层小时间片队列；如果是交互型 UI 点击，几毫秒内执行完毕，响应时间（Response Time）达到最佳。
02 · CPU 密集型任务自我降级
长期计算型任务不断耗尽时间片，自动流转到深层大时间片队列，减少上下文切换损耗，提升 CPU 计算有效产出率。
03 · 考研与工程：饥饿（Starvation）防范
若系统中不断有短任务涌入，底层的长作业会陷入**永久饥饿**。标准解决方案：设置周期性定时器（如每 100ms），执行 **Priority Boost 将所有任务无条件重置回 Q0**。
06
TCP 状态机全景时序：三次握手与四次挥手 2MSL
在不可靠的 IP 网络上建立全双工确定性流传输。三次握手协商初始序号与窗口，四次挥手支撑半关闭（Half-Close），2MSL 定时器彻底扫除网络残存游魂报文。
01 · 为什么三次握手？
防止已失效的连接请求报文段突然又传送到了服务端造成资源挂死浪费；且双方必须互相同步各自的随机初始序号（ISN）。
02 · 为什么挥手要四次？
TCP 是全双工的。收到客户端 FIN 仅代表客户端不再发送数据，服务端进入 CLOSE_WAIT 仍可继续向客户端发送未完成数据（半关闭状态），直到服务端也发送 FIN。
03 · 考研与实战：TIME_WAIT 2MSL
① 保证最后一个 ACK 能到达服务端（若丢弃可响应重传的 FIN）；② 让本连接内产生的所有报文在网络中消亡，防止老报文串入新连接。生产高并发下短连接滥用会导致本地可用端口耗尽，需开启连接池或复用参数。
07
流量控制与拥塞避免：滑动窗口与 Reno 水流波形
发送方发送速率由两把锁决定：接收方缓冲区（rwnd）与网络管道容量（cwnd）。慢启动指数冲锋、拥塞避免加法爬坡、快恢复乘法减半，共同构筑现代互联网自适应流控基石。
01 · 流量控制 vs 拥塞控制
流量控制（Flow Control）是点对点的，由接收方通过 rwnd 反馈处理能力；拥塞控制（Congestion Control）是全局性的，由网络路由器拥堵和丢包计算 cwnd 。
02 · AIMD 加法增大乘法减小
达到门限 ssthresh 后每个 RTT 仅增加 1 个 MSS（加法稳健探索）；一旦检测到 3 个重复 ACK，门限减半并将 cwnd 置为新门限（乘法退避），不重置为 1，保持管道饱满。
03 · 考研与实战：超时 vs 冗余 ACK
超时重传（RTO）意味着网络可能发生严重瘫痪，直接打回慢启动 cwnd = 1 ；而收到 3 个冗余 ACK 说明后续报文已到达，网络仍有流动性，执行快重传与快恢复。现代 Linux 默认采用 BBR/CUBIC 进一步利用带宽时延积（BDP）。
08
端到端数据包漫游：逐层封装、NAT 转换与路由跳跃
发送一个 HTTP 请求，报文在物理电缆中经历了什么？MAC 帧头每过一跳被彻底剥除重铸，IP 头指引全局终点并在网关发生 NAT 端口伪装，TTL 沿途衰减扑灭路由环路。
01 · MAC 地址 vs IP 地址
MAC 是局域网内换乘的“车票”，每跨越一次路由器都被彻底撕掉换新；IP 是从起点到终点的“邮政编码”，全程引导路由转发（除非经由 NAT 改写源地址）。
02 · ARP 寻址真实过程
跨网段发送数据时，Host A 绝不会向终点服务器发 ARP！而是用 ARP 广播查找“默认网关”的 MAC 地址，把数据帧第一跳送入路由器。
03 · 考研与实战：路由器的四大动作
路由器收到 IP 报文后：① 剥除旧 MAC 帧头并校验 FCS；② 查路由表进行最长前缀匹配（CIDR）确定下一跳；③ TTL 字段减 1（减为 0 则丢弃并向源发送 ICMP 超时报文）；④ 重新计算 IP 首部校验和并打上下一跳新 MAC。
09
平衡树动态自平衡：AVL 旋转拓扑与红黑树决策树
二叉搜索树若退化为链表，查找复杂度将从 $O(\log n)$ 恶化至 $O(n)$。AVL 以严格高度差为代价追求极致查询速度；红黑树以“红黑黑高平衡”换取插入时最多 2 次旋转的绝佳综合性能。
01 · AVL 树与红黑树对比
AVL 树追求绝对平衡（左右高度差 $\le 1$），查询深度极浅，但高频写入时旋转频繁；红黑树属于弱平衡（最长路径不超过最短路径的 2 倍），在频繁增删中表现更稳健。
02 · 红黑树五大公理
① 节点非红即黑；② 根节点必为黑；③ 叶子节点（NIL 哨兵）为黑；④ 不能有连续红节点；⑤ 从任一节点到其所有叶子的路径黑节点数相同（黑高平衡）。
03 · 考研与工程：生产级首选
工业界绝大多数内存关联容器（C++ std::map 、Java TreeMap 、Linux 进程调度器 CFS rbtree 、Nginx 定时器）**均采用红黑树而非 AVL**，正因为其插入最多只需 2 次旋转的极低动态开销。
10
存储引擎基石：B+ 树节点分裂与双向叶子链表扫描
磁盘 I/O 比内存慢 10 万倍。B+ 树非叶节点仅存索引键保持巨大扇出（高矮胖），全部数据下沉叶子节点并通过双向有序链表贯穿，让数据库范围检索无需反复回溯寻道。
01 · 为什么 MySQL 选 B+ 树而不是 B 树？
① 非叶子节点不存数据行，16KB 的一页可容纳多达 1000+ 个键值指针，树极矮（3层可存 2000 万行），磁盘寻道极少；② 全表扫描性能稳定；③ 双向叶子链表让范围查询（BETWEEN / > / <）无需树回溯。
02 · B+ 树阶数与高度计算
设阶数为 $m$、高度为 $h$，根节点至少有 2 个子节点，其余非叶节点至少有 $\lceil m/2
ceil$ 个子节点；所有叶子节点在同一物理层，保证查询时间稳定在 $O(\log_m N)$。
03 · 工程实战：B+ 树 vs LSM-Tree
B+ 树读性能极强，但高频写存在**随机写与写放大（Write Amplification）**；而现代日志型引擎（如 RocksDB、ClickHouse、HBase）采用 **LSM-Tree**：内存追加写（MemTable）+ 顺序刷盘（SSTable），用后台异步 Compaction 换取极致的写吞吐。