Richard Liu’s Blog http://richardliuda.top/ Under construction. Thu, 23 Apr 2026 20:42:04 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en-US All rights reserved 2026, Richard Liu <![CDATA[操作系统第三章讲义]]> http://richardliuda.top/article/34b69776-e204-8041-8892-d2c3c5afd1ed http://richardliuda.top/article/34b69776-e204-8041-8892-d2c3c5afd1ed Fri, 24 Apr 2026 00:00:00 GMT

3.1 处理机调度的层次和调度算法的目标

💡

什么是调度？

调度的本质：分配资源
  • 资源是什么？ 处理机（CPU）的使用时间。
  • 谁来分？ 操作系统。
  • 分配给谁？ 内存里排队等着的各个任务（进程/作业）。
因为 CPU 有限，但任务有很多。所以需要一套运行的规则，这就是调度。

3.1.1 处理机调度层次

因为计算机的架构所限，计算机硬件资源的速度极不匹配，且内存容量有限。所以单靠单一的调度策略很难顾全大局。
这时候就必须对每一层级进行分工调度，协调好“慢速的磁盘”、“金子做的内存”和“极速的CPU”。
  • 高级调度——作业调度
  • 中级调度——内存调度
  • 低级调度——进程调度

如果没有多级调度

  1. 没有高级调度会“撑死”： 内存撑爆，系统崩溃。
  1. 没有中级调度会“饿死”： 小任务等不到响应，长任务霸占资源。
  1. 没有低级调度会“急死”： 电脑变得极其不灵活，开个网页可能要把后台所有程序都关掉才行。

3.1.2 处理机调度算法的目标

💡
核心目标：尽量减少处理机的闲置。

1. 高资源利用率

——别让CPU偷懒。
  • 应使系统中的处理机和其它所有资源都尽可能地保持忙碌状态。
  • 计算处理机利用率：

2. 公平性

——别让老实人等死。
  • 调度算法需要使各进程都要获得合理的CPU时间。
  • 不能厚此薄彼，不能因为进程小就不给其分配资源。
  • 不能发生饥饿现象。
💡
饥饿现象
如果一个算法总是让优先级高的先跑，那么一个优先级低的进程可能等了 3 天还没跑上 1 秒钟，这就叫“饥饿”。
  • 公平是相对的
    • 同类等同： 如果都是普通的文档编辑程序，大家拿到的 CPU 时间应该差不多。
    • 异类区别： 视频播放器（实时性要求高）和后台杀毒软件（不急）相比，系统会优先照顾视频播放器，这虽然“不平等”，但在逻辑上是“公平”的。

3. 平衡性

——别让厨师闲着，也别让洗碗机闲着。
💡
进程的分类
  1. 计算型作业 (CPU-bound)： 狂算数字，CPU 很累，但不怎么用硬盘/网络。
  1. I/O 型作业 (I/O-bound)： 频繁读写硬盘、收发网络包，CPU 很闲，但外部设备很忙。
  • 调度算法要把这两种作业混合搭配，平衡CPU和IO设备的使用情况。
  • 理想状态： CPU、硬盘、网卡都在同时工作，系统资源利用率达到最高。

4. 策略强制执行

——规矩大过天。
就像医院急诊室，规定“抢救病人第一优先”。哪怕普通感冒患者已经等了 2 小时，只要来了一个心梗病人，医生必须立刻去抢救心梗病人。
  • 操作系统设定好的规则，调度算法必须无条件准确执行。
  • 即使可能会导致某些普通任务被推迟、延误，但为了系统的安全性、稳定性，必须严格执行预设策略。

3.1.3. 系统的目标

操作系统历史上有三种系统：
  • 批处理系统
  • 分时系统
  • 实时系统

批处理系统的目标

  • 批处理系统通常用于大型计算任务，它不强调人机交互，而是强调“干活的效率”。
1. 平均周转时间短
  • 周转时间——衡量系统快慢最基本的指标
    • 定义：从你把作业提交给系统开始，到系统帮你把活干完输出结果为止，这段总时间。
  • 平均周转时间：
  • 带权周转时间——衡量小任务是否被大任务压住了。
    • 定义为：周转时间 / 实际运行时间。
  • 平均带权周转时间：
    • 衡量一组作业的整体等待体验，值越接近 1 说明用户满意度越高。
    • 如果 W 很大，说明你的小任务在后台被大任务压住了，无法及时运行。
2. 系统吞吐量高
  • 定义：单位时间内系统完成的作业数量。
    • 与批处理作业的平均长度有关
  • 提高
    • 多跑短作业
3. 处理机利用率高
  • 多跑计算量大的作业

分时系统的目标

  • 响应时间快
  • 均衡性

实时系统的目标

  • 截止时间的保证
  • 可预测性

3.2 作业与作业调度

3.2.1 作业（Job）

  • 作业：用户交给计算机的一个完整的任务
    • 不仅包含程序和数据，还包含一份作业说明书，告诉操作系统该怎么运行。
  • 作业步：作业被拆分成若干个相互联系、顺序执行的处理步骤。每一个步骤就是一个作业步
作业控制块（JCB）
  • 操作系统中用于管理和描述“作业”的数据结构。
一个典型的 JCB 通常包含以下四类信息：
  1. 作业标识（Identity）：
      • 作业名 / 作业 ID。
      • 用户账号（谁提交的，方便扣费或查权限）。
  1. 资源需求（Resource Requirements）： —— 这是调度时的重要依据
      • 预计运行时间（需要多久）。
      • 内存需求（需要多大空间）。
      • 外设需求（是否需要打印机、磁带机等）。
      • 库函数或文件需求。
  1. 调度信息（Scheduling Info）：
      • 优先级： 决定谁先进入内存。
      • 作业状态： 进入系统了（提交）、正在排队（后备）、正在跑（运行）、跑完了（完成）。
      • 进入时间： 记录作业是什么时候来的（用于计算等待时间）。
  1. 控制信息：
      • 作业说明书的存放地址。
      • 程序及数据的存放起始地址。
作业运行的生命周期
1. 收容阶段 (Admission Stage) —— “挂号排队”
  • 过程： 当你把程序、数据和作业说明书交给操作系统时，系统会先检查一下：你的格式对不对？系统还有没有地方存你的信息？如果没问题，系统就为你创建一个 JCB（作业控制块），把你放在磁盘的“后备队列”里。
  • 对应状态：后备状态 (Backlog State)。
你到了医院，在大厅挂了号，拿到了一个就诊号。此时你并没见到医生，而是在等候区坐着，你的名字出现在了候诊大屏幕上。这个“号”就是 JCB，候诊大厅就是后备队列。
2. 运行阶段 (Execution Stage) —— “进入诊室”
  • 过程： 当系统资源（主要是内存）有空闲时，作业调度程序会从后备队列里挑一个作业，把它调入内存，为它分配必要的资源，并创建进程去执行它。
  • 对应状态：运行状态 (Running State)。
  • 注意： 这里的“运行状态”是一个宏观概念。从作业进入内存开始，到它运行结束前，都属于这个阶段。在这个阶段里，作业对应的进程可能会在 CPU 上跑，也可能在等 IO。
护士喊你的号了，你进入了诊室。医生给你开检查单、化验、诊断。这时候你正处于“被处理”的过程中。
3. 完成阶段 (Termination Stage) —— “缴费取药走人”
  • 过程： 作业的所有步骤都跑完了，或者中途出错了被强行停止。系统会开始“收尾工作”：把运行结果输出，回收分配给它的内存、设备等资源，最后把它的 JCB 撤销（从系统里注销）。
  • 对应状态：完成状态 (Finished State)。
医生看完了，你拿着处方去缴费、拿药。最后你离开了医院，医院的系统里显示你今天的就诊已经结束，你的号牌被回收了。

3.2.2 作业调度的主要任务

  • 根据JCB中的信息，检查系统中的资源能否满足作业对资源的需求。
  • 按照一定的调度算法，从外存的后备队列中选取某些作业调入内存，并为它们创建进程、分配必要的资源。
  • 将新创建的进程排在就绪队列上等待调度。
每次执行调度都做决定：
  • 接纳多少个作业？
  • 接纳哪些作业？

3.2.3 调度算法

1. 先来先服务——FCFS (First-Come, First-Served)

  • 核心逻辑：谁先来，谁先办
  • 唯一准则就是时间顺序。
    • 判断标准： 等待时间。谁在队列里等得最久，谁就最优先。
    • 无视因素： 它完全不看这个作业需要运行多久。哪怕排在第一位的作业需要跑 10 小时，而后面排队的作业只需要 1 秒，系统也会先处理那个 10 小时的。
  • 优点
      1. 最公平： 谁先来谁先办，谁也没意见。
      1. 实现极其简单： 只要一个 FIFO（先进先出）队列就行，算法开销极小。
  • 缺点
      1. 对“短作业”非常不友好： 短作业如果跟在长作业后面，周转时间会变得非常长。
      1. 平均等待时间较长： 整体效率通常不如其他算法。

2. 短作业优先——SJF（Short Job First）

💡
在实际情况中，短作业(进程)占有很大比例，为了能使它们能比长作业优先执行，而产生了短作业优先调度算法。
  • 核心逻辑：谁快谁先上
  • 唯一准则是作业的预计运行时间（估计时长）
    • 时间越短，优先级越高
    • 实现：当系统准备从后备队列挑选作业进入内存时，它会扫描一遍所有的作业，找出那个“干活最快”的。
  • 缺点
      1. 估计时间不准确：
          • 作业还没跑，系统怎么知道它要跑多久？这通常是用户在提交作业时自己填写的。如果用户为了早点运行而故意把时间填短，或者用户自己也预估不准，就会导致调度不准确。
          • 一般会偏长估计。
      1. “饥饿”现象（Starvation）：
          • 如果系统里源源不断地有短作业进来，那么那些长作业（大项目）就永远得不到运行的机会，只能在后备队列里“饿死”。
      1. 不考虑紧急程度：
          • 它只看长短。一个很紧急但时间略长的任务，会被一个不紧急但很短的任务插队。
特性
FCFS (先来先服务)
SJF (短作业优先)
判定标准
到达时间
运行时间
公平性
对长短作业都公平
对短作业极其偏心，对长作业不公
效率
平均等待时间较长
平均等待时间最短（在所有非抢占算法中）
风险
无
可能导致长作业“饥饿”

3. 优先级调度算法——PSA（Priority-Scheduling Algorithm）

  • 前两种算法都无法反应作业的“紧迫程度“。
  • 只看“等了多久”或“要跑多久”是不够的，我们需要一种能直接定义“这个任务有多急、多重要”的机制。

4. 高响应比优先算法——HRRN（Highest Response Ratio Next）

——对 FCFS（先来先服务）和 SJF（短作业优先）的一种综合折中。
  • 目标：既要照顾短作业，又要保证长作业不会等太久。
  • 方法：
    • 引入响应比（），谁分高谁就先执行
  • 原理：
    • 对短作业：因为分母（要求服务时间）很小，所以即使它刚来（等待时间短），它的响应比 也会迅速变得很高。这体现了 SJF（短作业优先） 的优点。
    • 对长作业： 虽然分母很大，一开始 很低。但随着它在队里等得越来越久，分子上的“等待时间”不断变大，它的 会慢慢涨上来。等到了一定程度，它总会变成全场最高，从而获得处理机。这解决了 “饥饿”问题，体现了公平性。

3.3 进程调度

——从就绪队列中选一个进程，把 CPU 分配给它。

3.3.1 进程调度的任务、机制与方式

任务（上下文切换）

1. 保存处理机的现场信息（现场“存档”）
  • 含义： 当一个正在运行的进程（比如 A）时间到了或者被抢占时，系统必须把 A 运行到哪一步了、寄存器里的数值是多少、程序计数器（PC）指到哪了，通通记下来。
  • 存到哪： 存入该进程的 PCB（进程控制块） 中。
  • 目的： 就像打游戏存档一样，下次轮到 A 运行的时候，能从断点处精准“读档”继续跑，而不是从头开始。
2. 按某种算法选取进程（决定“谁上”）
  • 含义： 调度程序（Scheduler）查看“就绪队列”，里面排了一堆等着干活的进程。
  • 依据： 这就是我们之前讨论的调度算法。
    • 是按响应比（HRRN）选？
    • 还是按时间片轮转（RR）选？
    • 还是按短作业优先（SJF）选？
  • 目的： 按照系统的目标（如：追求公平、追求效率、追求响应速度）选出最合适的那个进程（比如进程 B）。
3. 把处理器分配给进程（正式“换班”）
  • 含义： 这一步由分派程序（Dispatcher）执行。它会做两件事：
      1. 从进程 B 的 PCB 中取出上次保存的现场信息，恢复到 CPU 的寄存器里（“读档”）。
      1. 把 CPU 的控制权真正交给进程 B，让它开始执行。
  • 目的： 让选中的进程真正跑起来。

机制

notion image
主要有三部分构成：
1. 排队器 (Queuer) —— “排号员”
  • 功能： 当一个进程进入就绪状态时（比如刚创建完，或者刚从阻塞状态醒来），排队器负责把它插入到相应的就绪队列中。
  • 逻辑： 为了提高效率，系统通常不只有一个队列。排队器会根据进程的优先级、类型（是计算密集型还是 I/O 密集型）把它们送往不同的“窗口”排队。
2. 分派器 (Dispatcher) —— “叫号员”
  • 功能： 根据调度算法，从就绪队列中选出一个进程。
  • 动作： 它是做决策的那个“大脑”。它决定了谁是下一个作业上 CPU 运行。
3. 上下文切换器 (Context Switcher) —— “换班员”
  • 功能： 这是真正干体力活的，负责处理“换班”时的细节。
  • 流程（图中虚线部分）：
      1. 保存现场： 把当前正在 CPU 上跑的进程的各种数据（寄存器数值、程序计数器等）塞回它对应的 PCB（进程控制块） 里。
      1. 恢复现场： 把分派器选中的那个新进程的 PCB 里的数据拿出来，填到 CPU 的寄存器里。
      1. 移交控制权： 让 CPU 开始跑新进程的代码。

进程调度方式

1. 非抢占方式
——任务结束才能换作业
  • 一旦把处理机分配给某进程后，就一直让它运行下去
    • 不会因为时钟中断或任何其它原因去抢占当前正在运行进程的处理机
    • 直至该进程完成，或发生某事件而被阻塞（如读硬盘，请求IO）时，才把处理机分配给其它进程。
  • 优点： 简单，系统开销小（不需要频繁切换）。
  • 缺点： 极不公平。如果前面排了一个“大长作业”，后面的短作业或紧急任务只能干等。
2. 抢占方式
——随时叫停更换任务
  • 一旦发现更重要（优先级更高）或者更紧急（时间片到了）的进程，会暂停某个正在执行的进程，让其重新排队，把 CPU 让给留那个一个进程。
三个原则：
  1. 优先权原则： 来了个更重要的（高优先级）进程。
  1. 短作业优先原则： 新来的作业明显比现在的快得多。
  1. 时间片原则： 规定每个任务跑 10ms，到点就换（这是分时系统的基础）。
💡
目前的现代OS都采用抢占方式。
原因：
  1. 公平性（批处理系统）： 防止一个大任务一直霸占 CPU，让其他任务都能轮流用上。
  1. 人机交互（分时系统）： 这是最关键的。你移动鼠标、敲击键盘，系统必须立刻“抢占”当前正在后台跑的程序来响应你。如果不抢占，你点个图标可能要等后台压缩完文件才有反应。
  1. 实时性（实时系统）： 比如车载系统感应到要撞车了，这个“刹车进程”必须瞬间抢占正在放音乐的进程，否则后果不堪设想。
  • 代价：系统开销大

3.3.2 轮转调度算法（RR）

过程

  • 排队： 所有想要运行的进程按“先来先服务”（FCFS）原则排成一队。
  • 定额： 系统规定一个固定的时间长度，叫做“时间片”（Time Slice，如 30ms）。
  • 分配： CPU 只给排在队首的任务用这 30ms。
  • 轮换： 30ms 时间一到，不管干没干完，打回队尾重新排队，CPU 给下一个任务用。

切换时机

① 提前完成
场景： 给这个进程分配了 10ms，但它执行到第 5ms 就把任务跑完了。
动作： 系统会立即把它从就绪队列里删掉，然后调下一个进程上来，并且给下一个进程重新计时（开始一个新的完整时间片）。
② 时间片用完
场景： 10ms 到了，但这个大工程还没搞定。
动作： 计时器发出中断信号，调度程序强行中止该进程。为了公平，系统把它踢到就绪队列的末尾去重新排队，然后把 CPU 给现在的队首进程。

时间片大小的确定

时间片大小的确定对系统性能影响很大。
对响应时间的影响
这张图揭示了时间片 q 与用户交互时间 s（比如你点一下鼠标，系统处理完所需的时间）之间的博弈。
notion image
  • 图 (a) （理想情况）：
    • 时间片 q 足够大，能覆盖掉大部分简单的交互任务。
    • 结果： 进程在第一个时间片内就干完活了，响应时间就是 s。用户感觉非常快，系统也没有多余的切换开销。
  • 图 (b) （糟糕情况）：
    • 时间片太短，任务还没干完就被强行踢下 CPU 去排队。
    • 结果： 进程被迫等待其他进程运行完后，再拿第二个时间片才能完成。
    • 代价： 响应时间变成了原来的好几倍（图中的总长度 s 变长了），用户会明显感到掉帧或卡顿。
对周转时间的影响
进程名称及指标
A
B
C
D
E
平均 (Average)
到达时间
0
1
2
3
4
-
服务时间
4
3
4
2
4
-
RR (q=1) 情况
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ
完成时刻
15
12
16
9
17
-
周转时间
15
11
14
6
13
11.8
带权周转时间
3.75
3.67
3.5
3
3.33
3.46
RR (q=4) 情况
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ
完成时刻
4
7
11
13
17
-
周转时间
4
6
9
10
13
8.4
带权周转时间
1
2
2.25
5
3.33
2.5
  • 在本例中，q=4 的表现明显优于 q=1。
  • 因为 q=4 足够大，使得像 A、B、C 这样的进程在第一个时间片内或较短时间内就能完成，减少了进程在就绪队列中往返排队的次数，从而大幅降低了平均周转时间（从 11.8 降到 8.4）。

3.3.3 优先级调度算法

如果说之前的“轮转调度（RR）”是追求绝对公平，那么“优先级调度”就是追求效率和差异化服务（重要的、急的事先办）。
根据优先级的变动情况，分为以下两类：

1. 静态优先级

  • 定义： 在进程创建时就定死了，整个运行期间优先数保持不变。
  • 定数依据：
      1. 进程类型： 系统进程优先级通常高于用户进程。
      1. 资源需求： 对 CPU 要求不高的进程（如频繁等待读写磁盘的进程）往往会被给高一点的优先级，这样能提高整体资源利用率。
      1. 用户要求： 比如管理员手动给某个关键任务提高优先级。
  • 缺点： 可能会导致“饥饿”现象。如果系统里一直有高优先级的新任务进来，低优先级的任务可能一辈子都轮不到运行。

2. 动态优先级

  • 定义： 进程刚创建时有一个初始值，但在运行过程中，它的值会根据情况“自动调整”。
  • 规则：
    • 等待越久，级别越高： 这叫“老化”（Aging）。为了防止低优先级进程被饿死，如果它在队列里等太久，系统会自动给它“提拔”一级，直到它能被运行。
    • 运行越久，级别越低： 如果一个进程占着 CPU 不撒手，系统会慢慢调低它的优先级，让出位置给别人。

3.3.4 多队列调度算法

——为了解决之前算法的一个通病：“一刀切”。
  • 以前的做法： 系统里只有一个“就绪队列”，不管是系统关键进程、交互式进程（如键盘输入），还是后台大计算进程（如视频渲染），大家都挤在一起。
  • 单一策略的局限性： 如果用轮转法（RR），对后台任务不划算（切换太频繁）；如果用先来先服务（FCFS），对前台交互任务太慢。
  • 多处理机环境： 在多核 CPU 时代，如果只有一个队列，所有的 CPU 核心都要去抢这一个队列，会造成严重的拥堵和管理混乱。
工作原理
它的核心思想是：“分类管理，因材施教”。
系统将就绪队列拆分成多个独立的队列，每个队列代表一种特定的任务类型。
  • 队列 1（高优先级）： 放系统任务（如驱动、内核任务）。采用抢占式优先级算法。
  • 队列 2（中优先级）： 放前台交互任务（如文档编辑器、浏览器）。采用轮转法（RR），追求响应快。
  • 队列 3（低优先级）： 放后台批处理任务（如系统更新、杀毒扫描）。采用先来先服务（FCFS），追求吞吐量。

3.3.5多级反馈队列（Multilevel Feedback Queue, MLFQ）调度算法

1. 调度机制 (Mechanism)

notion image
该算法通过设置多个队列并动态调整进程所属队列，实现了灵活调度：
  • 设置多个就绪队列：
    • 优先级逐级降低： 队列1优先级最高，队列2次之，以此类推。
    • 时间片逐级增长： 优先级越高的队列，分配到的时间片越小。即：。
  • 进程在队列间的移动规则：
    • 新进程： 首先放入第一队列末尾，按先来先服务（FCFS）等待调度。
    • 降级处理： 如果进程在当前队列的时间片内没跑完，调度程序会把它降级到下一级队列的末尾。
    • 最终阶段： 当进程降到最后一级（第 n 队列）时，该队列通常采用时间片轮转（RR）方式运行。
  • 队列间的调度优先级：
    • 高优先级优先： 只有当第 队列全部为空时，才会调度第 i 队列中的进程。
    • 抢占机制： 如果 CPU 正在执行第 i 队列的进程，此时有一个新进程进入了更高优先级的队列（，新进程会抢占 CPU，被抢占的进程放回原队列末尾。

2. 调度算法的性能 (Performance)

该算法之所以被广泛应用，是因为它能同时兼顾各类用户的需求：
  1. 终端型用户（交互式）：
      • 这类任务通常很短（如点个鼠标、打个字）。由于它们一进入就在第一队列，且第一队列优先级最高，因此能获得极快的响应时间。
  1. 短批处理作业用户：
      • 这类任务通常在第一或第二队列的时间片内就能完成，周转时间非常短。
  1. 长批处理作业用户：
      • 这类任务虽然会不断下沉到低优先级队列，但时间片会越来越大。这意味着虽然它们被调度的次数少了，但一旦拿到 CPU，就能连续运行很久，减少了频繁切换的开销。

3.3.6 基于公平原则的调度算法

与之前的“优先级调度”不同，这类算法不分贵贱，核心目标是公平，确保每个进程（或每个用户）都能得到应得的一份 CPU 时间。

1. 保证调度算法 (Guaranteed Scheduling)

这种算法向用户做出一个明确的承诺：“如果你和其他个任务一起跑，我保证你能分到 的 CPU 时间。”
原理：
为了实现这个“合同”，系统需要不断地进行数学计算：
  1. 记录实际时间： 记录每个进程从创建到现在，到底在 CPU 上跑了多久（实际时间）。
  1. 计算应得时间： 计算从进程创建到现在，它本来“应该”分到多少时间（总时间 / n）。
  1. 计算比率： 。
      • 比率 < 1.0： 说明你还没分够，系统欠你的。
      • 比率 > 1.0： 说明你跑超了，占了别人的便宜。
  1. 调度策略： 调度程序总是挑选比率最小的进程来运行，直到它的比率追上别人为止。
就像分蛋糕，如果现在有 4 个人。系统会盯着看谁吃得最慢，然后就把叉子递给谁，直到他吃得跟别人一样多为止。

2. 公平分享调度算法 (Fair Share Scheduling)

——对“保证调度算法”的一个重要修正。
公平性的漏洞
如果只看“进程”层面的公平，会导致“用户”层面的不公平：
  • 用户 A： 开了 9 个下载任务（9 个进程）。
  • 用户 B： 只开了 1 个网页（1 个进程）。
  • 如果按“进程”平分，用户 A 会占掉 90% 的 CPU，而用户 B 只有 10%。这显然对用户 B 极度不公平。
它的核心逻辑
公平分享算法把“公平”的维度从进程提升到了用户（或用户组）。
  • 系统先给每个用户分配相等的 CPU 份额。
  • 比如两个用户，每人 50%。
  • 无论用户 A 开了多少个进程，这 9 个进程只能内部去分那 50% 的时间；而用户 B 的那 1 个进程能独享剩下的 50%。

3.4 实时调度

——核心目标：必须满足截止时间要求
  • 重点不在快，而是准时

3.4.1 实现实时调度的基本条件

1. 提供必要的信息

实时调度程序需要根据任务的紧急程度来排班，所以每个任务必须提前告知：
  • 就绪时间： 任务什么时候能开始。
  • 截止时间： 什么时候必须开始或完成（这是核心，没按时完成就算失败）。
  • 处理时间： 任务跑完需要多久。
  • 资源要求： 需要哪些内存、外设资源。
  • 优先级： 是“死命令”（绝对优先级）还是“尽量快”（相对优先级）。

2. 系统处理能力强

核心公式：
  • ： 第 i 个任务的处理时间。
  • ： 第 i 个任务的周期时间。
  • ： 这个任务占用了 CPU 多少百分比的“带宽”。
  • 含义： 如果所有周期性任务占用的 CPU 百分比之和大于 1（即 100%），说明 CPU 忙不过来，一定会有任务错过截止时间。
  • 解决办法： 增加 CPU 核心数，或者提高主频。

3. 采用抢占式调度机制

  • 在非实时系统中，一个任务可能一直占着 CPU。
  • 在实时系统中，必须是抢占式的。一旦有一个更高优先级的实时任务（HRT）就绪，系统必须能够立刻打断当前任务，把 CPU 让给最紧急的任务，以确保截止时间不被错过。

4. 具有快速切换机制

如果抢占发生了，但系统“切换任务”的过程太慢，也会影响效率。这需要两个能力：
  • 快速中断响应： 硬件能迅速察觉到紧急信号，并让 CPU 停下当前工作。
  • 快速分派能力： 操作系统内核要非常精简，把进程切换（Context Switch）的时间压缩到极致。就像F1赛车换轮胎，每一秒都关系到生死。

3.4.2 实时调度算法的分类

  • 按实时：
    • 硬实时
    • 软实时
  • 按调度方式：
    • 非抢占调度
    • 抢占调度

1. 非抢占式调度算法（比较“温和”，实时性较差）

在这种模式下，就算紧急任务来了，也不能立刻把正在干活的任务踢走，必须等人家干完。
  • (a) 非抢占式轮转调度 (Non-preemptive Round Robin)：
    • 逻辑： 任务排成一圈，轮流用 CPU。
    • 图解： 实时进程请求调度后，得排在进程 1、进程 2... 进程 n 的后面。只有等前面的兄弟们都跑完了，才轮到实时进程。
    • 缺点： 响应时间非常长，不适合高实时要求的场景。
  • (b) 非抢占式优先权调度 (Non-preemptive Priority)：
    • 逻辑： 实时进程优先级高，可以“插队”到队列最前面。
    • 图解： 实时进程来了，发现 CPU 正在跑“当前进程”。它不能中断人家，只能在旁边等着。等“当前进程”运行完成的一瞬间，它立刻顶上去。
    • 缺点： 如果“当前进程”是一个需要跑很久的大任务，实时进程还是会等很久。

2. 抢占式调度算法（比较“霸道”，实时性强）

这种模式下，紧急任务可以直接打断当前正在运行的任务。
  • (c) 基于时钟中断抢占的优先权调度：
    • 逻辑： 不是立刻抢，而是等“闹钟”响。
    • 图解： 实时进程请求调度，系统收到了，但没动作。直到下一个时钟中断（Clock Interrupt）到来时，调度程序才醒过来，发现有贵客，于是把当前进程换下来，让实时进程上。
    • 评价： 延迟取决于时钟频率（通常是几个毫秒），比非抢占式好很多。
  • (d) 立即抢占 (Immediate Preemption) 的优先权调度：
    • 逻辑： 真正的“秒回”，一刻都不等。
    • 图解： 只要实时进程发出请求，系统立即产生中断，强行停止当前进程，并在极短的调度开销后立刻运行实时进程。
    • 评价： 这是硬实时系统（如导弹控制、自动驾驶）必须采用的机制。它的响应时间（调度时间）被压缩到了微秒级。
notion image
调度方式
什么时候切换？
响应延迟
适用场景
(a) 轮转
轮到你了才换
极高
简单、非实时
(b) 非抢占优先
当前进程主动结束
较高
任务都很短的实时系统
(c) 时钟中断抢占
等下一个时钟滴答
较低
软实时系统（如视频播放）
(d) 立即抢占
立刻、马上
极低
硬实时系统（工业控制、航天）

3.4.3 最早截止时间有限算法——EDF(Earliest Deadline First)

核心思想：谁的任务最赶时间（截止时间最早），就让谁先做。

1. 非抢占式调度用于非周期任务

在非抢占式的情况下，即使新来的任务更紧急，也得等当前任务做完。
notion image
  • 执行逻辑：
      1. 任务 1 先到达并开始执行。
      1. 在任务 1 执行期间，任务 2 和 任务 3 陆续到达。
      1. 调度程序查看它们的截止时间：发现 任务 3 的截止时间 比 任务 2 早。
      1. 等任务 1 执行完，系统不按到达顺序，而是优先安排任务 3，最后才运行任务 2。
  • 适用场景： 任务执行时间短，或者对实时性要求不是极其严苛的场景。

2. 抢占式调度用于周期性任务

notion image
案例背景：
  • 任务 A：每 20ms 来一次，每次做 10ms（）。
  • 任务 B：每 50ms 来一次，每次做 25ms（）。
EDF 运行轨迹：
  1. t = 0ms：A1 和 B1 同时到达。A1 的截止时间是 20，B1 是 50。A1 截止时间早，先跑 A1。
  1. t = 10ms：A1 跑完了，开始跑 B1。
  1. t = 20ms：关键点！ A2 到达了。
      • 此时 B1 还没跑完（还剩 15ms），B1 的截止时间是 50。
      • A2 的截止时间是 40。
      • 因为 40 < 50，所以 A2 抢占了 B1。B1 被踢下去，A2 开始跑。
  1. t = 30ms：A2 跑完了，B1 继续跑剩下的 15ms。
  1. t = 40ms：A3 到达。
      • A3 的截止时间是 60。
      • 此时 B1 还没跑完（还剩 5ms），B1 的截止时间是 50。
      • 因为 50 < 60（B1 更急），所以 B1 继续跑，A3 必须等着。
  1. t = 45ms：B1 总算跑完了，A3 开始跑。

3. 为什么 EDF 更好？（对比结论）

看图片最下方的对比：
  • 固定优先级调度：如果给 A 高优先级，B 可能会错过截止时间（错过 50ms 的节点）；如果给 B 高优先级，A 可能会错过截止时间。
  • EDF（动态优先级）：优先级不是写死的，而是随着截止时间的逼近而改变。这种灵活性使得它能比固定优先级算法更充分地利用 CPU 资源，保证更多的任务不“违约”。

EDF 的精髓：

  • 不看出身（到达时间）。
  • 不看地位（固定优先级）。
  • 只看截止日期（Deadline）。
在单处理机环境下，只要总的利用率 ，EDF 算法就能保证所有任务都在截止时间前完成。

3.4.4 最低松弛度优先算法——LLF（Least Laxity First）

松弛度 = 必须完成的时间 - 任务本身还需要运行的时间 - 当前时间
  • 松弛度 = 0：意味着必须现在立刻开始跑，否则绝对跑不完。
  • 松弛度很大：意味着可以先睡会，晚点再写也没事。
  • 系统会不断计算所有就绪任务的松弛度，并优先执行松弛度最低的任务。这通常是一种抢占式调度。

案例详解：

还是回到上一个算法的场景。
notion image
notion image
  • t = 0ms：
    • A1 的松弛度 = 20 - 10 - 0 = 10
    • B1 的松弛度 = 50 - 25 - 0 = 25
    • 结果：A1 松弛度更低，A1 开始运行。
  • t = 10ms：
    • A1 运行结束。此时只有 B1 在排队。
    • 结果：B1 开始运行。
  • t = 20ms（关键点）：
    • 任务 A2 到达。
    • A2 的松弛度 = 40 - 10 - 20 = 10
    • B1 已经跑了 10ms，还剩 15ms。B1 的松弛度 = 50 - 15 - 20 = 15
    • 虽然 A2 更急，但在某些 LLF 实现中（为了减少切换开销），如果松弛度没到 0，可以先不抢占。但严格来说，此时 A2 (10) < B1 (15)，A2 应该抢占。
    • 注：书中的图 3-9 采用了“等到松弛度为 0 再抢占”的策略。
  • t = 30ms：
    • A2 的松弛度 = 40 - 10 - 30 = 0（火烧眉毛了！）
    • B1 此时还剩 5ms。B1 的松弛度 = 50 - 5 - 30 = 15
    • 结果：A2 的松弛度降到了 0，必须立刻抢占 B1。A2 开始跑，B1 停下。
  • t = 40ms：
    • A2 运行结束。B1 还有最后 5ms 没写完。
    • 此时 A3 也到达了，A3 的松弛度 = 60 - 10 - 40 = 10。
    • B1 此时的松弛度 = 50 - 5 - 40 = 5。
    • 结果：B1 更急（5 < 10），B1 优先补完剩下的 5ms。

3.4.5 优先级倒置

在优先级调度算法中，我们期望高优先级的任务能优先执行，但在某些情况下，高优先级任务反而会被低优先级任务阻塞，且被中优先级任务“插队”抢占执行时间。
notion image

1. 问题的起因（低优先级占用了资源）

  • 初始阶段：低优先级的进程 最先运行，它执行了 P(mutex) 操作，进入了临界区 ，并拿到了互斥锁（资源）。
  • 时刻 a：中优先级的进程 到达。因为 优先级高于 ，它抢占了 CPU， 被挂起（但手里还拿着锁）。

2. 冲突的发生（高优先级被阻塞）

  • 时刻 b：高优先级的进程 到达。它是级别最高的，立刻抢占了 开始运行。
  • 时刻 c： 运行到一半，也需要使用那个互斥资源（执行 P(mutex)）。但由于锁在 手里， 被阻塞，进入等待状态。

3. 核心问题点（中优先级的“插队”）

  • c 到 d 之间：按理说， 在等 放锁，此时应该让 赶紧跑完把锁还给 。
  • 但是，系统中还有一个就绪的 。因为 的优先级比 高，调度器会选择 优先运行。
  • 结果： 一直运行到结束（时刻 d），这段时间内，最高级别的 只能眼睁睁看着 在跑，自己却在等 。

4. 最终解决

  • 时刻 d： 运行完了，CPU 终于回到了 手中。 继续执行临界区代码。
  • 时刻 e： 执行 V(mutex) 释放了锁。此时，阻塞的 立即被唤醒，抢占 CPU 进入临界区 执行。

解决：优先级继承

在之前的问题图中，高优先级的 被中优先级的 无端阻塞。而在这一张图中，通过“临时提升优先级”的策略，成功缩短了 的等待时间。
notion image
  • 时刻 c：P1 请求互斥资源（P(mutex)），但资源被 P3 占用，P1 进入阻塞状态。
  • 关键变化：此时系统发现高优先级的 P1 在等 P3。为了防止 P2 插队，系统将 P3 的优先级临时提升到与 P1 相同的水平。这就是图中标注的“继承”。
  • c 到 d 之间：因为 P3 现在拥有了“伪高优先级”，它比 P2 级别更高。所以 P3 能够抢回 CPU 继续执行，而 P2 只能继续等待。
  • 时刻 d：P3 执行完临界区代码，调用 V(mutex) 释放资源。
    • 优先级复原：一旦释放资源，P3 的优先级立刻跌回原本的低水平。
    • P1 夺回控制权：资源空闲后，P1 立即被唤醒并抢占 CPU，进入 CS−1 执行。
  • 时刻 e：P1 全部运行结束。此时系统中优先级最高的是 P2，于是 P2 开始恢复运行。

习题

1、下列进程调度算法中，综合考虑进程等待时间和执行时间的是（ ）。
A. 时间片轮转 B. 短进程优先 C. 先来先服务 D. 高响应比优先
答案
D
考点： HRRN 的核心公式 响应比=(等待时间+服务时间)/服务时间
 
2、【2017 408】下列有关基于时间片的进程调度的叙述中，错误的是（ ）。
A. 时间片越短，进程切换次数越多，系统开销越大
B. 当前进程的时间片用完后，该进程状态由执行态变为阻塞态
C. 时钟中断发生后，系统会修改当前进程在时间片内的剩余时间
D. 影响时间片大小的主要因素包括响应时间、系统开销和进程数量等
答案
B
解析：进程切换带来系统开销，切换次数越多，系统开销越大，即A选项正确； 当前进程的时间片用完后，该进程状态由执行态变为就绪态，即B选项错误； 时钟中断是系统特定的周期性时钟节拍。操作系统通过它来确定时间间隔，实现时间的延时和任务的超时，即C选项正确； 现代操作系统为了保证性能最优，通常根据响应时间、系统开销、进程数量、进程运行时间、进程切换开销等因素确定时间片大小，即D选项正确。
3、假设4个作业到达系统的时刻和运行时间如下表所示。
notion image
系统在t=2时开始作业调度。若分别采用先来先服务和短作业优先调度算法 ，则选中的作业分别是 A．J2、J3 B．J1、J4 C．J2、J4 D．J1、J3
答案
D
解析：系统在 t=2时开始作业调度，若采用先来先服务调度算法，此时已有J1、J2和J3作业到达，作业来得越早优先级越高，则选中的作业是J1；若采用短作业优先调度算法，此时已有J1、J2和J3作业到达，但作业运行时间大小排序为J3<J2=J1，作业运行时间越短优先级越高，则选中的作业是J3。
4、 高响应比优先 HRRN 分析题
有 4 个作业：
J1：到达 0，服务时间 3
J2：到达 2，服务时间 6
J3：到达 4，服务时间 4 J4：到达 6，服务时间 2 系统采用 高响应比优先 HRRN。 要求： （1）在每次调度时，计算所有已到达作业的响应比； （2）给出作业选择顺序； （3）求平均周转时间； （4）说明 HRRN 为什么能兼顾短作业和长作业。
 
 
 
 
 
]]> <![CDATA[Summer Pocket 踩点小结]]> http://richardliuda.top/article/summerpocket http://richardliuda.top/article/summerpocket Sun, 22 Mar 2026 00:00:00 GMT

东涌

  • 吃得很少，很贵，拍摄尽量自己带吃的
  • 民宿旁边有个小公园，可以拍点树林景
      • notion image
      notion image
      notion image
  • 民宿是个小区，楼底下有一些娱乐设施，滑滑梯之类的，貌似还能烧烟花（有看到仙女棒的残骸），晚上如果方便的话可以拍一些夜景
      • notion image
  • 海滩入口有洗手间，比较方便
  • 穿鼻岩那边有石滩，但是今天没开放，六月份不知道能不能开
      • notion image
      notion image
  • 民宿到海滩大概一公里，会穿过一个小村子，挺整洁的，感觉可以拍点粗点心屋的景
      • notion image
      notion image
    • 这边的小路也挺还原
        • notion image
       

红树林公园

  • 不是很值得单独去，能用的景少，树矮，稀疏
notion image
  • 树少
notion image
notion image
  • 这里可以拍点有纵深的合照
💡
可以选择第一天先去华侨城拍点树林景，拍完之后再去东涌
或者就在民宿旁边的小树林拍一拍

备选

桔钓沙&杨梅坑

优点
  • 交通较便利，比东涌近一点，少走很多山路
  • 沙滩大，沙质比东涌略好，石滩近邻沙滩，方便
  • 有堤坝景，不过坝上应该不开放
  • 吃的东西多一点，能叫到葵涌的外卖
  • 树林多
缺点
  • 人多，车多，节假日车位紧张
  • 海滩旁没有比较还原的村道，比较景区化
    • 最近的要走两公里
  • 民宿会贵
  • 有树林景，但是小路少，都是马路或者路旁的栈道，且要走一段距离
notion image

华侨城（树林景）

  • 如果老师方便（鸥/嗨梨等）第一天可以去东涌前白天先去华侨城拍一点树林景
  • 拍完之后和摄影老师一起开车前往东涌民宿
notion image

需要注意的地方

  • 节假日有可能会堵车，如果第二天需要返回其他城市的，需要预留一下时间
  • 回广州/东莞可以选择去罗湖坐高铁，末班车十点半左右
  • 东涌开车过去最乐观估计需要一个半小时，堵车的话三四个小时（节假日包堵的）
  • 大家最好带上坐垫，因为很多需要坐地上的场景，那边没有专门露营的设计，所以地上不会很干净
  • 可能涉及到海滩踩水的场景，看看各位老师是否接受吧，如果要拍的话也需要做下准备
  • 尽量多带点吃的，东涌本地吃的少，贵，且外卖送不进来

地图

notion image
地图如上↑
红色箭头为路线，请大家存好以防迷路(=^▽^=)

to coser

coser老师们请熟记好时间，姿势(注意右上角有标注的地方为批注)，地点！
10:45为上午小组照人员出发时间（即诺儿 绀雾erika明宴 柊 海琴烟）
其余所有人员可以稍晚，但需于11:15到达图中标星号位置，程约800米自己掐好走路时间
notion image
  • 请自备好午餐 中午午休原地休息
  • 带好补妆用品(坐高铁有些会被收要注意) 防晒用品
  • 没有安排的时候可以自行寻找搭子拍小视频，集邮 也可以就地休息

to 摄影

请摄影老师们熟记拍摄时间，拍摄对象
10:45全员出发
  • 请自备好午餐 中午午休原地休息
  • 带好防晒用品
  • 没有安排的时候可以帮忙其他老师一起拍照，集邮 也可以就地休息
 
 
 
]]> <![CDATA[数据库系统笔记]]> http://richardliuda.top/article/Database http://richardliuda.top/article/Database Mon, 12 Jan 2026 00:00:00 GMT

一、绪论

文件系统的问题

ACID

  • 原子性(atomicity)
  • 一致性(consistency)
  • 隔离性(isolation)
  • 持久性(durability)

不同类型的DB

分层数据库系统

  • 树状结构，用指针连接，存在一对多
notion image
  • 缺点
    • 查询复杂（递归）
    • 难保证数据一致性
    • 难扩展
    • 缺乏标准
    • 权限不好分配

网状数据库系统

  • 无环图
      • notion image
  • 缺点
    • 复杂
    • 难维护

关系型数据库系统

  • 组织为表
      • notion image

数据库系统DBS

  • 组成
    • Database
    • Data model
    • DBMS

DB语言

  • 定义db格式
  • 增删改查
    • 分类
      • 过程化DML
        • 用户需同事知道要什么和怎么要数据
      • 非过程化DML
        • 用户只需要知道要什么数据
        • SQL

数据库模式DB Schema

  • 数据库的逻辑结构
    • 概念模式
      • 定义db所有数据
    • 物理模式
      • 描述如何存储数据
    • 用户视图
      • 只描述用户可访问的数据
  • 三层模式结构
    • 外部层
    • 概念层
    • 内部层
      • notion image
  • 提供访问控制机制
 

二、关系型数据库管理系统RDBMS

  • 表就是关系
notion image
  • 属性：列
  • 元组，记录：行
  • 表头：属性名

模式Schema

  • 定义：属性的集合，就是表的结构
    • 一旦确定，改动的代价很大
  • State：具体的所有数据
    • 就是数据条目，经常被修改

关系型数据库

关系的性质

  • 无序性
  • 无重复行
  • 无多值属性

空值Null

  • 使用条件
    • 未知
    • 后续将确定
    • 不适用
  • 不同于0和空格
  • 数值计算中null = 0
  • 排序中null为无穷大

超键sk

  • 可唯一确定的字段集合
notion image
  • 一个关系至少有一个sk（所有字段的集合）
  • 包含sk的集合也是sk
  • 只给一个关系的State，只能证明一个字段的集合不是sk，不能证明它就是sk

键

  • 极小化的sk
      1. 它能唯一标识一行（它是 SK）。
      1. 不能再减了。你要是再从这个集合里踢掉一个字段，它就没法唯一标识了。
  • 一个关系的key可唯一确定关系表的一行。
  • 一个关系至少有一个key，即所有字段的集合极小化的结果。

候选键ck

  • 一个关系的 Key 也称为 Candidate Key
  • 有资格当主键pk的候选
notion image

主键pk

  • 包含字段个数最少的ck之一
  • pk被选定之后不能更换
  • 唯一且非空
    • pk的值不能重复，且不能有空值

外键fk

R1 是键所在的表，R2 是被引用的表（通常主键 PK 在 R2 里）。
  • 规则 ①：门当户对。 FK 和它引用的 PK 必须有相同数量的字段，而且数据类型得兼容。
  • 规则 ②：活要见人，死要见尸（参照完整性）。 对于 R1 里的每一行，它的外键值只有两条路走：
      1. 要么是 null：代表你现在是个断线的风筝，还没跟谁搞上关系。
      1. 要么就必须在 R2 的主键里能找着。 这叫参照完整性约束。
  • fk需要显式指定

三、MySQL

SQL概览

  • Structural Query Language
  • 核心组件
    • DDL：数据定义语言 (Data Definition Language)
      • 定义数据库对象（数据库，表，字段）
    • DML：数据操纵语言 (Data Manipulation Language)
      • 增删改
    • DQL：数据查询语言 (Data Query Language)
      • 查
    • DCL：数据控制语言 (Data Control Language)
      • 创建DB用户，管理权限
  • 语句不区分大小写

DDL

  • DB的操作
    • 查询
      • 创建
        • CREATE DATABASE [IF NOT EXISTS] DB名 [DEFAULT CHARSET 字符集];
        • 加IF NOT EXISTS 避免因为已存在该DB而报错
        • 一般用utf8mb4可以每个数据4bytes
      • 删
        • DROP DATABASE [IF EXISTS] DB名;
      • 切换到指定DB
        • USE DB名
    • 数据表
      • SHOW TABLES 查询当前db所有表
      • DESC 表名 查询结构（Describe）
      • SHOW CREATE TABLE 查询指定表的建表语句
      • 创建
        • 如
        • 数据类型
          • 数
            • 类型
            描述
            大小 / Byte(s)
            TINYINT
            小整数
            1
            SMALLINT
            大整数
            2
            MEDIUMINT
            大整数
            3
            INT 或 INTERGER
            大整数
            4
            BIGINT
            极大整数
            8
            FLOAT
            单精度浮点数
            4
            DOUBLE
            双精度浮点数
            8
            DECIMAL
            小数值(精确定点数)
            /
          • 文本（使用时需指定长度）
            • 类型
            描述
            备注
            CHAR
            定长字符串
            长度不足用空格补足，也占固定空间，适用于性别等长度基本确定的字符串
            VARCHAR
            变长字符串
            按实际长度分配空间，适用于用户名等长度不确定的字符串
            TINYTEXT
            短文本字符串
            /
            TEXT
            长文本数据
            /
            MEDIUMTEXT
            中等长文本数据
            /
            LONGTEXT
            极大文本数据
            /
          • 日期时间
            • 类型
            描述
            格式
            大小
            DATE
            日期值
            YYYY-MM-DD
            3
            TIME
            时间值或持续时间
            HH:MM:SS
            3
            YAER
            年份值
            YYYY
            1
            DATETIME
            混合日期和时间值
            YYYY-MM-DD HH:MM:SS
            8
            TIMESTAMP
            混合日期和时间值、时间戳
            YYYY-MM-DD HH:MM:SS
            4
        • 表的修改
          • 增
              • ALTER TABLE 表名 ADD 字段名 类型(长度) ［COMMENT注释］［约束］;
          • 改
              • AFTER TABLE 表名 MODIFY 字段名 新类型(长度)
              AFTER TABLE 表名 CHANGE 旧名 新名 类型(长度) [COMMENT] [长度]
          • 删
              • AFTER TABLE 表名 DROP 字段名
          • 改表名
              • ALTER TABLE 表名 RENAME TO 新表名
          • 删表
              • DROP TABLE [IF EXISTS］表名；#删除表
              TRUNCATE TABLE 表名；#删除指定表，并重创建该表 clear操作

        DML

        • 添加数据
          • 字段顺序要对应
          • 字符串和日期要用引号
          • 不要超界
        • 修改数据
            • UPDATE 表名 SET 字段名1 = 值1, 字段名2 = 值2, ... [WHERE 条件]; # 修改数据
          • 一定加where，不然所有值都会改变
        • 删除数据
            • DELETE FROM 表名 [WHERE 条件]; # 删除数据
          • 同上
          • 如果只是将值置空，用update+set null

        DQL

        • 基础查询
          • 基本：SELECT，FROM
            • 条件：WHERE
                • 条件
              • 单条件
                  • 比较运算符
                  功能
                  >
                  大于
                  >=
                  大于等于
                  <
                  小于
                  <=
                  小于等于
                  =
                  等于
                  <> 或 !=
                  不等于
                  BETWEEN 最小值 AND 最大值
                  在某范围内的值(含最小值、最大值)
                  IN(...)
                  任一在列表中的值
                  LIKE 占位符
                  模糊匹配('_' 匹配单个字符, '%' 匹配多个字符)
                  IS NULL
                  是 NULL
              • 多条件
                  • 逻辑运算符
                  功能
                  AND 或 &&
                  且
                  OR 或 ||
                  或
                  NOT 或 !
                  非, 否
                  有以下的等价性：
                  ① = SOME(…)等价于 IN(…) .
                  ② <> SOME(…) 不等价于 NOT IN(…) .
                  ③ <> ALL(…) 等级与 NOT IN(…) .
            • 聚合函数：COUNT，MAX，MIN，AVG，SUM
                • 聚合函数
                功能
                COUNT
                统计数量
                MAX
                最大值
                MIN
                最小值
                AVG
                平均值
                SUM
                求和
              • SELECT AVG(age) FROM agetable; 统计平均年龄（输出数字）
              • Null不参与运算
            • 分组：GROUP BY
              • 过滤分组后的数据：HAVING
                • HAVING可用聚合函数作为条件
              • 分组后，除了分组字段，其他字段会被折叠，无法单独查询。所以只能查询聚合函数或者分组字段。
            • 分页：LIMIT
            • 排序：ORDER BY
              • ASC：非降序（默认），从小到大
              • DESC：非升序，从大到小
          • 编写顺序：
          • 执行顺序：
          • 所以别名（AS后的）只能在SELECT后用，不能在WHERE和GROUP BY用
          综合应用：

          DCL

          • 创建用户 (CREATE USER)
            • 主机名
              • localhost为只能本地连接
              • 可以为’%’，即可以在任意ip连接
          • 赋予权限（GRANT）
            • 准许 caixukun 在 company 这个库里，干所有的脏活累活（增删改查）。
            • company.*：意思是 company 库下面的所有表，他都能碰。
            • 但是不能建表（CREATE），也不能删表（DROP）。
            • 将所有库，所有表的所有权限给richardliu 。
            • 可以在权限列表中加可以操作的具体属性：
              • GRANT UPDATE(stock_code, stock_price) ON stock TO brown;
              • 只能操作stock_code, stock_price 属性
          • 移除权限（REVOKE）
            • 大体跟GRANT写法类似
            • 更加根本，删除用户：DROP USER 'caixukun'@'localhost';
          • 更新缓存（FLUSH PRIVILEGES）
            • 防止数据库没反应过来

          约束

          约束
          描述
          关键字
          非空约束
          限制字段数据不能为空 NULL
          NOT NULL
          唯一约束
          保证该字段的所有数据不重复，可用在身份证号、用户名等
          UNIQUE
          主键约束
          主键是一行数据的唯一标识，要求非空且唯一
          PRIMARY KEY
          默认约束
          保存数据时，若未指定该字段的值，则用默认值
          DEFAULT
          检查约束
          保证字段值满足某条件
          CHECK
          外键约束
          建立两张表间的连接，保证数据的一致性和完整性
          FOREIGN KEY
          自增
          整型数据自动增长，可用在 id 等
          AUTO_INCREMENT
          在建表或改属性时，在条目后面加上对应关键词就行。

          外键约束

          • 建立表与表之间的关系，确保引用完整性
          • 例
            • 主表：部门信息
            • 从表：员工信息，其中一个属性是部门，需要引用部门的信息。这个属性必须填主表上主键有的项
          • 从表插入属性要检查主表主键是否存在
          • 主表不能随便删改
          级联
          外键里最凶残的功能。如果你不想让数据库一直报错拦着你删数据，你可以开启“殉情模式”。
          • ON DELETE CASCADE：
            • 你删了“技术部”？
            • 数据库甚至不问你，直接把 employee 表里所有属于技术部的人全杀光！
            • 后果： 这是一个灭门惨案的开关。手抖删错一行主表，从表几万条数据瞬间蒸发，哭都没地方哭！

          DQL多表查询

          多表关系
          • 一对多/多对一
            • 多的一方建立外键，指向另一方主键
          • 多对多
            • 建立中间表，至少包含两个外键，分别关联两表的主键
            • 案例：
              • 一个 学生 可以选 多门课。
              • 一门 课 也可以被 多个学生 选。
                1. 建一张 Student 表。
                1. 建一张 Course 表。
                1. 再建一张 Student_Course_Relation 表（中间表/关联表）！
              • 中间表里存啥？ 就存 student_id 和 course_id。
                • 一行记录表示：“张三 选了 数据库原理”。
                • 另一行记录表示：“李四 也选了 数据库原理”。
          • 一对一
            • 多用于单表拆分，基础字段一张表，详情字段一张表，提升性能，隔离隐私
            • 外键建在哪边都行，关联另一边的主键，但是外键要加上 UNIQUE（唯一） 约束！
          多表查询
          • 实际上是求多张表的笛卡尔积，强制两两匹配
          • 需要消除冗余
            • WHERE + 条件：SELECT * FROM emp, dept WHERE emp.dept_id = dept.id;
              • 老标准
            • 连接查询
              • 内连接
                • 查询集合A，B交集的数据
                • SELECT * FROM emp e [INNER] JOIN dept d ON e.dept_id = d.id;
              • 外连接
                • 查询左表/右表所有数据和交集部分，常用左外连接，因为两表顺序可以反过来
                • SELECT * FROM 表1 LEFT JOIN 表2 ON 条件...
                • 返回左表的所有条目和右表的部分条目，如果左表的条目在右表没有，则返回null
                例
                先建两个表，一个是 beauty（女神表），一个是 car（豪车表）。
                beauty 表（女神）：
                id
                name (名字)
                1
                冰冰
                2
                圆圆
                3
                凤姐
                car 表（豪车）：
                owner_id
                car_name (车名)
                1
                劳斯莱斯
                2
                法拉利
                4
                五菱宏光
                注：你看好了，凤姐（id 3）没车，五菱宏光（owner_id 4）的主人不在女神表里。

                1. 内连接 (INNER JOIN) —— 返回的是“门当户对”

                返回结果： 只有两边都能匹配上的数据。
                SQL语句：
                返回什么？
                name
                car_name
                冰冰
                劳斯莱斯
                圆圆
                法拉利
                • 凤姐呢？ 凤姐没车，滚蛋了。
                • 五菱宏光呢？ 没主人的破车，数据库理都不理。

                2. 左外连接 (LEFT JOIN) —— 返回的是“女神及其挂件”

                返回结果： 左表（beauty）的所有人，加上右表能匹配上的数据。匹配不上的，右边填 NULL。
                SQL语句：
                返回什么？
                name
                car_name
                冰冰
                劳斯莱斯
                圆圆
                法拉利
                凤姐
                NULL
                • 凤姐怎么出来了？ 因为她是左表的人，她是主子。虽然她没车，但数据库得给她留个位置，没车就给她分配个 NULL（空气）。
                • 五菱宏光呢？ 依然没戏，因为它在右表，没人领它，它就得滚。

                3. 右外连接 (RIGHT JOIN) —— 返回的是“名车博览会”

                返回结果： 右表（car）的所有车，加上左表能匹配上的主人。匹配不上的，左边填 NULL。
                SQL语句：
                返回什么？
                name
                car_name
                冰冰
                劳斯莱斯
                圆圆
                法拉利
                NULL
                五菱宏光
                • 五菱宏光怎么出来了？ 因为它是右表的，主子必须全部露脸。虽然它没主人，但数据库会在主人那一栏给它写个 NULL。
                • 凤姐呢？ 凤姐没车，在这种“名车博览会”的逻辑下，没车的女人连进门扫码的资格都没有！
              • 自连接
                • 自连接可以是内连接也可以是外连接
                • 解决的就是那种“老子表里某个人是我表里另一个人他爹”这种狗屁倒灶的层级关系
                • 一张表拆成两张虚表 + 起两个不一样的外号 + 按逻辑连起来
                  • 例
                  有一张员工表 emp：
                  id
                  name (员工名)
                  manager_id (领导的ID)
                  1
                  老王 (大BOSS)
                  NULL
                  2
                  张三
                  1
                  3
                  李四
                  1
                  4
                  王五
                  2
                  查询谁是谁的领导。
                  返回结果：
                  员工
                  领导
                  张三
                  老王
                  李四
                  老王
                  王五
                  张三
                  • 老王因为是顶级BOSS，他没有领导（manager_id是NULL），所以在 INNER JOIN 下，老王直接被踢出名单了。你要是想把老王也查出来，就得用 LEFT JOIN！
              • 联合查询
                • 合并多次查询结果形成新表。
                • 要求行属性一致，列数相等
                • UNION：删掉重复项
                • UNION ALL：直接拼合
              • 子查询（嵌套查询）
                • SQL语句中嵌套 SELECT 语句称为嵌套查询或子查询.
                  1. 子查询外部的语句可以是 INSERT、UPDATE、DELETE、SELECT 等.
                  1. 按子查询的结果分类:
                  ① 标量子查询: 子查询的结果是一个值.
                  ② 列子查询: 子查询结果为一列.
                  ③ 行子查询: 子查询结果为一行.
                  ④ 表子查询: 子查询结果为多行多列的表.
                  1. 按子查询的位置分类:
                  ① WHERE 之后.
                  ② FROM 之后.
                  ③ SELECT 之后.
              • 存在判定EXIST()
                • 可以替换掉子查询操作，性能更优
                • 子查询：以“结果集”为中心，把表作为单位查询
                • 存在判定：以“逻辑判定”为中心，把条目作为单位查询
                  • 例
                  在学生表 "students" 和修课表 "enrollment" 中进行如下查询:
                  (1) 查询至少修了一门课的学生的信息.
                  (2) 查询没有修编号 "21003001" 的课程的学生的信息.

          视图

          • 虚拟的表，数据存在，但不是真实存在库里的表，实际上是一个动态生成的查询结果

          增删改查

          • 创建
            • OR REPLACE：要是视图已经存在了，数据库不会给你报错，而是覆盖
          • 查询: 同查询数据表.
            • 修改.
                • 或
            • 删除.
              • 删视图不会影响原始数据

            检查选项

            • WITH ... CHECK OPTION ：过滤网
              • 检查更改的每一行是否符合视图定义
                • 对视图进行修改的时候，如果修改的项不符合视图的条件，则报错
                • 直接对源表进行修改，不生效
            • 两种选项
              • CASCADED 级联（默认）
                • 逻辑： 如果视图 B 是基于视图 A 建的，而视图 B 加了 WITH CASCADED CHECK OPTION。
                • 连坐： 当你往 B 里塞数据时，它不仅要检查 B 的条件，还会强行检查 A 的条件，不管 A 当初建的时候有没有加检查选项！
              • LOCAL 本地
                • 如果只有B加了检查选项，只会检查B，不会检查A

            视图的更新

            • 只有当视图的条目和基础表中的条目一一对应才能改，不然数据库不知道要改什么
            • 如果包含下面这些项之一都不能更新：
              • 聚合函数或窗口函数, 如 SUM、MIN、MAX、COUNT.
              • DISTINCT.
              • GROUP BY.
              • HAVING.
              • UNION 或 UNION ALL.
            • 能更新的： SELECT * FROM table WHERE ...（原封不动，只是加了过滤）。

            视图的优缺点

            • 优点
              • 简化查询语句
              • 安全
              • 数据独立性
              • 提高编程效率
              • 存储占用小
            • 确定
              • 引用视图花时间
              • 可能不被直接更新（LOCAL）

            其他存储对象

            • 存储过程
              • 存放在数据库中的完成特定功能的SQL语句集
            • 存储函数
              • 返回计算结果，可以直接被SQL表达式调用
            • 触发器
              • 自动检测某表的改变
            • 事件
              • 定时任务
            • 游标
              • 用于遍历结果集，每次返回一行

            四、关系代数

            —— 选择 (Select)

            • 取行
            • 对应WHERE
            notion image

            π —— 投影 (Projection)

            • 取列
            • 对应SELECT
            notion image

            ——连接（Join）

              • 即原本条关系中，真实的n条一一对应的关系
              • 先乱交，再筛选
            • θ 连接
              • 只要你的配对条件里用的是 >、<、>=、<=、!= 这些玩意儿，它都叫 Theta 连接。
            • 等值连接
              • 条件里必须且只能是等号（=）。
            • 自然连接
              • 两表中的相同属性对应的值也相等的条目会自动连接
              • 本质上是内连接
              • 你来个 NATURAL JOIN，数据库会默默在后台给你加上：WHERE A.id = B.id AND A.name = B.name AND A.status = B.status。两表属性连一起且自动去重
              • 省略join-condition的join成为自然连接
                • notion image
                notion image
            • 外连接
              • 左右连接
              • 全连接
                • 同时保留左右表的全部数据
                  • notion image

            除法

            • 核心逻辑： 给你两张表 A 和 B，查出 A 表里哪些货色“完全涵盖了” B 表里的所有要求。
            notion image
            notion image
            notion image

            五、关系型数据库理论

            确定性

            三大症状

            • 更新异常：漏
            • 删除异常：删多了
            • 插入异常：没主键

            决定因素

            如果属性 X 的每一个值，都对应属性 Y 里的唯一一个值，那 X 就叫 Determinant（决定因素）。

            函数依赖

            FD 的本质： 。也就是 Y 函数依赖于 X。
            • 自反律：你包含我，那我肯定能确定你
            • 扩充率：，那给两边都加个 Z，逻辑依然成立。
            • 传递率： 且 ，那 A 就能跨过 B 直接搞定 C

            闭包

            • 闭包（Closure）： 给你一个属性集 X，让你去推导在这个表里，X 到底能间接确定多少个属性。推出来的那个大集合就叫 。
              • 搜索
            • 超级键（Superkey）： 只要你的闭包能覆盖整张表的所有属性，你就是超级键。
            • 候选键（Candidate Key）： 如果你是超级键，而且你还没法再精简了（去掉任何一个字段就罩不住全场了），那你就是候选键。
            可以用图解法
            • 起点：，只有向外的箭头
            • 终点：，只有箭头指向它
            notion image
            • 任何候选键中必须含有的所有项，但不能有的任何项

            关系分解

            为了解决三大症状，将数据库拆小
            1. Lossless Join Decomposition (LLJD) —— “无损连接分解”
            它的意思是：你把表拆开后再连回去（Join），结果必须跟原来一模一样。
            • 数据库里的无损是指“没产生幻觉”。如果拆得不对，拼回来的时候会多出一些原本不存在的、莫名其妙的“幽灵行”（Wrong tuples）。这就叫有损。
              • Join的共同属性不能是多对多，需要是某个表的候选键。
            • 判别绝招（Theorem 5.1.3.1）： 如果你把一张表拆成 和 ，只要满足：
              • （公共属性是 的键）
              • 或者 （公共属性是 的键）
              • 只要满足其中一个，你这次拆迁就是“无损”的。
                  • notion image
            2. Dependency Preserving Decomposition (DPD) —— “保持依赖分解”
            这个是说：原来的那些规矩（函数依赖 FD），在拆完之后，是不是还能在这些小表里找得着？
            • 后果： 如果没保持依赖，你以后往表里塞数据的时候，数据库就没法自动帮你检查逻辑错误了。这简直就是给未来的程序 Bug 留了个后门。
            • 算法： XYGP 算法。就是让你在拆开的小表里反复求闭包，看看能不能把原表所有的 FD 都给推导出来。
                • notion image
             
            1. 拆表是为了治病（去冗余）。
            1. 无损连接（LLJD）是底线。如果你拆完连不回去了，那你就直接回炉重造吧，别tm当程序员了。
            1. 保持依赖（DPD）是理想。有些时候（比如为了达到 BCNF），我们不得不牺牲一点点依赖保持，这是权衡。

            范式

            1NF

            • 表中的每一个格子（属性），都必须是原子性 (Atomic) 的
            • 一个格子里只能放一个东西
            • 非主键必须依赖主键
            总结：多拆，尽量不要一对多

            2NF

            • 只有组合主键才要考虑是不是2NF，如果主键就一列，一定是2NF
            • 其他属性必须同时依赖主键的所有属性
              • 假设你建了一张选课成绩表，主键是 (学号, 课程号)。
              • 成绩 同时依赖 (学号, 课程号)。这没问题
              • 学生姓名 只依赖主键的一半 (学号)，把另一半 (课程号) 当空气。这不行。
              • 所以不符合2NF
            如果不符合2NF，会出现数据冗余。
            解决：
            • 将只依赖部分主键属性的分出去。
            notion image

            3NF

            • 只有两个属性的一定满足
            • 非主键之间也存在依赖，造成传递依赖
            解决：
            • 将非主键的依赖分成小表
            notion image

            BCNF

            • 所有的决定者都必须是候选键
            3NF 和 BCNF 的区别：
            • 3NF：非主键的小弟不能互相搞基（传递依赖）。
            • BCNF：哪怕你是主键的一部分，只要你敢决定别人，你就必须是候选键！ 
            notion image

            算法

            LLJD-BCNF（保持无损连接的 BCNF 分解）

            它的Input和Output写得装模作样的，其实就干一件事：暴力拆迁。
            • Input（原料）： 一张可能充满病毒（非 BCNF）的大表 R，和一堆规则 F。
            • Process（屠宰）：
                1. 检查这张表是不是 BCNF？
                1. 如果是，收工。
                1. 如果不是（比如发现 X→Y 这个二五仔），那就一刀切下去！把表拆成两半。
                1. 对拆出来的两半，重复步骤 1。直到所有的表都干净为止。
            • Output（成品）： 一堆小表 D，每一张都必须是 BCNF，而且拼起来还能还原。
            notion image

            Cover覆盖

            • F 说：只要你有钱，就能买车；只要有车，就能载妹。
            • G 说：只要你有钱，就能载妹。
            • 虽然 F 没直接说有钱能载妹，但通过 F 的逻辑能推导出 G。所以 F 覆盖了 G。

            等价

            • F 能推导出 G 的所有屁话。
            • G 也能推导出 F 的所有废话。
            • FG等价

            最小覆盖

            • 能够覆盖原fd
            • fd一一对应
            • 不要有多余的语句
              • 如果一条规矩删了，剩下的规矩还是能推导出它，那这条规矩就是多余的废话。
            • 左边不准带拖油瓶 (No extraneous)： 如果 AB→C，而老子发现光靠 A→C 就够了，那 B 就没用。
            notion image

            LLJD-DPD-3NF

            • LLJD (无损连接)： 拼回去的时候别给我多出一块肉，也别少个腰子。
            • DPD (依赖保持)： 以前的帮规（函数依赖）在新表里还得管用，别拆完之后没人守规矩了。
            • 3NF (第三范式)： 别有那些小弟勾搭小弟的破事（传递依赖）。
            1. 去废话： 先把函数依赖变成
            1. 拉小圈子： 对于 Fmin 里的每一条规矩 X→Y，直接建一张新表，把 X 和 Y 关在一起。
            1. 找老大： 看看这些新表里，有没有哪张表包含了原表的老大（候选键 CK）？
              1. 如果有，恭喜，你已经完事了。
              2. 如果没有，硬塞一个！ 专门建一张只包含候选键的表。
            1. 删多余： 如果一张小表是另一张表的“子集”，直接把它踢了。

            ER图

            • 矩形（方块）： 实体（Entity）。就是表里的“主角”
            • 椭圆（圆圈）： 属性（Attribute）。就是主角身上的“零件”
            • 菱形： 关系（Relationship）。就是主角们是怎么“勾搭”在一起的
            notion image

            多对多/三元关系

            • 要R表中转，其他的分别建表

            二元关系

            • 方块 E 和方块 F 通过 R 勾搭。
            • x 和 y 是基数（Cardinality），表示一个人能勾搭几个。
            1. 一对多： 众多的“小弟”兜里揣着“大哥”的身份证（1端主键做n端外键）。
            1. 一对一： 别让表里出现太多空位（NULL），谁必须参与就让谁带着对方的 ID。
            1. 多对多： 别瞎折腾，直接建个“案发现场”表（中介表），把双方的 ID 都拽过来。
             
             

            孩子复习不完了……就这样吧

             
            😀
            这里写文章的前言： 一个简单的开头,简述这篇文章讨论的问题、目标、人物、背景是什么？并简述你给出的答案。
            可以说说你的故事：阻碍、努力、结果成果，意外与转折。
             
            ]]>                         <![CDATA[计算机系统3笔记]]> http://richardliuda.top/article/CS3 http://richardliuda.top/article/CS3 Sun, 11 Jan 2026 00:00:00 GMT
            ⚙
            Fork from Hytidel. Show respect!

            第一章概要

            概念

            • 性能衡量
              • 响应时间：计算机完成某任务的时间
              • 吞吐率：单位时间内完成的任务数
              • 性能： 1 / 执行时间

            计算

            • CPU时间
                • =CPU时钟周期数×时钟周期时间
                =CPU时钟周期数/时钟频率
                =指令数 × CPI × 时钟周期时间
            💡
            CPI（每条指令的时钟周期数）：由CPU硬件决定
            • 加权平均CPI——综合效率指标
              • 功耗
               

              第二章MIPS汇编

              四大基本原则（面向流水线的ISA设计）

              • 简单源于规整
                • 算术运算总是有三个操作数
              • 越小越快
                • MIPS只有32个寄存器
              • 加速经常性事件
                • 立即数操作
              • 优秀的设计需要折中
                • 为了保持指令长度一致（32位），MIPS采用了多种指令格式

              寄存器约定

              寄存器名
              寄存器编号
              用途
              是否调用者保存
              $zero
              0
              常数 0
              不可重写
              $v0, $v1
              2, 3
              返回值
              否
              $a0 ~ $a3
              4 ~ 7
              函数传参的前 4 个参数
              否
              $t0 ~ $t7
              8 ~ 15
              临时变量
              否
              $s0 ~ $s7
              16 ~ 23
              保存参数
              是
              $t8, $t9
              24, 25
              临时变量
              否
              $gp
              28
              Global Pointer, 静态数据的全局指针
              是
              $sp
              29
              Stack Pointer, 堆栈指针
              是
              $fp
              30
              Frame Pointer, 帧指针, 保存过程帧的第一个字
              是
              $ra
              31
              Return Address, 返回地址
              是

              汇编指令

              算术运算

              • 加减
              • 逻辑运算
                • and：按位与，将数据的某些位保留下来
                • or：按位或，将某些位强行变1
                • xor：按位异或
                  • 与1异或：取反
                  • 与自己异或：为0，可判断两数是否相等，也可以快速清零
                • nor：按位或非，先or再取反
                  • 实现单独的取反功能
                      • nor $t0, $t1, $zero

              内存操作

              • 读写
                • lw/lb
                  • $rt = $rs 里的值 + offset（偏移量）
                • sw/sb
                  • 把 $rt 的值存到地址 $rs + offset 的地方
              • 寻址
                • 字节寻址：连续读数，地址+4字节
                • 内存对齐：w必须是4的倍数，h必须是2的倍数
                • 大端：高位字节低地址，从左往右写（MIPS默认）
                • 小端：低位字节低地址，从右往左写，倒着来
              💡
              寄存器的值要跟内存里的值进行操作时，需要先读内存加载到寄存器再操作

              跳转指令

              • beq：$rs，$rt相等跳转
              • bne：不相等跳转
              • j：无条件跳转
                • target为26位，可在256MB范围内跳转
              • jal：函数调用专用跳转
                • 将下一条指令的地址（pc+4）塞进$ra中，方便跳回来
              • jr：R型指令，调到$rs里面存的地址中
              💡
              if写法：
              for写法：

              32bit立即数

              • 两步走
                • 加载高16位：先用 lui (Load Upper Immediate) 指令，把立即数的高 16 位塞进目标寄存器，这时候低 16 位会自动补零。
                • 合并低16位：然后再用 ori (Or Immediate) 指令，把剩下的低 16 位常数“或”进去，这才凑成一个完整的 32 位立即数。

              伪指令

              • 伪指令就是汇编指令的变种。除了这些玩意儿，大部分汇编指令跟机器指令都是一对一的

              指令后缀

              后缀
              他妈的含义
              典型指令
              老子的白话解释
              i
              Immediate (立即数)
              addi, ori, lui
              指令里自带一个 16 位的常数，不用去别处抠数据，自给自足。
              u
              Unsigned (无符号/不报溢出)
              addu, lbu, sltu
              1. 算术里指**“爆了也别报警”；2. 读内存/比较里指“把数据当成纯正数”**，高位补 0。
              b
              Byte (字节)
              lb, sb
              每次只吞吐 8 位 数据。胃口小，专门吃零碎玩意儿。
              h
              Half-word (半字)
              lh, sh
              每次吞吐 16 位 数据。比上不足比下有余的货。
              w
              Word (字)
              lw, sw
              每次吞吐 32 位 数据。MIPS 的标准套餐，一次吃一满口。
              v
              Variable (变量/动态)
              sllv, srav
              移位多少位不是定死的，得看寄存器里的脸色。
              a
              Arithmetic (算术/带符号)
              sra, srav
              专门用于右移，高位补符号位。为了保证负数移位完还是负数。
              l
              Link (保存返回地址)
              jal, bal
              跳走之前，先把下一条指令地址存进 $ra。记着回家的路。
              r
              Register (寄存器)
              jr
              跳转地址不是写死的，是存放在寄存器里的。
              .s
              Single (单精度浮点)
              add.s, lwc1
              搞 32 位浮点数算的。算这种数的 CPU 单元都他妈是另开的小灶（协处理器）。
              .d
              Double (双精度浮点)
              add.d, ldc1
              搞 64 位浮点数算的。精度更高，也更吃资源。

              指令分类

              • R型是干苦力的，算数的。
                  • notion image
                • op (6 bits)：操作码。在 R-型指令里，这 6 位全是他妈的 0！
                • rs (5 bits)：第一个源寄存器。
                • rt (5 bits)：第二个源寄存器。
                • rd (5 bits)：Destination (目的地)！也就是算完的结果往哪儿塞。
                • shamt (5 bits)：全称是 Shift Amount（移位量）。
                  • 只有在做 sll（左移）或者 srl（右移）的时候才用。
                  • 普通的加减法，这里就是纯种的 0，没它什么屁事儿。
                • funct (6 bits)：功能码。这才是决定“干什么活”的关键！
                  • 同样是 op=0，如果这里是 32 (二进制 100000)，那就是 add。
                  • 如果是别的数，可能就是减法、乘法或者逻辑运算。
                  notion image
              • I型是灵活的，搞立即数、读写内存、条件判断。
                • 将R-型指令中的rd、shamt、funct字段合并为constant or address字段
                  • notion image
                • op (6位)：这次绝对不是 0 了！每一个 I-型指令都有自己唯一的编号（比如 addi 是 8，lw 是 35）。CPU 一看前 6 位，就知道这活儿是加法、读内存还是跳槽。
                • rs (5位)：还是老样子，源寄存器。
                • rt (5位)：这是最他妈坑爹的地方！
                  • 在 addi 或者 lw（读内存）里，它是目的地（结果存这儿）。
                  • 在 beq（相等跳转）或者 sw（存内存）里，它是第二个源。
                  • 这 rt 就是个“两面派”，一会儿当爹一会儿当儿子，你得看前面的 op 才知道它是个什么货色。
                • immediate (16位)：这就是传说中的立即数！
                  • 它占据了指令整整一半的长度（16 位）。
                  • 它可以存一个常数，或者一个内存地址的偏移量。
                  • 范围：因为它带符号，所以能存 32768 到 32767 之间的数。你要是想存个 100 万？去你妈的，存不下！
              • J型是到处飞的。

              寻址

              寻址模式
              英文全称
              核心逻辑
              典型指令
              解释
              1. 立即数寻址
              Immediate Addressing
              数据就在指令里揣着
              addi, ori
              兜里揣着现钱，想花直接掏，不用去银行。
              2. 寄存器寻址
              Register Addressing
              数据在寄存器里存着
              add, sub
              钱在碗里，直接伸手抓，快得一批。
              3. 基址寻址
              Base Addressing
              寄存器地址 + 偏移量
              lw, sw
              按图索骥。拿着仓库地址（寄存器）再数几个坑位（偏移量）去找货。
              4. PC相对寻址
              PC-Relative Addressing
              当前行号 + 偏移量
              beq, bne
              就在附近。从你站的地方往前或往后跑几步。
              5. 伪直接寻址
              Pseudodirect Addressing
              指令里存了大半个地址
              j, jal
              瞬间移动。虽然不能满地图乱飞，但在同一个大区里想去哪去哪。
              jr是R型指令，跳转范围是32位。
              PC相对寻址只有16位，可以转化为伪直接寻址拓展为26位。

              第三章运算

              整数

              加

              • 溢出
                • 正正相加，符号位1溢出
                • 负负相加，符号位0溢出
                • 正负相加，不溢出
              • 全加器
                  • notion image
                • 输入：A（加数1）、B（加数2）、Cin（上一位传过来的进位）。
                • 输出：S（这一位的和）、Co（给下一位的进位）。

              减

              • 溢出
                • 正 + 正 = 负？（炸了）
                • 负 + 负 = 正？（炸了）
                • 正 - 负（即正+正）= 负？（炸了）
                • 负 - 正（即负+负）= 正？（炸了）
                • MIPS中，指令 add 检测溢出，addu 忽略溢出

              乘

              notion image
              notion image
              这张图最精妙的地方，就是下面那个 64 位的 Product 寄存器。
              • 开局状态：
                • 左边 32 位：全是 0（准备用来存加法的结果）。
                • 右边 32 位：塞进去的是 Multiplier (乘数)。
              • 运算过程：
                  1. 看最右边那一位（乘数的最低位）。
                  1. 如果是 1，就把 32 位被乘数 加到 64 位寄存器的左半边。
                  1. 如果是 0，屁也不加。
                  1. 关键动作来了：整个 64 位寄存器一起向右移一位！
                • 逻辑：效果是一样的！你把数往左挪，和你把底下的纸往右抽，相对位移他妈的一模一样。
                • 骚点：随着计算的进行，右边的乘数被一位位挤出去了（因为不需要了），而左边算出来的乘积正好一位位占领了右边的坑位。
                • 最后结果：等 32 次循环跑完，原来的乘数被彻底“扫地出门”，整个 64 位寄存器里装的全是算好的乘积。

              除

              notion image
              notion image
              • 余数的符号必须跟被除数（Dividend）保持一致！
                • 7÷(−2)=−3……1 （被除数 7 是正，余数 1 就是正）
                • (−7)÷2=−3……(−1)（被除数 -7 是负，余数 -1 必须是负）
                • (−7)÷(−2)=3……(−1)（被除数 -7 是负，余数还是 -1）

              浮点数

              加减法

              1. 对阶
                  • 小阶向大阶看齐，向右移位直到指数相同
                  • 丢精度
              1. 尾数加减
              1. 规格化为IEEE格式
              1. 舍入
                  • 四舍五入，是5就保偶数
              浮点加法器
              浮点加法器

              乘法

              1. 指数相加
              1. 尾数相乘
                  • 硬乘
              1. 规格化
              1. 舍入
              1. 确定符号
              例子
              notion image

              第四章处理器

              • 7/11/32/54/133
              • 不含流水线的处理器
              • ALU
              • 流水线性能计算
              • 流水线冒险
              • 分支冒险气泡插入
              • 多发射
              • 延迟槽，分支预测，分支检测前移

              重点的图

              notion image
              notion image
              notion image
              notion image
              notion image
              notion image
              notion image
               
               
               
               

              指令的执行

              • 取指令
                • PC从存储单元取指
                • 根据寄存器编号从寄存器中读取内容
              • 后续操作与指令类型相关
                • 除跳转指令，其他都要经过ALU
                  • 计算
                  • 方寸地址
                  • 分支条件
                • 存储访问指令读写内存
                • 将ALU运算结果写入寄存器
              • PC跳到下一条指令

              流水图

              notion image
              notion image
              1. 寄存器写入口的 MUX (RegDest)：
                  • 决定是把结果写进 rt 寄存器还是 rd 寄存器。
              1. ALU 输入端的 MUX (ALUSrc)：
                  • 0 代表选寄存器里的值，1 代表选指令里的“立即数”（就是那根从 Instruction 连出来的线）。
              1. Data Memory 后面的 MUX (MemtoReg)：
                  • 0 代表把 ALU 算出来的结果写回寄存器，1 代表把从内存捞出来的宝贝写回寄存器。
              1. PC 顶上的那个 MUX (PCSrc)：
                  • 最牛逼的一个：它由 Branch 信号 和 ALU 的 Zero 信号 共同控制（看到那个 AND 门 没？）。
                  • 只有当这是一条分支指令（Branch=1）且两个数相等（Zero=1）时，才让 PC 跳到新的地址。

              数据通路

              部件：
              1. 算术逻辑单元 (ALU)：这就是工厂里的核心加工机。不管是加减乘除还是比大小，东西扔进去，出来就是结果。这是干活最猛的地方。
              1. 寄存器堆 (Register File)：这是工人的随身工具包。常用的数据得放在这儿，伸手就能拿，速度贼快。
              1. 存储器 (Memory)：这是大仓库。指令仓库（Instruction Memory）放的是“施工图纸”，数据仓库（Data Memory）放的是“原材料”和“成品”。
              1. 程序计数器 (PC)：这是那个看大门的。他手里拿着个名单，决定下一秒该去哪儿掏指令。
              1. 多路复选器 (MUX)：这是路口的红绿灯和分叉路。不同指令的数据来源不同时，需用复选器。
              1. 各种连接线 (Buses/Wires)：这就是传送带。数据（电信号）顺着这些线从寄存器跑到 ALU，再从 ALU 跑到仓库。
              信号：
              • 读写使能类 (RegWrite, MemRead, MemWrite)：决定谁能动，谁不能动。
              • 路径选择类 (RegDst, ALUSrc, MemtoReg, Branch)：决定数据走哪条路。
              详细

              1. RegDst (寄存器目标位)

              • 干嘛的：决定谁是“接盘侠”。
              • 逻辑：
                • 0：把结果写进指令的 rt 段（[20:16] 位）。（通常是 Load 指令）
                • 1：把结果写进指令的 rd 段（[15:11] 位）。（通常是 R 型算术指令）

              2. RegWrite (寄存器写使能)

              • 干嘛的：终极“准生证”。
              • 逻辑：
                • 1：允许把数据写进寄存器。
                • 0：别碰！哪怕算出来的结果再香，也不准存。
              • 这就是个保险栓。如果不该写的时候你开了 1，你那寄存器里存的宝贝分分钟变成一坨不可名状的屎。

              3. ALUSrc (ALU 源操作数选择)

              • 干嘛的：选“下酒菜”。
              • 逻辑：
                • 0：选寄存器里的第二个值（Read data 2）。（R 型指令干架用）
                • 1：选指令里的那 16 位立即数（经过符号扩展后的）。（addi, lw, sw 这种带数字的用）

              4. Branch (分支控制)

              • 干嘛的：决定要不要“反复横跳”。
              • 逻辑：
                • 1：这是一条分支指令（比如 beq），如果此时 ALU 算出来两个数相等（Zero=1），那就跳！
                • 0：给老子老老实实走下一条路。

              5. MemRead (存储器读使能)

              • 干嘛的：翻大仓库。
              • 逻辑：
                • 1：把数据存储器（Data Memory）里的东西掏出来。
                • 0：仓库大门锁死，不准看。

              6. MemWrite (存储器写使能)

              • 干嘛的：往仓库倒垃圾。
              • 逻辑：
                • 1：把寄存器里的东西写进数据存储器。
                • 0：不准往仓库里乱塞东西。

              7. MemtoReg (存储器到寄存器选择)

              • 干嘛的：决定谁才是“真成果”。
              • 逻辑：
                • 0：把 ALU 算出来的结果写回寄存器。
                • 1：把从存储器里捞出来的东西写回寄存器。

              单周期数据通路

              notion image

              控制单元

              • ALU的控制信号
              ALU的控制信号
              功能 F (运算操作)
              0000
              and
              0001
              or
              0010
              add
              0110
              sub
              0111
              slt
              1100
              nor
              op
              ALU op
              operation
              funct
              ALU function
              ALU control
              lw
              00
              load word
              xxxxxx
              add
              0010
              sw
              00
              store word
              xxxxxx
              add
              0010
              beq
              01
              branch equal
              xxxxxx
              subtract
              0110
              R型指令
              10
              add
              100000
              add
              0010
              R型指令
              10
              subtract
              100010
              subtract
              0110
              R型指令
              10
              and
              100100
              and
              0000
              R型指令
              10
              or
              100101
              or
              0001
              R型指令
              10
              slt
              101010
              slt
              0111
              指令
              RegDst
              ALUSrc
              Mem-toReg
              Reg-Write
              Mem-Read
              Mem-Write
              Branch
              ALUOp1
              ALUOp2
              R型指令
              1
              0
              0
              1
              0
              0
              0
              1
              0
              lw
              0
              1
              1
              1
              1
              0
              0
              0
              0
              sw
              $x$
              1
              $x$
              0
              0
              1
              0
              0
              0
              beq
              $x$
              0
              $x$
              0
              0
              0
              1
              0
              1

              流水线

              五级流水线

              1. IF：从内存取指
              1. ID：译码，读寄存器
              1. EX：执行运算
              1. MEM：访存
              1. WB：回写到寄存器

              流水线加速比

              理想为4-5，但达不到
              因为
              • 各级不等长
              • 存在数据冒险

              冒险

              1. 结构冒险：两个工人都想抢同一个扳手，打起来了，流水线得停。
                  • 解决：把内存拆成“指令内存”和“数据内存”
              1. 数据冒险：后面的人要等前面的人算出结果才能动，停顿 (Stall) 了。
                  • 解决：
                    • 塞气泡
                        • notion image
                    • 旁路/前推
                        • notion image
                        避免访存，提高效率。
                        但是取数-使用型冒险不能用前推解决：
                        notion image
                        前推只能推一步，如果涉及到访存，只能通过塞气泡或者指令调度（将无关紧要的指令插进来执行）来解决。
              1. 控制冒险：需根据前面某条指令的结果才能确定分支的执行。
                  • 解决：
                    • ID（译码）阶段加入硬件比较寄存器和计算分支地址，在这一步就决定要不要跳转。
                    • 分支预测：默认不跳转，直接取紧跟着的指令
                      • 向后的分支：猜发生，直接跳
                      • 向前的分支：猜不发生，直接执行下一条

              流水线数据通路

              notion image

              流水线寄存器

              notion image
              • 作用：数据隔断，按照时钟周期执行，确保数据同步
              红圈里的名字，全是两级名字的组合（如 IF/ID）：
              • PC 寄存器：这是“发令枪”。每一秒钟它都指着下一条该死指令的地址。
              • IF/ID：存的是刚取出来的指令码和 PC+4 的地址。
              • ID/EX：这里面存的东西最杂！有从寄存器里掏出来的操作数，有符号扩展后的立即数，还有主控单元发出的控制信号。
              • EX/MEM：存的是 ALU 算出来的结果，以及要存入内存的数（如果是 sw 指令的话）。
              • MEM/WB：存的是从内存里捞出来的数，或者 ALU 的结果，等着最后写回寄存器。
              这些寄存器不仅是存数的，它们还在帮指令“传话”。指令每走一级，它的“身份证明”和“控制参数”都要跟着寄存器一起往下挪。这就是同步。

              带阻塞的流水线

              notion image
              解读

              1. 物理结构：那四根蓝色的“通天柱”

              这四根柱子（IF/ID, ID/EX, EX/MEM, MEM/WB）是时间的围墙。
              • 它们把整个 CPU 强行切成了五个房间（IF, ID, EX, MEM, WB）。
              • 怎么看？ 每一级房间只干自己的活，干完就把结果和指令的“档案袋”（那堆控制信号和编号）扔进柱子里。下一秒，下一级房间从柱子里捡起档案继续干。
              • 这就是“按劳分配，到点下班”。柱子就是为了保证每一级指令互不干扰，谁也别想抢跑。

              2. 处理矛盾：两个“大内高手”的博弈

              这是整张图最硬核的地方，专门对付“数据冒险”：
              • 前推单元 (Forwarding Unit)：它是“截胡专家”。
                • 它的逻辑：能不停车就不停车！只要后面的指令算出了结果，它就通过那些蓝色的“秘密通道”直接把数送到 ALU 门口。
              • 冒险检测单元 (Hazard Detection Unit)：它是“紧急刹车”。
                • 它的逻辑：有些数（比如 lw 拿的数）实在太慢，截胡都来不及，它就果断拉手刹（PCWrite=0），让后面的人原地罚站，顺便在流水线里吐个“肥皂泡（NOP）”。
              • 这就是“能私了就私了（前推），私了不了就报警（阻塞）”。

              3. 控制信号：三组“随身锦囊” (EX, M, WB)

              你得盯着那些从 Control 单元流出来的蓝虚线。
              • 怎么看？ 这些信号不是一次性用完的，它们像剥洋葱一样，每过一级柱子，就丢掉一层。
              • EX 在执行级用掉，M 在访存级用掉，WB 熬到最后写回级才用。
              • 这叫“带着锦囊上路”。指令跑到哪，规矩就跟到哪，谁也别想乱来。

              4. 整体节奏：被“最慢者”支配的恐惧

              • 怎么看？ 整个流水线的时钟周期，必须迁就那个最慢的房间（通常是 MEM 级读内存）。
              • 这就好比一个宿舍的人一起去食堂，只要有一个人在那儿磨叽拉稀（访存延迟），全宿舍的人都得在门口等着他！这就是流水线的代价：虽然吞吐量大了，但单条指令的耗时其实变长了。

              带冒险检测的流水线

              notion image
              • 主要目的：分支预测，尽量早跳转减少空转
              • 核心区别：
                • ID阶段直接比较寄存器中的两值是否相等，如果相等，Control直接发送IF.Flush信号，将下一条的控制指令清零，杀掉这条操作。
                • 在ID阶段同时预先算好跳转地址，如果满足跳转条件直接有地址可以跳转。
                • PC的值需要先经过一个Mux，决定下面的指令是否跳转。

              异常与中断

              来源

              • 异常：源于CPU内部事件
                • 无效指令，溢出，系统调用指令
              • 中断：源于外部IO控制器

              处理

              • MIPS的异常通常由协处理器CP0处理
                  1. 保存报错指令地址PC，存进寄存器EPC (Exception Program Counter)
                  1. 记录引发异常的原因到状态寄存器Cause
                  1. 强制跳到异常处理入口0x 8000 0180
              • 指令撤销
                • IF-Flush 与分支预测的一样。把刚取出来的指令变成 0。
                • ID-Flush 如果 EX 级的指令出事了，处于 ID 级的指令也变0。
                • EX-Flush 同理，如果是在更后面出事，EX 级的指令也变0。
                • 假设不在 MEM/WB 发生异常。其实生活里很常见，如页表失效。

              第五章缓存

              Cache

              直接映射

              • 每个存储器地址对应一个唯一的Cache地址
              notion image
              • MIPS按字对齐，只查找4的倍数，Byte Offset没用，用来找字里面的字节
              notion image
              • [11,2]用来计算index（）
              • 只有index和tag都对上且valid=1才算命中

              FastMATH

              notion image
              • 将横轴拉长

              Cache的性能

              相联

              notion image
              将原本匹配的块编成组，组内有多少个块就多少个比较器，匹配上其中一个就行
              • 全相联
                • 一个块可被放在任何地方
                • 需要查找Cache的所有项
                • 每个项都要一个比较器
              • 多路组相联
                • 每个组包含n块
                • 块可以被放在组内的任何一块
                • 只需要n个比较器
                    • notion image
              • 增加相联度，可降低缺失率，但收益递减
              notion image
              替换策略
              • 优先存没有信息的块
              • LRU算法，选择最长时间没使用的替换掉
                • 电路复杂，超过四路难以实现
                • 目前主流是近似LRU

              多级Cache

              Cache缺失原因
              • 强制缺失：第一次访问
              • 容量缺失：Cache太小不足以容纳所有块引起的缺失
                • 例：一个被替换的块又被访问
              • 冲突缺失：映射规则约束太死，导致数据发生资源争夺
                • 全相联不会有这个问题
              设计变化
              对缺失率的影响
              可能对性能的负面影响
              增加 cache 容量
              减少容量缺失，降低缺失率
              增加访问时间
              提高相联度
              减少冲突缺失，降低缺失率
              增加访问时间
              增加块容量
              因空间局部性，对宽范围内变化的块大小都能降低缺失率
              ① 增加缺失代价 ② 块过大时增加缺失率
              为了在这些缺陷中取得较优解，对Cache进行分级
              • L1-Cache：直连CPU，容量小速度快
                • 追求最小化命中时间
              • L2-Cache：处理L1的miss，容量比L1大但速度慢
                • 追求低缺失率，避免访问主存
              • L2的miss交给主存

              虚拟存储器

              notion image
              • 地址映射：将虚页号映射到物理页号
              • 若缺页，需从硬盘取回，消耗数百万时钟周期
              • 降低缺页率：
                • 虚页使用全相联：绝对不能miss
                • 替换算法智能化，最大程度减少miss发生

              页表（PTE）

              notion image
              Virtual Address (32位虚拟地址)
              • 高 20 位 是 Virtual Page Number (VPN)。
              • 低 12 位 是 Page Offset。这代表一页的大小是 =4KB。
               Valid 位（有效位）
              • 1：在内存，直接访问
              • 0：在硬盘，需要访问硬盘
               
              • 虚拟内存好处：碎片化管理。
              • 在LRU算法（近似）中，PTE的引用位被周期性清零。只有在某页被访问时，引用位才置1。
              • 每个页表只有一个1bit的引用位。
              • 从磁盘向内存写入数据通常成块写入，不单独写地址
                • 采取回写（Write-back）策略，更新的值等在页表中被替换了才写回硬盘。

              快表（TLB）

              • 页表的缺陷：地址映射需要额外一次访存
              • 解决：现代CPU 在自己身体里（MMU 内部）搞了一个极小、极快的缓存，专门用来存最近用过的页表项，这就是TLB。
              • 就是页表的缓存，快表miss了就去读页表
              notion image
              • Valid (有效位)：这行映射是不是真的。
              • Dirty (脏位)：这页数据被没被改过（回写磁盘时用）。
              • Ref (引用位)：用来决定谁该滚出内存。
              • Tag：用来匹配虚拟页号的标识。
              1. 第一步：看 TLB。中了？直接拿物理地址去 Cache 找数据。
              1. 第二步：TLB 没中，看页表 (Page Table)。
                  • 页表里有？（Valid=1），赶紧把这一项同步到 TLB 里，然后去内存拿货。
                  • 页表里也没有？（Valid=0），缺页中断！ 唤醒操作系统，从硬盘里搬进内存，改页表（如果dirty位为1,则先写回），重新执行指令。
              ]]>                             <![CDATA[壁纸分享]]> http://richardliuda.top/article/wallpaper http://richardliuda.top/article/wallpaper Sat, 14 Jun 2025 00:00:00 GMT
              ⚠️
              注：图片来源均为网上收集，鼠鼠我只是个搬运工，请勿商用！ 另外，个别图片原图分辨率过低，故利用AI工具超了分辨率。 图片加载不出来的话，可以尝试科学上网，或者直接文末打包下载。 打包的图片体积较大，网页直接保存的体积会小一些。
              notion image
              notion image
              notion image
              notion image
              notion image
              notion image
              notion image
              notion image
              notion image
               
              打包下载：
              package.zip
              84342.4KB
               
              ]]>                             <![CDATA[Cherry Studio自用CSS]]> http://richardliuda.top/article/cherry_studio_css http://richardliuda.top/article/cherry_studio_css Sat, 24 May 2025 00:00:00 GMT
              纯自用的，属性可以根据自己喜好改。背景--background-image要用图床链接
              效果如图所示
              notion image
              notion image
               
              ]]>