diff --git a/README.md b/README.md
index d586386c7..759bb9fea 100644
--- a/README.md
+++ b/README.md
@@ -20,6 +20,10 @@
准备面试可以从
面试高频问题 开始，每个问题都链接到对应的章节。
|
+| 查看状态 | git status |
+| 加入暂存区 | git add |
+| 提交 | git commit -m "说明" |
+| 查看历史 | git log --oneline --graph |
+| 查看改动 | git diff（工作区与暂存区），git diff --staged（暂存区与最新提交） |
+| 撤销工作区的修改 | git restore |
+| 撤销 git add | git restore --staged |
+| 新建并切换分支 | git switch -c dev |
+| 切换分支 | git switch master |
+| 合并分支 | git merge dev |
+| 变基 | git rebase master |
+| 临时保存修改 | git stash，之后用 git stash pop 恢复 |
+| 撤销最近一次提交，保留修改 | git reset --soft HEAD~1 |
+| 回到某个提交，丢弃之后的修改 | git reset --hard |
+| 用一个新提交抵消某次提交 | git revert |
+| 拉取并合并远程分支 | git pull |
+| 推送 | git push origin dev |
+
+git restore 和 git switch 是 Git 2.23 加入的命令，分别承担了原来 git checkout 恢复文件和切换分支两种用途。需要注意的是，reset --hard 会丢弃未提交的修改；已经推送到远程的提交，应该用 revert 撤销，而不是 reset 后强制推送。
+
+比较详细的命令列表：http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf
## 参考资料
diff --git a/notes/HTTP.md b/notes/HTTP.md
index 578e53e52..1ade6a90d 100644
--- a/notes/HTTP.md
+++ b/notes/HTTP.md
@@ -36,9 +36,12 @@
* [多部分对象集合](#多部分对象集合)
* [虚拟主机](#虚拟主机)
* [通信数据转发](#通信数据转发)
+ * [WebSocket](#websocket)
+ * [跨域](#跨域)
* [六、HTTPS](#六https)
* [加密](#加密)
* [认证](#认证)
+ * [TLS 握手](#tls-握手)
* [完整性保护](#完整性保护)
* [HTTPS 的缺点](#https-的缺点)
* [七、HTTP/2.0](#七http20)
@@ -46,6 +49,7 @@
* [二进制分帧层](#二进制分帧层)
* [服务端推送](#服务端推送)
* [首部压缩](#首部压缩)
+ * [HTTP/3](#http3)
* [八、HTTP/1.1 新特性](#八http11-新特性)
* [九、GET 和 POST 比较](#九get-和-post-比较)
* [作用](#作用)
@@ -69,7 +73,7 @@
- 第一行是包含了请求方法、URL、协议版本；
- 接下来的多行都是请求首部 Header，每个首部都有一个首部名称，以及对应的值。
- 一个空行用来分隔首部和内容主体 Body
-- 最后是请求的内容主体
+- 最后是请求的内容主体，GET 请求通常没有主体，POST 请求的表单数据、JSON 放在这里
```http
GET http://www.example.com/ HTTP/1.1
@@ -84,7 +88,6 @@ Proxy-Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 xxx
-param1=1¶m2=2
```
响应报文结构：
@@ -218,7 +221,7 @@ DELETE /file.html HTTP/1.1
CONNECT www.example.com:443 HTTP/1.1
```
- {
- [Iterator 模式](https://openhome.cc/Gossip/DesignPattern/IteratorPattern.htm)
- [Java 8 系列之重新认识 HashMap](https://tech.meituan.com/java_hashmap.html)
- [What is difference between HashMap and Hashtable in Java?](http://javarevisited.blogspot.hk/2010/10/difference-between-hashmap-and.html)
-- [Java 集合之 HashMap](http://www.zhangchangle.com/2018/02/07/Java%E9%9B%86%E5%90%88%E4%B9%8BHashMap/)
- [The principle of ConcurrentHashMap analysis](http://www.programering.com/a/MDO3QDNwATM.html)
- [探索 ConcurrentHashMap 高并发性的实现机制](https://www.ibm.com/developerworks/cn/java/java-lo-concurrenthashmap/)
- [HashMap 相关面试题及其解答](https://www.jianshu.com/p/75adf47958a7)
diff --git "a/notes/Java \345\271\266\345\217\221.md" "b/notes/Java \345\271\266\345\217\221.md"
index 4bcfb2c07..d948c3101 100644
--- "a/notes/Java \345\271\266\345\217\221.md"
+++ "b/notes/Java \345\271\266\345\217\221.md"
@@ -21,6 +21,7 @@
* [ReentrantLock](#reentrantlock)
* [比较](#比较)
* [使用选择](#使用选择)
+ * [Java 中的锁](#java-中的锁)
* [五、线程之间的协作](#五线程之间的协作)
* [join()](#join)
* [wait() notify() notifyAll()](#wait-notify-notifyall)
@@ -39,6 +40,7 @@
* [Semaphore](#semaphore)
* [八、J.U.C - 其它组件](#八juc---其它组件)
* [FutureTask](#futuretask)
+ * [CompletableFuture](#completablefuture)
* [BlockingQueue](#blockingqueue)
* [ForkJoin](#forkjoin)
* [九、线程不安全示例](#九线程不安全示例)
@@ -121,7 +123,7 @@ public static void main(String[] args) throws ExecutionException, InterruptedExc
### 继承 Thread 类
-同样也是需要实现 run() 方法，因为 Thread 类也实现了 Runable 接口。
+同样也是需要实现 run() 方法，因为 Thread 类也实现了 Runnable 接口。
当调用 start() 方法启动一个线程时，虚拟机会将该线程放入就绪队列中等待被调度，当一个线程被调度时会执行该线程的 run() 方法。
@@ -155,7 +157,7 @@ Executor 管理多个异步任务的执行，而无需程序员显式地管理
主要有三种 Executor：
-- CachedThreadPool：一个任务创建一个线程；
+- CachedThreadPool：有空闲线程时复用，没有时为任务新建一个线程，线程空闲 60 秒后被回收；
- FixedThreadPool：所有任务只能使用固定大小的线程；
- SingleThreadExecutor：相当于大小为 1 的 FixedThreadPool。
@@ -290,7 +292,7 @@ public void run() {
### InterruptedException
-通过调用一个线程的 interrupt() 来中断该线程，如果该线程处于阻塞、限期等待或者无限期等待状态，那么就会抛出 InterruptedException，从而提前结束该线程。但是不能中断 I/O 阻塞和 synchronized 锁阻塞。
+通过调用一个线程的 interrupt() 来中断该线程，如果该线程正在 sleep()、wait()、join() 等方法中处于限期等待或者无限期等待状态，那么就会抛出 InterruptedException，从而提前结束该线程。但是不能中断传统 I/O 的阻塞和等待 synchronized 锁的阻塞（BLOCKED）。
对于以下代码，在 main() 中启动一个线程之后再中断它，由于线程中调用了 Thread.sleep() 方法，因此会抛出一个 InterruptedException，从而提前结束线程，不执行之后的语句。
@@ -364,7 +366,7 @@ Thread end
### Executor 的中断操作
-调用 Executor 的 shutdown() 方法会等待线程都执行完毕之后再关闭，但是如果调用的是 shutdownNow() 方法，则相当于调用每个线程的 interrupt() 方法。
+调用 Executor 的 shutdown() 方法后，线程池不再接受新任务，已经提交的任务会继续执行完，它本身不会阻塞等待，需要等待时调用 awaitTermination()；如果调用的是 shutdownNow() 方法，则相当于调用每个线程的 interrupt() 方法，并返回队列中还没有执行的任务。
以下使用 Lambda 创建线程，相当于创建了一个匿名内部线程。
@@ -590,7 +592,43 @@ synchronized 中的锁是非公平的，ReentrantLock 默认情况下也是非
### 使用选择
-除非需要使用 ReentrantLock 的高级功能，否则优先使用 synchronized。这是因为 synchronized 是 JVM 实现的一种锁机制，JVM 原生地支持它，而 ReentrantLock 不是所有的 JDK 版本都支持。并且使用 synchronized 不用担心没有释放锁而导致死锁问题，因为 JVM 会确保锁的释放。
+除非需要使用 ReentrantLock 的高级功能，否则优先使用 synchronized。这是因为 synchronized 是 JVM 实现的一种锁机制，JVM 原生地支持它，并且使用 synchronized 不用担心没有释放锁而导致死锁问题，因为 JVM 会确保锁的释放；ReentrantLock 则必须在 finally 中调用 unlock()。
+
+### Java 中的锁
+
+Java 中的锁可以从几个角度分类，同一把锁会同时属于多类，例如 ReentrantLock 默认是悲观、独占、可重入的非公平锁：
+
+| 分类 | 区别 | 例子 |
+| --- | --- | --- |
+| [悲观锁与乐观锁](#4-乐观锁与悲观锁) | 先加锁再访问；或者先访问，提交时再检查有没有冲突 | synchronized、ReentrantLock；AtomicInteger 的 CAS、StampedLock 的乐观读 |
+| 独占锁与共享锁 | 同一时刻只能有一个线程持有；或者可以有多个 | ReentrantLock、写锁；读锁、Semaphore |
+| [公平锁与非公平锁](#七juc---aqs) | 按申请的顺序获得锁；或者允许新来的线程插队 | new ReentrantLock(true)；synchronized、ReentrantLock 默认 |
+| 可重入锁 | 持有锁的线程可以再次获得同一把锁，不会被自己阻塞 | synchronized、ReentrantLock、ReentrantReadWriteLock |
+| [自旋锁](#自旋锁) | 获取失败时循环重试，而不是挂起线程 | synchronized 的自适应自旋、CAS 循环 |
+| [偏向锁、轻量级锁、重量级锁](#十二锁优化) | synchronized 在不同竞争程度下的实现 | synchronized |
+
+读多写少时，读和读之间不需要互斥，可以使用读写锁 ReentrantReadWriteLock：读锁是共享锁，多个线程可以同时持有；写锁是独占锁，持有写锁时其它线程既不能读也不能写。JDK 8 的 StampedLock 还提供乐观读，读之前不加锁，只记下一个版本号，读完再检查期间有没有写入，有写入才加读锁重读：
+
+```java
+long stamp = lock.tryOptimisticRead();
+long sum = readWork();
+if (!lock.validate(stamp)) { // 读的过程中有写入
+ stamp = lock.readLock();
+ try { sum = readWork(); } finally { lock.unlockRead(stamp); }
+}
+```
+
+在本机用 8 个线程访问同一个保存了 1000 个商品价格的 HashMap，99% 的操作是遍历求总价，1% 是修改价格，每个线程 2 万次，三种锁的耗时如下（JDK 21，各运行 3 次）：
+
+- ReentrantLock：365～427 ms，读也互斥，与单线程不加锁执行同样多次读的 357 ms 差不多，8 个线程实际上是排队执行的；
+- ReentrantReadWriteLock：139～156 ms，读可以并行，但每次加读锁都要用 CAS 修改锁中的读线程计数，多个线程争抢同一个变量，不能做到 8 倍；
+- StampedLock 乐观读：61～63 ms，读的时候不修改任何共享变量，只有极少数读取需要重试。
+
+需要注意的是：
+
+- 读锁不能升级为写锁：持有读锁时再获取写锁，要等所有读锁释放，而自己的读锁不会释放，实测 tryLock 等待 1 秒后返回 false，用 lock() 就会永远阻塞；
+- 写锁可以降级为读锁：先获取写锁，再获取读锁，然后释放写锁，这样修改之后的数据可以继续读，期间不会被其它线程修改；
+- StampedLock 不可重入，也不支持 Condition，乐观读期间读到的数据可能是不一致的，只能在 validate 成功之后使用。
## 五、线程之间的协作
@@ -844,6 +882,8 @@ for (int i = 0; i < 3; i++) {
阻塞和等待的区别在于，阻塞是被动的，它是在等待获取 monitor lock。而等待是主动的，通过调用 Object.wait() 等方法进入。
+需要注意的是，只有等待 synchronized 的线程才处于 BLOCKED 状态。ReentrantLock 基于 AQS，抢不到锁的线程通过 LockSupport.park() 挂起，状态是 WAITING：让一个线程等待 synchronized、另一个线程等待 ReentrantLock，在 JDK 21 上打印两者的 getState()，分别是 BLOCKED 和 WAITING。
+
| 进入方法 | 退出方法 |
| --- | --- |
| 没有设置 Timeout 参数的 Object.wait() 方法 | Object.notify() / Object.notifyAll() |
@@ -874,13 +914,37 @@ for (int i = 0; i < 3; i++) {
java.util.concurrent（J.U.C）大大提高了并发性能，AQS 被认为是 J.U.C 的核心。
+AbstractQueuedSynchronizer（AQS）用两样东西实现了各种同步器：
+
+- 一个 int 类型的 state，含义由具体的同步器决定，修改时使用 CAS；
+- 一个等待队列，获取失败的线程包装成节点加入队尾，并通过 LockSupport.park() 挂起，释放时唤醒队头的线程。
+
+以 ReentrantLock 为例，state 表示锁被重入的次数：0 表示没有被持有，加锁时用 CAS 把 0 改为 1，同一个线程再次加锁时直接加 1，解锁时减 1，减到 0 才真正释放。下面的代码中，main 线程加锁两次后，t1、t2 都进入了等待队列：
+
+```java
+ReentrantLock lock = new ReentrantLock();
+lock.lock();
+lock.lock();
+System.out.println(lock.getHoldCount()); // 2
+Thread t1 = new Thread(lock::lock), t2 = new Thread(lock::lock);
+t1.start(); t2.start();
+Thread.sleep(200);
+System.out.println(lock.getQueueLength()); // 2，t1、t2 的状态都是 WAITING
+lock.unlock();
+lock.unlock(); // state 减到 0，唤醒队头的 t1
+```
+
+公平锁与非公平锁的区别只在加锁的第一步：非公平锁不管队列里有没有线程在等，先尝试 CAS 抢一次；公平锁先检查队列（hasQueuedPredecessors），有线程在等就直接排到队尾。非公平锁的好处是刚释放锁的线程可以立即再次获得锁，省去了唤醒另一个线程的开销。在本机用 8 个线程各加锁、解锁 20 万次，非公平锁约 37 ms，公平锁约 3.3 秒，差距接近 100 倍，所以 ReentrantLock 默认是非公平的，只有严格要求先来先得时才使用公平锁。
+
+CountDownLatch、Semaphore 等也基于 AQS，只是对 state 的解释不同：CountDownLatch 的 state 是剩余的计数，Semaphore 的 state 是剩余的许可数。
+
### CountDownLatch
用来控制一个或者多个线程等待多个线程。
维护了一个计数器 cnt，每次调用 countDown() 方法会让计数器的值减 1，减到 0 的时候，那些因为调用 await() 方法而在等待的线程就会被唤醒。
- order = CompletableFuture.supplyAsync(() -> call("订单 1024", 200), pool);
+CompletableFuture logistics = order.thenApplyAsync(o -> call("物流 SF1234567", 200), pool); // 依赖订单的结果
+CompletableFuture coupon = CompletableFuture.supplyAsync(() -> call("优惠券 2 张", 200), pool)
+ .exceptionally(e -> "优惠券暂不可用"); // 失败时降级
+String page = logistics.thenCombine(coupon, (l, c) -> l + "，" + c).join();
+```
+
+```text
+串行：640 ms
+物流 SF1234567，优惠券暂不可用，耗时 425 ms
+```
+
+需要注意的是：
+
+- 不传入线程池时，任务在 ForkJoinPool.commonPool() 中执行，它的线程数默认为 CPU 核数 − 1（本机 10 核时为 9），并且被并行流等代码共用，阻塞的 I/O 任务应该使用自己的线程池；
+- 异常不会自动抛出，要用 exceptionally、handle 处理，否则只有调用 join() 时才会得到包装后的 CompletionException；
+- thenApply 的函数返回普通的值，thenCompose 的函数返回另一个 CompletableFuture，用来串联两个异步调用，避免得到 CompletableFuture<CompletableFuture<T>>。
+
### BlockingQueue
java.util.concurrent.BlockingQueue 接口有以下阻塞队列的实现：
@@ -1164,9 +1254,9 @@ ForkJoin 使用 ForkJoinPool 来启动，它是一个特殊的线程池，线程
public class ForkJoinPool extends AbstractExecutorService
```
-ForkJoinPool 实现了工作窃取算法来提高 CPU 的利用率。每个线程都维护了一个双端队列，用来存储需要执行的任务。工作窃取算法允许空闲的线程从其它线程的双端队列中窃取一个任务来执行。窃取的任务必须是最晚的任务，避免和队列所属线程发生竞争。例如下图中，Thread2 从 Thread1 的队列中拿出最晚的 Task1 任务，Thread1 会拿出 Task2 来执行，这样就避免发生竞争。但是如果队列中只有一个任务时还是会发生竞争。
+ForkJoinPool 实现了工作窃取算法来提高 CPU 的利用率。每个线程都维护了一个双端队列，用来存储需要执行的任务。工作窃取算法允许空闲的线程从其它线程的双端队列中窃取一个任务来执行。线程从自己队列的一端取最新放入的任务，窃取者从另一端取最早放入的任务，两者分别在队列的两端操作，避免发生竞争。例如下图中，Thread2 从 Thread1 的队列中窃取最早的 Task1，Thread1 自己取出 Task3 执行。但是如果队列中只有一个任务时还是会发生竞争。
-32 × 8 = 32 GB 的堆。堆超过 32 GB 时压缩指针自动关闭，所有引用都变大，这是堆的大小通常不超过 32 GB 的原因。
+
## 二、垃圾收集
垃圾收集主要是针对堆和方法区进行。程序计数器、虚拟机栈和本地方法栈这三个区域属于线程私有的，只存在于线程的生命周期内，线程结束之后就会消失，因此不需要对这三个区域进行垃圾回收。
@@ -284,7 +343,7 @@ HotSpot 虚拟机的 Eden 和 Survivor 大小比例默认为 8:1，保证了内
### 垃圾收集器
-33 TB = 8 ZB。
-33 TB
BIOS（Basic Input/Output System，基本输入输出系统），它是一个固件（嵌入在硬件中的软件），BIOS 程序存放在断电后内容不会丢失的只读内存中。
-d N)，其中 d 为每个节点的出度。红黑树的出度为 2，而 B+ Tree 的出度一般都非常大，所以红黑树的树高 h 很明显比 B+ Tree 大非常多。
+例如本机 MySQL 8.0 中一张 200 万行的 orders 表（平均每行约 200 字节），从 .ibd 文件中读取主键索引根页的 PAGE_LEVEL，值为 2，也就是树高为 3：根页中有 27 条记录，指向 27 个中间页，叶子页约 2.5 万个，每页约 80 行。查找任意一行只需要读 3 个页，而且根页和中间页通常常驻在缓冲池中，实际最多 1 次磁盘 I/O；换成二叉树，200 万个节点的高度约为 21。
+
（二）磁盘访问原理
操作系统一般将内存和磁盘分割成固定大小的块，每一块称为一页，内存与磁盘以页为单位交换数据。数据库系统将索引的一个节点的大小设置为页的大小，使得一次 I/O 就能完全载入一个节点。
@@ -76,6 +79,12 @@ B+ Tree 是基于 B Tree 和叶子节点顺序访问指针进行实现，它具
为了减少磁盘 I/O 操作，磁盘往往不是严格按需读取，而是每次都会预读。预读过程中，磁盘进行顺序读取，顺序读取不需要进行磁盘寻道，并且只需要很短的磁盘旋转时间，速度会非常快。并且可以利用预读特性，相邻的节点也能够被预先载入。
+#### 4. 与 B Tree 的比较
+
+- B Tree 的每个节点都存放数据，B+ Tree 只有叶子节点存放数据，内部节点只存放 key 和指针，同样大小的页能放下更多的 key，树更矮；
+- B+ Tree 的叶子节点按 key 的顺序用指针连接，范围查询找到起点后顺序扫描叶子节点即可，B Tree 则要在不同层的节点之间来回遍历；
+- B+ Tree 的每次查找都要走到叶子节点，查询的磁盘 I/O 次数稳定。
+
### MySQL 索引
索引是在存储引擎层实现的，而不是在服务器层实现的，所以不同存储引擎具有不同的索引类型和实现。
@@ -214,6 +223,8 @@ WHERE user_id = 5 AND status > 0 AND create_time > '2025-01-05' -- key_len = 5
不过第二条语句的 Extra 为 Using index condition，也就是索引下推：create_time 虽然不能缩小扫描范围，但仍然在索引上过滤，不满足条件的行不需要回表，所以范围条件之后的列并不是完全没有作用。
+例如 `user_id = 1001 AND create_time >= '2025-01-20'` 跳过了 status，只能用 user_id 定位（key_len = 4），user_id 为 1001 的 20 行中只有 3 行满足时间条件。开启索引下推时 Handler_read_next 为 3，用 `SET optimizer_switch='index_condition_pushdown=off'` 关闭后为 20，也就是多回表了 17 次。
+
需要注意的是，是否使用索引是优化器按成本估算决定的。走二级索引的每一行都要回表，匹配的行越多回表越多，超过一定比例后全表扫描反而更快：`create_time > '2025-01-23'` 匹配 9.9 万行，走 idx_create_time；`create_time > '2025-01-02'` 匹配 191 万行，就选择了全表扫描。IN 也一样，`user_id IN` 5 个值时走索引，3 万多个值时全表扫描。因此同一种写法有时走索引有时不走，可能是因为匹配的数据量不同。
### 索引的优点
@@ -238,6 +249,18 @@ WHERE user_id = 5 AND status > 0 AND create_time > '2025-01-05' -- key_len = 5
## 二、查询性能优化
+### 一条 SQL 的执行过程
+
+MySQL 分为 Server 层和存储引擎层：Server 层负责连接、解析、优化和执行，存储引擎负责数据的存储和读取，例如 InnoDB。
+
+10 + (1010 − 达到这个点赞数的秒级时间戳)。例如 article:1001 和 article:1002 都是 520 个赞，时间戳分别为 1793000000 和 1793000300，分值为 5208207000000 和 5208206999700，先达到的 article:1001 排在前面。需要注意的是，分值是双精度浮点数，只能精确表示 253 以内的整数，这种写法下点赞数不能超过约 90 万，更大时要缩短时间部分的位数。
+
+排行榜被大量用户同时查看时，前 10 名这个键会成为热点。前几名的变化不需要实时反映给每个用户，可以在应用的本地缓存中保存 1 秒，大部分请求不再访问 Redis，见 [多级缓存](缓存.md#多级缓存)。
+
### 其它
Set 可以实现交集、并集等操作，从而实现共同好友等功能。
@@ -450,6 +456,8 @@ Redis 是内存型数据库，为了保证数据在断电后不会丢失，需
将某个时间点的所有数据都存放到硬盘上。
+执行 BGSAVE 或满足 save 配置的条件时，Redis fork 一个子进程把内存中的数据写入 RDB 文件，主进程继续处理命令。fork 之后父子进程共享同一份内存页，主进程修改某一页时操作系统才复制这一页（写时复制），所以生成快照期间写入越多，额外占用的内存越多。
+
可以将快照复制到其它服务器从而创建具有相同数据的服务器副本。
如果系统发生故障，将会丢失最后一次创建快照之后的数据。
@@ -474,6 +482,12 @@ Redis 是内存型数据库，为了保证数据在断电后不会丢失，需
随着服务器写请求的增多，AOF 文件会越来越大。Redis 提供了一种将 AOF 重写的特性，能够去除 AOF 文件中的冗余写命令。
+重写同样由子进程完成，它不读取旧的 AOF 文件，而是按内存中的当前数据生成最少的命令。Redis 7.0 起 AOF 由多个文件组成：重写生成的基础文件，以及之后追加写命令的增量文件。
+
+ byUser(@Param("userId") int userId);
+
+@Select("SELECT id, user_id AS userId, status FROM orders WHERE user_id = ${userId} ORDER BY id LIMIT 3")
+List byUserUnsafe(@Param("userId") String userId);
+```
+
+参数传入 1024 OR 1=1 时，MyBatis 输出的 SQL 分别为：
+
+```text
+==> Preparing: SELECT ... WHERE user_id = ? ORDER BY id LIMIT 3
+==> Parameters: 1024(Integer)
+
+==> Preparing: SELECT ... WHERE user_id = 1024 OR 1=1 ORDER BY id LIMIT 3
+==> Parameters:
+```
+
+第二条语句的条件恒为真，返回了其他用户的订单。${} 只用于表名、列名、ORDER BY 的字段这类不能使用占位符的地方，并且要用白名单校验参数。
+
+### Mapper 接口为什么不需要实现类
+
+MyBatis 在启动时为每个 Mapper 接口生成 JDK 动态代理，例如上面的 OrderMapper 注入的对象类型是 jdk.proxy2.$Proxy63，调用处理器是 MapperProxy。调用接口方法时，MapperProxy 按“接口全名 + 方法名”找到对应的 SQL，绑定参数后交给 SqlSession 执行，再把结果映射成返回类型。
+
+### 动态 SQL
+
+XML 中可以用 if、where、foreach 等标签按参数拼接 SQL：
+
+```xml
+
+ SELECT id, user_id AS userId, status FROM orders
+
+ AND user_id = #{userId}
+ AND status = #{status}
+
+
+```
+
+只传 status 时生成 WHERE status = ?，两个都传时生成 WHERE user_id = ? AND status = ?，where 标签会去掉开头多余的 AND。
+
+### 缓存
+
+- 一级缓存：默认开启，作用范围是一个 SqlSession，同一个会话中相同的查询只执行一次，执行增删改或提交后清空。与 Spring 集成时，不在事务中的每次调用都会使用新的 SqlSession，一级缓存基本不起作用；
+- 二级缓存：需要在 Mapper 中配置 cache 才开启，多个会话共享，但缓存在单个应用的内存中，多个实例之间不一致，实际项目中很少使用，通常用 Redis 等缓存代替。
+
+## 七、Spring 中的设计模式
+
+| 模式 | Spring 中的例子 | 解决的问题 |
+| --- | --- | --- |
+| [工厂](设计模式%20-%20工厂方法.md) | BeanFactory、FactoryBean | 使用者只按名称或类型获取对象，不关心对象怎样创建 |
+| [单例](设计模式%20%20-%20单例.md) | 默认的 singleton 作用域，由 DefaultSingletonBeanRegistry 保存 | 每个 Bean 在容器中只有一个对象，不是通过私有构造函数实现的 |
+| [代理](设计模式%20-%20代理.md) | AOP 的 JdkDynamicAopProxy、CglibAopProxy | 在不修改原类的情况下加入事务、日志等逻辑，见 [动态代理](#动态代理) |
+| [模板方法](设计模式%20-%20模板方法.md) | JdbcTemplate、TransactionTemplate、AbstractApplicationContext 的 refresh() | 固定的步骤（获取连接、执行、释放、处理异常）由框架完成，变化的部分由使用者传入 |
+| [观察者](设计模式%20-%20观察者.md) | ApplicationEvent、ApplicationListener、@EventListener | 发布方不需要知道有哪些接收方 |
+| [适配器](设计模式%20-%20适配器.md) | Spring MVC 的 HandlerAdapter | DispatcherServlet 用同一个接口调用不同形式的处理器，见 [请求的处理过程](#请求的处理过程) |
+| [责任链](设计模式%20-%20责任链.md) | HandlerExecutionChain 中的拦截器、AOP 的 ReflectiveMethodInvocation | 多个拦截器或通知依次处理同一个请求 |
+| [策略](设计模式%20-%20策略.md) | InstantiationStrategy、Resource 的多种实现 | 同一件事有多种做法，运行时选择其中一种 |
+
+以观察者模式为例，订单支付成功后需要加积分、发短信，用事件解耦后，订单服务只负责发布事件：
+
+```java
+public record OrderPaidEvent(long orderId) {}
+
+publisher.publishEvent(new OrderPaidEvent(1024)); // 订单服务，publisher 是注入的 ApplicationEventPublisher
+
+@EventListener
+public void on(OrderPaidEvent e) { ... } // 积分服务、短信服务各写一个监听方法
+```
+
+需要注意的是，监听方法默认在发布事件的线程中同步执行。在 Spring Boot 3.3 中让短信服务的监听方法抛出异常，输出如下：
+
+```text
+[main] 订单 1024 支付成功，发布事件
+[main] 短信服务：发送失败
+[main] 发布方收到异常：短信网关超时
+```
+
+两个监听方法都在 main 线程中执行；短信服务先执行并抛出异常后，积分服务的监听方法没有被调用，异常还传回了订单服务。监听方法之间的顺序默认不确定，可以用 @Order 指定；不希望互相影响时，加上 @Async 让监听方法在线程池中异步执行，或者用 @TransactionalEventListener 在订单的事务提交之后再处理。
+
## 参考资料
- [Spring Framework: Dependency Injection](https://docs.spring.io/spring-framework/reference/core/beans/dependencies/factory-collaborators.html)
@@ -203,3 +361,5 @@ Spring Boot 在 Spring 的基础上提供了自动配置和 starter：starter
- [Spring Boot: Creating Your Own Auto-configuration](https://docs.spring.io/spring-boot/reference/features/developing-auto-configuration.html)
- [Spring Boot 2.6 Release Notes](https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.6-Release-Notes)
- [Spring Boot 2.7 Release Notes](https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.7-Release-Notes)
+- [MyBatis 3 文档](https://mybatis.org/mybatis-3/zh_CN/index.html)
+- [DispatcherServlet | Spring Framework 文档](https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-servlet.html)
diff --git a/notes/pics/acid.png b/notes/pics/acid.png
new file mode 100644
index 000000000..0cfcef06f
Binary files /dev/null and b/notes/pics/acid.png differ
diff --git a/notes/pics/adapter-turkey.png b/notes/pics/adapter-turkey.png
new file mode 100644
index 000000000..dcc5f8b86
Binary files /dev/null and b/notes/pics/adapter-turkey.png differ
diff --git a/notes/pics/cdn.png b/notes/pics/cdn.png
new file mode 100644
index 000000000..e29eac630
Binary files /dev/null and b/notes/pics/cdn.png differ
diff --git a/notes/pics/cert-chain.png b/notes/pics/cert-chain.png
new file mode 100644
index 000000000..33a000977
Binary files /dev/null and b/notes/pics/cert-chain.png differ
diff --git a/notes/pics/clock.png b/notes/pics/clock.png
new file mode 100644
index 000000000..ea355824b
Binary files /dev/null and b/notes/pics/clock.png differ
diff --git a/notes/pics/coding-agent.png b/notes/pics/coding-agent.png
new file mode 100644
index 000000000..74a9ebb90
Binary files /dev/null and b/notes/pics/coding-agent.png differ
diff --git a/notes/pics/command-remote.png b/notes/pics/command-remote.png
new file mode 100644
index 000000000..b3693b6aa
Binary files /dev/null and b/notes/pics/command-remote.png differ
diff --git a/notes/pics/compile-pipeline.png b/notes/pics/compile-pipeline.png
new file mode 100644
index 000000000..2af854c6a
Binary files /dev/null and b/notes/pics/compile-pipeline.png differ
diff --git a/notes/pics/consistent-hash.png b/notes/pics/consistent-hash.png
new file mode 100644
index 000000000..b3dad47a6
Binary files /dev/null and b/notes/pics/consistent-hash.png differ
diff --git a/notes/pics/crypto-asymmetric.png b/notes/pics/crypto-asymmetric.png
new file mode 100644
index 000000000..a3bc2a15b
Binary files /dev/null and b/notes/pics/crypto-asymmetric.png differ
diff --git a/notes/pics/crypto-symmetric.png b/notes/pics/crypto-symmetric.png
new file mode 100644
index 000000000..cc138e6d0
Binary files /dev/null and b/notes/pics/crypto-symmetric.png differ
diff --git a/notes/pics/deadlock-banker-multi.png b/notes/pics/deadlock-banker-multi.png
new file mode 100644
index 000000000..95c57b6d9
Binary files /dev/null and b/notes/pics/deadlock-banker-multi.png differ
diff --git a/notes/pics/deadlock-banker-single.png b/notes/pics/deadlock-banker-single.png
new file mode 100644
index 000000000..f11d25fb1
Binary files /dev/null and b/notes/pics/deadlock-banker-single.png differ
diff --git a/notes/pics/deadlock-detect-graph.png b/notes/pics/deadlock-detect-graph.png
new file mode 100644
index 000000000..4fc166d7e
Binary files /dev/null and b/notes/pics/deadlock-detect-graph.png differ
diff --git a/notes/pics/deadlock-detect-matrix.png b/notes/pics/deadlock-detect-matrix.png
new file mode 100644
index 000000000..643e29074
Binary files /dev/null and b/notes/pics/deadlock-detect-matrix.png differ
diff --git a/notes/pics/deadlock-safe-state.png b/notes/pics/deadlock-safe-state.png
new file mode 100644
index 000000000..bb8da3850
Binary files /dev/null and b/notes/pics/deadlock-safe-state.png differ
diff --git a/notes/pics/deadlock-transfer.png b/notes/pics/deadlock-transfer.png
new file mode 100644
index 000000000..f6deebb33
Binary files /dev/null and b/notes/pics/deadlock-transfer.png differ
diff --git a/notes/pics/decorator-cost.png b/notes/pics/decorator-cost.png
new file mode 100644
index 000000000..e85670ba6
Binary files /dev/null and b/notes/pics/decorator-cost.png differ
diff --git a/notes/pics/dhcp.png b/notes/pics/dhcp.png
new file mode 100644
index 000000000..08932a449
Binary files /dev/null and b/notes/pics/dhcp.png differ
diff --git a/notes/pics/disk-scan.png b/notes/pics/disk-scan.png
new file mode 100644
index 000000000..1f0012fb3
Binary files /dev/null and b/notes/pics/disk-scan.png differ
diff --git a/notes/pics/disk-sstf.png b/notes/pics/disk-sstf.png
new file mode 100644
index 000000000..abbfeabf2
Binary files /dev/null and b/notes/pics/disk-sstf.png differ
diff --git a/notes/pics/dns-resolve.png b/notes/pics/dns-resolve.png
new file mode 100644
index 000000000..89ffbfbd6
Binary files /dev/null and b/notes/pics/dns-resolve.png differ
diff --git a/notes/pics/docker-layers.png b/notes/pics/docker-layers.png
new file mode 100644
index 000000000..a16025c8d
Binary files /dev/null and b/notes/pics/docker-layers.png differ
diff --git a/notes/pics/docker-vs-vm.png b/notes/pics/docker-vs-vm.png
new file mode 100644
index 000000000..09f3f8a00
Binary files /dev/null and b/notes/pics/docker-vs-vm.png differ
diff --git a/notes/pics/docker-why.png b/notes/pics/docker-why.png
new file mode 100644
index 000000000..e0399ad68
Binary files /dev/null and b/notes/pics/docker-why.png differ
diff --git a/notes/pics/dynamic-link.png b/notes/pics/dynamic-link.png
new file mode 100644
index 000000000..f0cf19c8a
Binary files /dev/null and b/notes/pics/dynamic-link.png differ
diff --git a/notes/pics/email-flow.png b/notes/pics/email-flow.png
new file mode 100644
index 000000000..f2b88cd11
Binary files /dev/null and b/notes/pics/email-flow.png differ
diff --git a/notes/pics/ext-layout.png b/notes/pics/ext-layout.png
new file mode 100644
index 000000000..9e3acb10e
Binary files /dev/null and b/notes/pics/ext-layout.png differ
diff --git a/notes/pics/facade-movie.png b/notes/pics/facade-movie.png
new file mode 100644
index 000000000..226c68200
Binary files /dev/null and b/notes/pics/facade-movie.png differ
diff --git a/notes/pics/feed-push-pull.png b/notes/pics/feed-push-pull.png
new file mode 100644
index 000000000..54a8cc736
Binary files /dev/null and b/notes/pics/feed-push-pull.png differ
diff --git a/notes/pics/fifo.png b/notes/pics/fifo.png
new file mode 100644
index 000000000..6422dba64
Binary files /dev/null and b/notes/pics/fifo.png differ
diff --git a/notes/pics/ftp-modes.png b/notes/pics/ftp-modes.png
new file mode 100644
index 000000000..430e19c22
Binary files /dev/null and b/notes/pics/ftp-modes.png differ
diff --git a/notes/pics/gc-cms.png b/notes/pics/gc-cms.png
new file mode 100644
index 000000000..8df701cc5
Binary files /dev/null and b/notes/pics/gc-cms.png differ
diff --git a/notes/pics/gc-collectors.png b/notes/pics/gc-collectors.png
new file mode 100644
index 000000000..a5cc6143f
Binary files /dev/null and b/notes/pics/gc-collectors.png differ
diff --git a/notes/pics/gc-g1-cycle.png b/notes/pics/gc-g1-cycle.png
new file mode 100644
index 000000000..bc22faca3
Binary files /dev/null and b/notes/pics/gc-g1-cycle.png differ
diff --git a/notes/pics/gc-g1-regions.png b/notes/pics/gc-g1-regions.png
new file mode 100644
index 000000000..41733ed77
Binary files /dev/null and b/notes/pics/gc-g1-regions.png differ
diff --git a/notes/pics/gc-generations.png b/notes/pics/gc-generations.png
new file mode 100644
index 000000000..4ff636bec
Binary files /dev/null and b/notes/pics/gc-generations.png differ
diff --git a/notes/pics/gc-parallel.png b/notes/pics/gc-parallel.png
new file mode 100644
index 000000000..c98615f23
Binary files /dev/null and b/notes/pics/gc-parallel.png differ
diff --git a/notes/pics/gc-parnew.png b/notes/pics/gc-parnew.png
new file mode 100644
index 000000000..7f8466b83
Binary files /dev/null and b/notes/pics/gc-parnew.png differ
diff --git a/notes/pics/gc-serial.png b/notes/pics/gc-serial.png
new file mode 100644
index 000000000..209606776
Binary files /dev/null and b/notes/pics/gc-serial.png differ
diff --git a/notes/pics/gpt-layout.png b/notes/pics/gpt-layout.png
new file mode 100644
index 000000000..468a281cb
Binary files /dev/null and b/notes/pics/gpt-layout.png differ
diff --git a/notes/pics/h2-frames.png b/notes/pics/h2-frames.png
new file mode 100644
index 000000000..b98a7ff2e
Binary files /dev/null and b/notes/pics/h2-frames.png differ
diff --git a/notes/pics/h2-push.png b/notes/pics/h2-push.png
new file mode 100644
index 000000000..c78899327
Binary files /dev/null and b/notes/pics/h2-push.png differ
diff --git a/notes/pics/h2-streams.png b/notes/pics/h2-streams.png
new file mode 100644
index 000000000..b8064e402
Binary files /dev/null and b/notes/pics/h2-streams.png differ
diff --git a/notes/pics/harness-loop.png b/notes/pics/harness-loop.png
new file mode 100644
index 000000000..ef8af9d54
Binary files /dev/null and b/notes/pics/harness-loop.png differ
diff --git a/notes/pics/hpack.png b/notes/pics/hpack.png
new file mode 100644
index 000000000..bc0e928bb
Binary files /dev/null and b/notes/pics/hpack.png differ
diff --git a/notes/pics/http-connect.png b/notes/pics/http-connect.png
new file mode 100644
index 000000000..0ab53eaa8
Binary files /dev/null and b/notes/pics/http-connect.png differ
diff --git a/notes/pics/http-connections.png b/notes/pics/http-connections.png
new file mode 100644
index 000000000..b255b9f2c
Binary files /dev/null and b/notes/pics/http-connections.png differ
diff --git a/notes/pics/http-proxy.png b/notes/pics/http-proxy.png
new file mode 100644
index 000000000..aea75d78a
Binary files /dev/null and b/notes/pics/http-proxy.png differ
diff --git a/notes/pics/https-hybrid.png b/notes/pics/https-hybrid.png
new file mode 100644
index 000000000..11c444278
Binary files /dev/null and b/notes/pics/https-hybrid.png differ
diff --git a/notes/pics/https-layers.png b/notes/pics/https-layers.png
new file mode 100644
index 000000000..dcbaf8fd9
Binary files /dev/null and b/notes/pics/https-layers.png differ
diff --git a/notes/pics/inode-pointers.png b/notes/pics/inode-pointers.png
new file mode 100644
index 000000000..d03a8854a
Binary files /dev/null and b/notes/pics/inode-pointers.png differ
diff --git a/notes/pics/io-async.png b/notes/pics/io-async.png
new file mode 100644
index 000000000..728ab3a7c
Binary files /dev/null and b/notes/pics/io-async.png differ
diff --git a/notes/pics/io-blocking.png b/notes/pics/io-blocking.png
new file mode 100644
index 000000000..d2d0f5035
Binary files /dev/null and b/notes/pics/io-blocking.png differ
diff --git a/notes/pics/io-compare.png b/notes/pics/io-compare.png
new file mode 100644
index 000000000..470432bc1
Binary files /dev/null and b/notes/pics/io-compare.png differ
diff --git a/notes/pics/io-multiplex.png b/notes/pics/io-multiplex.png
new file mode 100644
index 000000000..f00a310bd
Binary files /dev/null and b/notes/pics/io-multiplex.png differ
diff --git a/notes/pics/io-nonblocking.png b/notes/pics/io-nonblocking.png
new file mode 100644
index 000000000..1c65449eb
Binary files /dev/null and b/notes/pics/io-nonblocking.png differ
diff --git a/notes/pics/io-signal.png b/notes/pics/io-signal.png
new file mode 100644
index 000000000..b700a40b2
Binary files /dev/null and b/notes/pics/io-signal.png differ
diff --git a/notes/pics/java-exceptions.png b/notes/pics/java-exceptions.png
new file mode 100644
index 000000000..7645d8d57
Binary files /dev/null and b/notes/pics/java-exceptions.png differ
diff --git a/notes/pics/jc-atomic-cas.png b/notes/pics/jc-atomic-cas.png
new file mode 100644
index 000000000..5b68499a2
Binary files /dev/null and b/notes/pics/jc-atomic-cas.png differ
diff --git a/notes/pics/jc-cnt-race.png b/notes/pics/jc-cnt-race.png
new file mode 100644
index 000000000..d1e0f5482
Binary files /dev/null and b/notes/pics/jc-cnt-race.png differ
diff --git a/notes/pics/jc-countdownlatch.png b/notes/pics/jc-countdownlatch.png
new file mode 100644
index 000000000..42db01ffb
Binary files /dev/null and b/notes/pics/jc-countdownlatch.png differ
diff --git a/notes/pics/jc-cpu-cache.png b/notes/pics/jc-cpu-cache.png
new file mode 100644
index 000000000..ab1707b5d
Binary files /dev/null and b/notes/pics/jc-cpu-cache.png differ
diff --git a/notes/pics/jc-cyclicbarrier.png b/notes/pics/jc-cyclicbarrier.png
new file mode 100644
index 000000000..d648ece81
Binary files /dev/null and b/notes/pics/jc-cyclicbarrier.png differ
diff --git a/notes/pics/jc-hb-join.png b/notes/pics/jc-hb-join.png
new file mode 100644
index 000000000..7ac8279fa
Binary files /dev/null and b/notes/pics/jc-hb-join.png differ
diff --git a/notes/pics/jc-hb-monitor.png b/notes/pics/jc-hb-monitor.png
new file mode 100644
index 000000000..8be8854a6
Binary files /dev/null and b/notes/pics/jc-hb-monitor.png differ
diff --git a/notes/pics/jc-hb-program-order.png b/notes/pics/jc-hb-program-order.png
new file mode 100644
index 000000000..40ae53343
Binary files /dev/null and b/notes/pics/jc-hb-program-order.png differ
diff --git a/notes/pics/jc-hb-start.png b/notes/pics/jc-hb-start.png
new file mode 100644
index 000000000..40f9421ae
Binary files /dev/null and b/notes/pics/jc-hb-start.png differ
diff --git a/notes/pics/jc-hb-volatile.png b/notes/pics/jc-hb-volatile.png
new file mode 100644
index 000000000..9b36c6732
Binary files /dev/null and b/notes/pics/jc-hb-volatile.png differ
diff --git a/notes/pics/jc-jmm-ops.png b/notes/pics/jc-jmm-ops.png
new file mode 100644
index 000000000..decc984cf
Binary files /dev/null and b/notes/pics/jc-jmm-ops.png differ
diff --git a/notes/pics/jc-jmm.png b/notes/pics/jc-jmm.png
new file mode 100644
index 000000000..9db572bef
Binary files /dev/null and b/notes/pics/jc-jmm.png differ
diff --git a/notes/pics/jc-threadlocal.png b/notes/pics/jc-threadlocal.png
new file mode 100644
index 000000000..fab252695
Binary files /dev/null and b/notes/pics/jc-threadlocal.png differ
diff --git a/notes/pics/jc-work-stealing.png b/notes/pics/jc-work-stealing.png
new file mode 100644
index 000000000..9502efd56
Binary files /dev/null and b/notes/pics/jc-work-stealing.png differ
diff --git a/notes/pics/kafka-topic.png b/notes/pics/kafka-topic.png
new file mode 100644
index 000000000..127fa40b8
Binary files /dev/null and b/notes/pics/kafka-topic.png differ
diff --git a/notes/pics/lb-dns.png b/notes/pics/lb-dns.png
new file mode 100644
index 000000000..193456832
Binary files /dev/null and b/notes/pics/lb-dns.png differ
diff --git a/notes/pics/lb-http-redirect.png b/notes/pics/lb-http-redirect.png
new file mode 100644
index 000000000..da0c3fa94
Binary files /dev/null and b/notes/pics/lb-http-redirect.png differ
diff --git a/notes/pics/lb-ip-hash.png b/notes/pics/lb-ip-hash.png
new file mode 100644
index 000000000..c9cbe07d3
Binary files /dev/null and b/notes/pics/lb-ip-hash.png differ
diff --git a/notes/pics/lb-least-conn-problem.png b/notes/pics/lb-least-conn-problem.png
new file mode 100644
index 000000000..989050faa
Binary files /dev/null and b/notes/pics/lb-least-conn-problem.png differ
diff --git a/notes/pics/lb-least-conn.png b/notes/pics/lb-least-conn.png
new file mode 100644
index 000000000..a18dbccd6
Binary files /dev/null and b/notes/pics/lb-least-conn.png differ
diff --git a/notes/pics/lb-random.png b/notes/pics/lb-random.png
new file mode 100644
index 000000000..78ec1e840
Binary files /dev/null and b/notes/pics/lb-random.png differ
diff --git a/notes/pics/lb-round-robin-weak.png b/notes/pics/lb-round-robin-weak.png
new file mode 100644
index 000000000..7a3250a4b
Binary files /dev/null and b/notes/pics/lb-round-robin-weak.png differ
diff --git a/notes/pics/lb-round-robin.png b/notes/pics/lb-round-robin.png
new file mode 100644
index 000000000..b4d2f0085
Binary files /dev/null and b/notes/pics/lb-round-robin.png differ
diff --git a/notes/pics/lb-weighted-round-robin.png b/notes/pics/lb-weighted-round-robin.png
new file mode 100644
index 000000000..cbbbd79d9
Binary files /dev/null and b/notes/pics/lb-weighted-round-robin.png differ
diff --git a/notes/pics/lock-level-1.png b/notes/pics/lock-level-1.png
new file mode 100644
index 000000000..3001ced5b
Binary files /dev/null and b/notes/pics/lock-level-1.png differ
diff --git a/notes/pics/lock-level-2.png b/notes/pics/lock-level-2.png
new file mode 100644
index 000000000..396a33d31
Binary files /dev/null and b/notes/pics/lock-level-2.png differ
diff --git a/notes/pics/lock-level-3.png b/notes/pics/lock-level-3.png
new file mode 100644
index 000000000..3ade520b0
Binary files /dev/null and b/notes/pics/lock-level-3.png differ
diff --git a/notes/pics/lock-record.png b/notes/pics/lock-record.png
new file mode 100644
index 000000000..b88a03fd1
Binary files /dev/null and b/notes/pics/lock-record.png differ
diff --git a/notes/pics/lock-states.png b/notes/pics/lock-states.png
new file mode 100644
index 000000000..b36faed0c
Binary files /dev/null and b/notes/pics/lock-states.png differ
diff --git a/notes/pics/lru-stack.png b/notes/pics/lru-stack.png
new file mode 100644
index 000000000..b6c7c64cd
Binary files /dev/null and b/notes/pics/lru-stack.png differ
diff --git a/notes/pics/markword.png b/notes/pics/markword.png
new file mode 100644
index 000000000..5d1d70872
Binary files /dev/null and b/notes/pics/markword.png differ
diff --git a/notes/pics/mbr-multiboot.png b/notes/pics/mbr-multiboot.png
new file mode 100644
index 000000000..707a31b5a
Binary files /dev/null and b/notes/pics/mbr-multiboot.png differ
diff --git a/notes/pics/mediator-after.png b/notes/pics/mediator-after.png
new file mode 100644
index 000000000..ef5f90e31
Binary files /dev/null and b/notes/pics/mediator-after.png differ
diff --git a/notes/pics/mediator-before.png b/notes/pics/mediator-before.png
new file mode 100644
index 000000000..ecbf55343
Binary files /dev/null and b/notes/pics/mediator-before.png differ
diff --git a/notes/pics/mime.png b/notes/pics/mime.png
new file mode 100644
index 000000000..14b2e4650
Binary files /dev/null and b/notes/pics/mime.png differ
diff --git a/notes/pics/modulation.png b/notes/pics/modulation.png
new file mode 100644
index 000000000..5bdc389a5
Binary files /dev/null and b/notes/pics/modulation.png differ
diff --git a/notes/pics/multilevel-cache.png b/notes/pics/multilevel-cache.png
new file mode 100644
index 000000000..55e590d7f
Binary files /dev/null and b/notes/pics/multilevel-cache.png differ
diff --git a/notes/pics/mvcc-readview.png b/notes/pics/mvcc-readview.png
new file mode 100644
index 000000000..d6037bae2
Binary files /dev/null and b/notes/pics/mvcc-readview.png differ
diff --git a/notes/pics/mvcc-undo-chain.png b/notes/pics/mvcc-undo-chain.png
new file mode 100644
index 000000000..1a3fb476d
Binary files /dev/null and b/notes/pics/mvcc-undo-chain.png differ
diff --git a/notes/pics/mysql-replication.png b/notes/pics/mysql-replication.png
new file mode 100644
index 000000000..2424d7926
Binary files /dev/null and b/notes/pics/mysql-replication.png differ
diff --git a/notes/pics/mysql-rw-split.png b/notes/pics/mysql-rw-split.png
new file mode 100644
index 000000000..e75620680
Binary files /dev/null and b/notes/pics/mysql-rw-split.png differ
diff --git a/notes/pics/network-of-networks.png b/notes/pics/network-of-networks.png
new file mode 100644
index 000000000..4212a73b1
Binary files /dev/null and b/notes/pics/network-of-networks.png differ
diff --git a/notes/pics/next-key-locks-v2.png b/notes/pics/next-key-locks-v2.png
new file mode 100644
index 000000000..9044a2ce6
Binary files /dev/null and b/notes/pics/next-key-locks-v2.png differ
diff --git a/notes/pics/oauth-code-flow.png b/notes/pics/oauth-code-flow.png
new file mode 100644
index 000000000..e760d1d4d
Binary files /dev/null and b/notes/pics/oauth-code-flow.png differ
diff --git a/notes/pics/observer-intent.png b/notes/pics/observer-intent.png
new file mode 100644
index 000000000..2e1234704
Binary files /dev/null and b/notes/pics/observer-intent.png differ
diff --git a/notes/pics/observer-run.png b/notes/pics/observer-run.png
new file mode 100644
index 000000000..5653ecdbd
Binary files /dev/null and b/notes/pics/observer-run.png differ
diff --git a/notes/pics/os-kernels.png b/notes/pics/os-kernels.png
new file mode 100644
index 000000000..a350ac84d
Binary files /dev/null and b/notes/pics/os-kernels.png differ
diff --git a/notes/pics/os-syscall.png b/notes/pics/os-syscall.png
new file mode 100644
index 000000000..324f57414
Binary files /dev/null and b/notes/pics/os-syscall.png differ
diff --git a/notes/pics/page-translate.png b/notes/pics/page-translate.png
new file mode 100644
index 000000000..0422bb507
Binary files /dev/null and b/notes/pics/page-translate.png differ
diff --git a/notes/pics/paxos-roles.png b/notes/pics/paxos-roles.png
new file mode 100644
index 000000000..58f62c8f3
Binary files /dev/null and b/notes/pics/paxos-roles.png differ
diff --git a/notes/pics/philosophers.png b/notes/pics/philosophers.png
new file mode 100644
index 000000000..cac076a6a
Binary files /dev/null and b/notes/pics/philosophers.png differ
diff --git a/notes/pics/pipe.png b/notes/pics/pipe.png
new file mode 100644
index 000000000..5bc7d4575
Binary files /dev/null and b/notes/pics/pipe.png differ
diff --git a/notes/pics/process-concurrent.png b/notes/pics/process-concurrent.png
new file mode 100644
index 000000000..4ce4b747e
Binary files /dev/null and b/notes/pics/process-concurrent.png differ
diff --git a/notes/pics/process-mlfq.png b/notes/pics/process-mlfq.png
new file mode 100644
index 000000000..ca8112ef1
Binary files /dev/null and b/notes/pics/process-mlfq.png differ
diff --git a/notes/pics/process-rr.png b/notes/pics/process-rr.png
new file mode 100644
index 000000000..aba55c692
Binary files /dev/null and b/notes/pics/process-rr.png differ
diff --git a/notes/pics/process-states.png b/notes/pics/process-states.png
new file mode 100644
index 000000000..2e589e471
Binary files /dev/null and b/notes/pics/process-states.png differ
diff --git a/notes/pics/process-threads.png b/notes/pics/process-threads.png
new file mode 100644
index 000000000..262660d68
Binary files /dev/null and b/notes/pics/process-threads.png differ
diff --git a/notes/pics/raft-election.png b/notes/pics/raft-election.png
new file mode 100644
index 000000000..76c947924
Binary files /dev/null and b/notes/pics/raft-election.png differ
diff --git a/notes/pics/raft-log.png b/notes/pics/raft-log.png
new file mode 100644
index 000000000..a4f6dc535
Binary files /dev/null and b/notes/pics/raft-log.png differ
diff --git a/notes/pics/raft-split.png b/notes/pics/raft-split.png
new file mode 100644
index 000000000..b5c2bdd0f
Binary files /dev/null and b/notes/pics/raft-split.png differ
diff --git a/notes/pics/redis-aof-rewrite.png b/notes/pics/redis-aof-rewrite.png
new file mode 100644
index 000000000..7eb917a9f
Binary files /dev/null and b/notes/pics/redis-aof-rewrite.png differ
diff --git a/notes/pics/redis-article-hash.png b/notes/pics/redis-article-hash.png
new file mode 100644
index 000000000..3cf4e5a8c
Binary files /dev/null and b/notes/pics/redis-article-hash.png differ
diff --git a/notes/pics/redis-article-vote.png b/notes/pics/redis-article-vote.png
new file mode 100644
index 000000000..3bc27d25d
Binary files /dev/null and b/notes/pics/redis-article-vote.png differ
diff --git a/notes/pics/redis-article-zsets.png b/notes/pics/redis-article-zsets.png
new file mode 100644
index 000000000..7b5f55396
Binary files /dev/null and b/notes/pics/redis-article-zsets.png differ
diff --git a/notes/pics/redis-event-loop.png b/notes/pics/redis-event-loop.png
new file mode 100644
index 000000000..fb9e789cf
Binary files /dev/null and b/notes/pics/redis-event-loop.png differ
diff --git a/notes/pics/redis-file-event.png b/notes/pics/redis-file-event.png
new file mode 100644
index 000000000..50091b87e
Binary files /dev/null and b/notes/pics/redis-file-event.png differ
diff --git a/notes/pics/redis-hash.png b/notes/pics/redis-hash.png
new file mode 100644
index 000000000..2d4f7deb3
Binary files /dev/null and b/notes/pics/redis-hash.png differ
diff --git a/notes/pics/redis-list.png b/notes/pics/redis-list.png
new file mode 100644
index 000000000..76e313fa1
Binary files /dev/null and b/notes/pics/redis-list.png differ
diff --git a/notes/pics/redis-replica-chain.png b/notes/pics/redis-replica-chain.png
new file mode 100644
index 000000000..2a836574e
Binary files /dev/null and b/notes/pics/redis-replica-chain.png differ
diff --git a/notes/pics/redis-sentinel-failover.png b/notes/pics/redis-sentinel-failover.png
new file mode 100644
index 000000000..d634440ee
Binary files /dev/null and b/notes/pics/redis-sentinel-failover.png differ
diff --git a/notes/pics/redis-set.png b/notes/pics/redis-set.png
new file mode 100644
index 000000000..fa68c55c3
Binary files /dev/null and b/notes/pics/redis-set.png differ
diff --git a/notes/pics/redis-skiplist.png b/notes/pics/redis-skiplist.png
new file mode 100644
index 000000000..d02bb99f4
Binary files /dev/null and b/notes/pics/redis-skiplist.png differ
diff --git a/notes/pics/redis-string.png b/notes/pics/redis-string.png
new file mode 100644
index 000000000..9260ae15b
Binary files /dev/null and b/notes/pics/redis-string.png differ
diff --git a/notes/pics/redis-zset.png b/notes/pics/redis-zset.png
new file mode 100644
index 000000000..e10c26f57
Binary files /dev/null and b/notes/pics/redis-zset.png differ
diff --git a/notes/pics/second-chance.png b/notes/pics/second-chance.png
new file mode 100644
index 000000000..f3ee602f8
Binary files /dev/null and b/notes/pics/second-chance.png differ
diff --git a/notes/pics/segments.png b/notes/pics/segments.png
new file mode 100644
index 000000000..86ceb1f35
Binary files /dev/null and b/notes/pics/segments.png differ
diff --git a/notes/pics/shard-horizontal.png b/notes/pics/shard-horizontal.png
new file mode 100644
index 000000000..9789e3ce3
Binary files /dev/null and b/notes/pics/shard-horizontal.png differ
diff --git a/notes/pics/shard-vertical.png b/notes/pics/shard-vertical.png
new file mode 100644
index 000000000..c505cf326
Binary files /dev/null and b/notes/pics/shard-vertical.png differ
diff --git a/notes/pics/short-url.png b/notes/pics/short-url.png
new file mode 100644
index 000000000..3fe81ca30
Binary files /dev/null and b/notes/pics/short-url.png differ
diff --git a/notes/pics/snowflake.png b/notes/pics/snowflake.png
new file mode 100644
index 000000000..6ea1c76f1
Binary files /dev/null and b/notes/pics/snowflake.png differ
diff --git a/notes/pics/sql-flow.png b/notes/pics/sql-flow.png
new file mode 100644
index 000000000..37a4aae6e
Binary files /dev/null and b/notes/pics/sql-flow.png differ
diff --git a/notes/pics/state-gumball.png b/notes/pics/state-gumball.png
new file mode 100644
index 000000000..efee450df
Binary files /dev/null and b/notes/pics/state-gumball.png differ
diff --git a/notes/pics/static-link.png b/notes/pics/static-link.png
new file mode 100644
index 000000000..e264f3b72
Binary files /dev/null and b/notes/pics/static-link.png differ
diff --git a/notes/pics/template-recipe.png b/notes/pics/template-recipe.png
new file mode 100644
index 000000000..8ccd74edc
Binary files /dev/null and b/notes/pics/template-recipe.png differ
diff --git a/notes/pics/tls-handshake.png b/notes/pics/tls-handshake.png
new file mode 100644
index 000000000..0fe3e216a
Binary files /dev/null and b/notes/pics/tls-handshake.png differ
diff --git a/notes/pics/tool-call-text.png b/notes/pics/tool-call-text.png
new file mode 100644
index 000000000..996b08d24
Binary files /dev/null and b/notes/pics/tool-call-text.png differ
diff --git a/notes/pics/txn-dirty-read.png b/notes/pics/txn-dirty-read.png
new file mode 100644
index 000000000..b354456d6
Binary files /dev/null and b/notes/pics/txn-dirty-read.png differ
diff --git a/notes/pics/txn-flow.png b/notes/pics/txn-flow.png
new file mode 100644
index 000000000..0a1a474aa
Binary files /dev/null and b/notes/pics/txn-flow.png differ
diff --git a/notes/pics/txn-lost-update.png b/notes/pics/txn-lost-update.png
new file mode 100644
index 000000000..98d99d204
Binary files /dev/null and b/notes/pics/txn-lost-update.png differ
diff --git a/notes/pics/txn-non-repeatable.png b/notes/pics/txn-non-repeatable.png
new file mode 100644
index 000000000..268a77d16
Binary files /dev/null and b/notes/pics/txn-non-repeatable.png differ
diff --git a/notes/pics/txn-phantom.png b/notes/pics/txn-phantom.png
new file mode 100644
index 000000000..c0b528922
Binary files /dev/null and b/notes/pics/txn-phantom.png differ
diff --git a/notes/pics/url-timeline.png b/notes/pics/url-timeline.png
new file mode 100644
index 000000000..56a91a5d4
Binary files /dev/null and b/notes/pics/url-timeline.png differ
diff --git a/notes/pics/vm-mapping.png b/notes/pics/vm-mapping.png
new file mode 100644
index 000000000..eb004621d
Binary files /dev/null and b/notes/pics/vm-mapping.png differ
diff --git a/notes/pics/zero-copy.png b/notes/pics/zero-copy.png
new file mode 100644
index 000000000..e55ec79e3
Binary files /dev/null and b/notes/pics/zero-copy.png differ
diff --git "a/notes/\344\273\243\347\240\201\345\217\257\350\257\273\346\200\247.md" "b/notes/\344\273\243\347\240\201\345\217\257\350\257\273\346\200\247.md"
index 1b1458d92..9d9618d1c 100644
--- "a/notes/\344\273\243\347\240\201\345\217\257\350\257\273\346\200\247.md"
+++ "b/notes/\344\273\243\347\240\201\345\217\257\350\257\273\346\200\247.md"
@@ -272,17 +272,17 @@ var setFirstEmptyInput = function(new_value) {
```java
int findClostElement(int[] arr) {
- int clostIdx;
- int clostDist = Interger.MAX_VALUE;
+ int clostIdx = -1;
+ int clostDist = Integer.MAX_VALUE;
for (int i = 0; i < arr.length; i++) {
int x = ...;
int y = ...;
int z = ...;
int value = x * y * z;
- int dist = Math.sqrt(Math.pow(value, 2), Math.pow(arr[i], 2));
+ int dist = (int) Math.sqrt(Math.pow(value, 2) + Math.pow(arr[i], 2));
if (dist < clostDist) {
clostIdx = i;
- clostDist = value;
+ clostDist = dist;
}
}
return clostIdx;
@@ -293,13 +293,13 @@ int findClostElement(int[] arr) {
```java
public int findClostElement(int[] arr) {
- int clostIdx;
- int clostDist = Interger.MAX_VALUE;
+ int clostIdx = -1;
+ int clostDist = Integer.MAX_VALUE;
for (int i = 0; i < arr.length; i++) {
int dist = computDist(arr, i);
if (dist < clostDist) {
clostIdx = i;
- clostDist = value;
+ clostDist = dist;
}
}
return clostIdx;
diff --git "a/notes/\345\210\206\345\270\203\345\274\217.md" "b/notes/\345\210\206\345\270\203\345\274\217.md"
index 1d8020829..9446dd4f4 100644
--- "a/notes/\345\210\206\345\270\203\345\274\217.md"
+++ "b/notes/\345\210\206\345\270\203\345\274\217.md"
@@ -33,6 +33,9 @@
* [服务发现](#服务发现)
* [RPC 与 HTTP](#rpc-与-http)
* [超时与重试](#超时与重试)
+ * [八、分布式 ID](#八分布式-id)
+ * [雪花算法](#雪花算法)
+ * [九、幂等](#九幂等)
* [参考](#参考)
@@ -94,7 +97,7 @@ Redis 8.4 新增了 `DELEX lock_key IFEQ unique_value` 指令，可以直接原
RedLock 依赖各个节点的时钟基本同步，并且无法应对进程暂停（例如 GC）导致锁过期后客户端仍然认为自己持有锁的情况，因此存在争议。更可靠的做法是让锁服务每次加锁时返回一个单调递增的栅栏令牌（Fencing Token），客户端访问资源时带上令牌，资源拒绝令牌比已处理过的更小的请求。
-w 、yl 分别是较好和较差的回答，πref 是参考模型，β 控制偏离参考模型的程度：
+
+```text
+loss = -log σ( β × [ (log π(y_w|x) - log π_ref(y_w|x)) - (log π(y_l|x) - log π_ref(y_l|x)) ] )
+```
+
+训练开始时模型与参考模型相同，括号内为 0，损失是 log 2 ≈ 0.693。取 β = 0.1，如果训练后较好回答的对数概率比参考模型高了 2，较差回答的低了 1，括号内为 3，损失降为 -log σ(0.3) ≈ 0.554。也就是说，DPO 在拉高较好回答概率的同时压低较差回答的概率，是一个二分类问题。
+
+GRPO 的优势计算举例：对一道数学题生成 4 个回答，答对得 1 分、答错得 0 分，得分为 [1, 0, 0, 1]，平均分 0.5、标准差 0.5，每个回答的优势 (得分 - 平均分) / 标准差 为 [1, -1, -1, 1]，答对的回答被强化，答错的被抑制。如果 4 个回答全对或全错，优势都是 0，这道题对训练没有贡献，所以题目的难度要适中。数学、代码这类能自动判断对错的任务可以直接用规则打分，不需要奖励模型。
+
+三者的选择：DPO 实现简单、训练稳定，适合已有偏好数据的对齐；PPO 和 GRPO 在训练中生成新的回答，能探索出训练数据之外的更好回答，推理能力的训练通常使用 GRPO 这类强化学习方法。
+
### 微调
微调指的是用特定任务的数据继续训练模型。全量微调要更新所有参数，7B 模型的参数、梯度和优化器状态加起来需要上百 GB 显存。
@@ -291,6 +318,8 @@ RAG、微调和提示词解决的是不同的问题：
需要注意的是，截断历史时工具调用和它的结果要成对保留或者成对删除。只剩下结果而缺少对应的调用时，很多接口会直接报错。
+闲聊、客服这类前后轮关系不大的对话，用滑动窗口就够了，简单且不需要额外调用模型；Agent 执行长任务时，早期做出的决定和用户提出的约束一直有用，适合摘要加外置。压缩有没有丢掉关键信息，可以准备一组依赖早期对话才能回答的问题（例如“用户一开始要求的输出格式是什么”），分别用压缩前和压缩后的上下文回答，比较正确率。
+
## 三、检索增强生成
检索增强生成（Retrieval-Augmented Generation, RAG）指的是先从知识库中检索与问题相关的资料，再把资料和问题一起交给模型生成回答。它用于解决模型不了解私有数据和最新数据的问题，也能减少幻觉，回答还可以附上来源。
@@ -340,6 +369,8 @@ c = “今天股价上涨了” (0.6, -0.8) cos(a, c) = 0.48 - 0.48 = 0
a 和 b 几乎没有相同的字，相似度却很高，这正是向量检索相比关键词检索的优势。向量通常会归一化为长度 1，这时余弦相似度等于点积，计算更快。
+用真实的模型计算，结论相同但数值没有这么极端：用 bge-small-zh-v1.5（512 维）编码这三句话，“怎么申请年假”与“休假的流程是什么”的余弦相似度为 0.603，与“今天股价上涨了”为 0.194。实际系统中不同句子的相似度大多落在一个不太宽的区间里，判断是否相关要看排名和阈值，而不是期望不相关的结果接近 0。
+
检索时把问题也转为向量，找出与它最相似的 K 个切片，称为 Top-K 检索。问题和切片必须使用同一个 Embedding 模型，更换模型后所有切片都要重新计算向量。
### 向量索引
@@ -367,6 +398,8 @@ a 和 b 几乎没有相同的字，相似度却很高，这正是向量检索相
Elasticsearch 中 BM25 的参数 k1 和 b 默认为 1.2 和 0.75，分别控制词频的饱和速度和文档长度的影响程度。
+用同一个例子对比两种检索。查询“错误码 E1024 是什么意思”，候选文档是“错误码 E1024：库存不足”和“错误码 E1025：支付超时”：bge-small-zh 给出的相似度分别为 0.813 和 0.795，几乎分不开；BM25 中“错误码”出现在每篇文档里，逆文档频率很低，E1024 只出现在一篇文档中，权重高得多。在这两篇加一篇“常见错误码说明”组成的小语料上，按 k1 = 1.2、b = 0.75 计算，第一篇得 1.114 分，第二篇只有 0.134 分。
+
因此通常两路同时召回，再合并结果。两路的分数不能直接相加，BM25 的分数没有上限，余弦相似度在 -1 到 1 之间。倒数排名融合（Reciprocal Rank Fusion, RRF）只看排名：文档的得分是它在各路结果中排名的倒数之和，即 Σ 1 / (k + rank)，k 通常取 60。例如：
| 文档 | 向量检索排名 | BM25 排名 | RRF 得分 |
@@ -470,20 +503,20 @@ Agent（智能体）指的是让大模型通过调用工具来完成任务的系
可见工具调用本质上仍然是生成文本，所以模型可能写错参数、调用不存在的工具，应用必须先校验再执行。很多服务提供严格模式，用约束解码保证参数符合 Schema。
-以 OpenAI 兼容的接口为例，请求中这样描述工具：
+以 OpenAI 兼容的接口为例，用户问“订单 1024 到哪了”，请求中这样描述查询订单的工具（省略了查询物流的 get_logistics）：
```json
"tools": [{
"type": "function",
"function": {
- "name": "get_weather",
- "description": "查询城市当天的天气。用户询问天气、气温时使用",
+ "name": "get_order",
+ "description": "按订单号查询订单状态和运单号。用户询问订单、发货情况时使用",
"parameters": {
"type": "object",
"properties": {
- "city": {"type": "string", "description": "城市名，例如 杭州"}
+ "order_id": {"type": "string", "description": "订单号，例如 1024"}
},
- "required": ["city"]
+ "required": ["order_id"]
}
}
}]
@@ -494,16 +527,22 @@ Agent（智能体）指的是让大模型通过调用工具来完成任务的系
```json
{"role": "assistant", "tool_calls": [{
"id": "call_1", "type": "function",
- "function": {"name": "get_weather", "arguments": "{\"city\": \"杭州\"}"}
+ "function": {"name": "get_order", "arguments": "{\"order_id\": \"1024\"}"}
}]}
```
应用执行函数后，用 tool 角色的消息把结果发回。一次回复中可能包含多个调用，tool_call_id 用于对应是哪一次调用：
```json
-{"role": "tool", "tool_call_id": "call_1", "content": "{\"weather\": \"晴\", \"temp\": 26}"}
+{"role": "tool", "tool_call_id": "call_1", "content": "{\"status\": \"已发货\", \"tracking_no\": \"SF1234567\"}"}
```
+这些结构化的字段只存在于接口中。在本机用 Qwen2.5-7B-Instruct 和 Hugging Face Transformers 运行“订单 1024 到哪了”这个例子，可以直接看到模型收到和输出的原始文本：
+
+8 ≈ 43%。面向用户的 Agent 每次都要做对，更应该关注 pass^k。该论文中 GPT-4o 在零售场景的任务上成功率不到 50%，pass^8 不到 25%。
+
每次修改提示词、工具或者模型，都在同一批任务上回归，并记录每次运行的完整轨迹，出错时才能复现和定位。
## 五、工程实践
@@ -772,6 +905,7 @@ static void stream(HttpClient client, HttpRequest request, Consumer onDa
- Nginx 等反向代理默认会缓冲上游的响应，流式输出变成了一次性输出，需要关闭缓冲，例如在响应头中加上 X-Accel-Buffering: no；
- 网关和负载均衡的读超时要大于最长的生成时间；
- 用户关闭页面后要及时取消对模型的请求，否则仍在消耗 Token；
+- 网络抖动导致断线时，模型的生成无法从中途重新开始。需要续传时，让生成任务与连接解耦：生成的内容按会话和事件编号写入 Redis 等缓存，客户端带着 Last-Event-ID 重连后，先从缓存中补发之后的事件，再继续推送新的内容，超时没有重连再取消生成；
- 工具调用的参数也是分片段流式返回的，需要按调用的序号拼接，生成结束后才能解析出完整的 JSON。
### 延迟与成本
@@ -794,6 +928,18 @@ Agent 的成本会随步数快速增长，因为每一步都要把完整的历
自己部署模型时，vLLM 等推理框架通过连续批处理提高吞吐量：每生成一步就把已完成的请求移出批次、把新请求加入，而不是等整批请求全部生成结束。
+自己部署时，显存首先被模型权重占用。量化指的是用更少的位数存储权重，例如把 4 个 BF16 权重量化为 INT8，取绝对值最大的 1.20 除以 127 作为缩放系数 s ≈ 0.00945，每个权重除以 s 后取整：
+
+```text
+原始权重 0.12 -0.53 0.97 -1.20
+INT8 13 -56 103 -127
+还原（× s） 0.1228 -0.5291 0.9732 -1.2000
+```
+
+误差在 0.003 左右；同样的权重量化为 INT4（-7～7）时还原为 0.171、-0.514、1.029、-1.2，误差明显变大。GPTQ、AWQ 等方法在量化时用少量校准数据减小误差，例如 AWQ 根据激活值找出对结果影响大的那部分权重，保护它们的精度。
+
+以 Qwen2.5-7B（7.61B 参数）为例，权重在 BF16 下约 15.2 GB，INT8 约 7.6 GB，INT4 约 3.8 GB。在一张 24 GB 的显卡上，BF16 时只剩约 8.8 GB 放 KV Cache，按每个 Token 56 KB 计算约 15 万个 Token；INT4 时剩约 20 GB，能放约 35 万个 Token，可以同时服务更多的请求。代价是精度下降，量化后要在自己的任务上重新评测。
+
### 稳定性
- 限流与重试：模型服务会限制请求频率和 Token 速率，超限时返回 429 状态码，需要按指数退避重试；
@@ -826,6 +972,9 @@ Agent 的成本会随步数快速增长，因为每一步都要把完整的历
- [The Curious Case of Neural Text Degeneration](https://arxiv.org/abs/1904.09751)
- [Training Language Models to Follow Instructions with Human Feedback](https://arxiv.org/abs/2203.02155)
- [Direct Preference Optimization: Your Language Model is Secretly a Reward Model](https://arxiv.org/abs/2305.18290)
+- [DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models](https://arxiv.org/abs/2402.03300)
+- [AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration](https://arxiv.org/abs/2306.00978)
+- [GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers](https://arxiv.org/abs/2210.17323)
- [LoRA: Low-Rank Adaptation of Large Language Models](https://arxiv.org/abs/2106.09685)
- [QLoRA: Efficient Finetuning of Quantized LLMs](https://arxiv.org/abs/2305.14314)
- [DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning](https://arxiv.org/abs/2501.12948)
@@ -845,6 +994,11 @@ Agent 的成本会随步数快速增长，因为每一步都要把完整的历
- [ReAct: Synergizing Reasoning and Acting in Language Models](https://arxiv.org/abs/2210.03629)
- [LLM Powered Autonomous Agents](https://lilianweng.github.io/posts/2023-06-23-agent/)
- [Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents)
+- [Effective Harnesses for Long-Running Agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)
+- [Harness Engineering for Coding Agent Users](https://martinfowler.com/articles/harness-engineering.html)
+- [The Anatomy of an Agent Harness](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness)
+- [ArchUnit User Guide](https://www.archunit.org/userguide/html/000_Index.html)
+- [Claude Docs: Tool Search Tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool)
- [How We Built Our Multi-Agent Research System](https://www.anthropic.com/engineering/multi-agent-research-system)
- [DeepSeek API 文档：Tool Calls](https://api-docs.deepseek.com/zh-cn/guides/tool_calls)
- [Qwen2.5-7B-Instruct 对话模板](https://huggingface.co/Qwen/Qwen2.5-7B-Instruct/blob/main/tokenizer_config.json)
@@ -857,3 +1011,6 @@ Agent 的成本会随步数快速增长，因为每一步都要把完整的历
- [Nginx: proxy_buffering](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering)
- [Orca: A Distributed Serving System for Transformer-Based Generative Models](https://www.usenix.org/conference/osdi22/presentation/yu)
- [OWASP Top 10 for LLM Applications: Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)
+- [τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains](https://arxiv.org/abs/2406.12045)
+- [How Claude Code works](https://code.claude.com/docs/en/how-claude-code-works)
+- [How Claude remembers your project](https://code.claude.com/docs/en/memory)
diff --git "a/notes/\346\224\273\345\207\273\346\212\200\346\234\257.md" "b/notes/\346\224\273\345\207\273\346\212\200\346\234\257.md"
index 9c56e27c9..ec3bfea87 100644
--- "a/notes/\346\224\273\345\207\273\346\212\200\346\234\257.md"
+++ "b/notes/\346\224\273\345\207\273\346\212\200\346\234\257.md"
@@ -194,6 +194,14 @@ stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();
```
+需要注意的是，MySQL 的 JDBC 驱动（Connector/J）默认并不在服务器上预编译，而是在客户端把参数中的单引号等字符转义后，拼成完整的语句发送。在本机用 Connector/J 8.3 执行上面的查询，两个参数都传入 1' OR '1'='1，MySQL 通用查询日志中记录的是：
+
+```text
+Query SELECT * FROM users WHERE name = '1'' OR ''1''=''1' AND pw = '1'' OR ''1''=''1'
+```
+
+参数仍然只是一个普通的字符串，查询结果为空。连接参数加上 useServerPrepStmts=true 后，驱动才会先发送 Prepare、再发送 Execute。两种方式都能防止注入，关键在于参数由驱动或数据库处理，而不是由开发者拼接。表名、列名和 ORDER BY 的字段不能使用占位符，只能用白名单校验，见 [MyBatis 的 #{} 和 ${}](Spring.md#-和--的区别)。
+
#### 2. 单引号转换
将传入的参数中的单引号转换为连续两个单引号。PHP 的 Magic Quotes 曾经自动完成这个功能，但是因为不可靠已经被移除，应该使用数据库驱动提供的转义函数，并且只在无法使用参数化查询时使用。
diff --git "a/notes/\346\225\260\346\215\256\345\272\223\347\263\273\347\273\237\345\216\237\347\220\206.md" "b/notes/\346\225\260\346\215\256\345\272\223\347\263\273\347\273\237\345\216\237\347\220\206.md"
index 59006f300..8192a1991 100644
--- "a/notes/\346\225\260\346\215\256\345\272\223\347\263\273\347\273\237\345\216\237\347\220\206.md"
+++ "b/notes/\346\225\260\346\215\256\345\272\223\347\263\273\347\273\237\345\216\237\347\220\206.md"
@@ -49,7 +49,7 @@
事务指的是满足 ACID 特性的一组操作，可以通过 Commit 提交一个事务，也可以使用 Rollback 进行回滚。
-1 和 T2 两个事务都对一个数据进行修改，T1 先修改并提交生效，T2 随后修改，T2 的修改覆盖了 T1 的修改。
+丢失修改指一个事务的更新操作被另外一个事务的更新操作替换。例如：T1 和 T2 先后读到余额为 100，T1 取出 30 元，写回 70 并提交；T2 存入 50 元，在它读到的 100 的基础上写回 150，T1 的修改被覆盖了。
-1 修改一个数据但未提交，T2 随后读取这个数据。如果 T1 撤销了这次修改，那么 T2 读取的数据是脏数据。
-2 读取一个数据，T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。
-1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。
+幻读本质上也属于不可重复读的情况，T2 读取某个范围的数据，T1 在这个范围内插入新的数据，T2 再次读取这个范围的数据，此时读取的结果和第一次读取的结果不同。
-6 ≈ 568 亿个短码，每天新增 1 亿个也能用一年半。
+
+发号器通常用 [数据库号段](分布式.md#八分布式-id)：每个实例一次领取 1000 个 ID 在内存中使用，用完再领。雪花算法生成的 ID 是 64 位的大整数，转成 Base62 也有 11 位，用在短链中太长。需要注意的是，自增 ID 得到的短码是连续的，100000001 对应 6LAzf，别人可以据此遍历出其他短链；对隐私敏感的链接可以改用随机的方法，或者加上有效期和访问权限。
+
+### 跳转用 301 还是 302
+
+301 表示永久跳转，响应默认可以被缓存，浏览器之后会直接跳到长链接；302 表示临时跳转，每次访问都会请求短链服务。在本机用 Edge 访问同一个短链两次：返回 301 时，第二次直接跳到了长链接，服务端只收到一次请求；返回 302 时，两次都请求了服务端。
+
+需要统计点击量、允许修改目标地址或者设置有效期时用 302；只想减轻服务端的压力时可以用 301。
+
+### 存储与缓存
+
+```sql
+CREATE TABLE short_url (
+ code VARCHAR(8) PRIMARY KEY,
+ long_url VARCHAR(2048) NOT NULL,
+ url_hash BINARY(16) NOT NULL, -- 长链接的 MD5，用于查找同一个长链接是否已经生成过
+ expire_at DATETIME,
+ KEY idx_url_hash (url_hash)
+);
+```
+
+长链接最长可能有几千个字符，直接在 long_url 上建唯一索引会报错 Specified key was too long（InnoDB 索引最长 3072 字节），所以另存一列 16 字节的 MD5 建索引，查到后再比较完整的长链接。
+
+短链读多写少，热门链接的访问又很集中，适合用 Redis 缓存短码到长链接的映射。不存在的短码会穿透到数据库，可以缓存空值或者使用布隆过滤器，见 [缓存穿透](缓存.md#缓存穿透)。点击统计不要在跳转时同步写数据库，而是把点击事件写入消息队列，异步汇总。
+
+## 九、Feed 流
+
+Feed 流指的是把关注的人发布的内容按时间倒序合并后展示，例如朋友圈和微博的首页。每个用户有一个发件箱，保存自己发的帖子；难点在于怎样把几百个人的发件箱合成一个首页。
+
+ cache = Caffeine.newBuilder()
+ .maximumSize(10_000) // 最多 1 万个，超出时淘汰
+ .expireAfterWrite(Duration.ofSeconds(30)) // 写入 30 秒后过期
+ .build();
+
+Product p = cache.get("product:1024", key -> loadFromRedisOrDb(key));
+```
+
+它的淘汰算法 W-TinyLFU 同时考虑访问频率和最近访问时间，命中率通常高于 LRU；get 传入的加载函数对同一个键只会执行一次，其它并发的请求等待它的结果，避免缓存未命中时大量请求同时查询下游。
+
### 数据库缓存
MySQL 等数据库管理系统具有自己的缓存机制来提高查询效率，例如 InnoDB 的 Buffer Pool 将数据页和索引页缓存在内存中。MySQL 的查询缓存因为命中率低、维护开销大，已经在 8.0 版本中被移除。
@@ -84,7 +111,7 @@ CDN 主要有以下优点：
- 通过部署多台服务器，从而提高系统整体的带宽性能；
- 多台服务器可以看成是一种冗余机制，从而具有高可用性。
-n -1] 看成一个哈希环，每个服务器节点都通过哈希配置到哈希环上。每个数据对象通过哈希函数得到哈希值之后，存放到哈希环中顺时针方向第一个大于等于该哈希值的节点上。
- implements Iterable {
- [How Aspiration CDN helps to improve your website loading speed?](https://www.aspirationhosting.com/aspiration-cdn/)
- [Redis: UNLINK](https://redis.io/docs/latest/commands/unlink/)
- [Redis CLI](https://redis.io/docs/latest/develop/tools/cli/)
+- [Caffeine Wiki](https://github.com/ben-manes/caffeine/wiki)
diff --git "a/notes/\350\256\241\347\256\227\346\234\272\346\223\215\344\275\234\347\263\273\347\273\237 - \345\206\205\345\255\230\347\256\241\347\220\206.md" "b/notes/\350\256\241\347\256\227\346\234\272\346\223\215\344\275\234\347\263\273\347\273\237 - \345\206\205\345\255\230\347\256\241\347\220\206.md"
index 61eb50688..b00a61130 100644
--- "a/notes/\350\256\241\347\256\227\346\234\272\346\223\215\344\275\234\347\263\273\347\273\237 - \345\206\205\345\255\230\347\256\241\347\220\206.md"
+++ "b/notes/\350\256\241\347\256\227\346\234\272\346\223\215\344\275\234\347\263\273\347\273\237 - \345\206\205\345\255\230\347\256\241\347\220\206.md"
@@ -18,13 +18,13 @@
## 虚拟内存
-虚拟内存的目的是为了让物理内存扩充成更大的逻辑内存，从而让程序获得更多的可用内存。
+虚拟内存的目的是为了让物理内存扩充成更大的逻辑内存，从而让程序获得更多的可用内存。此外，每个进程都有独立的地址空间，一个进程无法直接访问另一个进程的内存，操作系统还可以按页设置读写和执行权限。
-为了更好的管理内存，操作系统将内存抽象成地址空间。每个程序拥有自己的地址空间，这个地址空间被分割成多个块，每一块称为一页。这些页被映射到物理内存，但不需要映射到连续的物理内存，也不需要所有页都必须在物理内存中。当程序引用到不在物理内存中的页时，由硬件执行必要的映射，将缺失的部分装入物理内存并重新执行失败的指令。
+为了更好的管理内存，操作系统将内存抽象成地址空间。每个程序拥有自己的地址空间，这个地址空间被分割成多个块，每一块称为一页。这些页被映射到物理内存，但不需要映射到连续的物理内存，也不需要所有页都必须在物理内存中。当程序引用到不在物理内存中的页时，硬件触发缺页中断，由操作系统将缺失的页装入物理内存，再重新执行失败的指令。
从上面的描述中可以看出，虚拟内存允许程序不用将地址空间中的每一页都映射到物理内存，也就是说一个程序不需要全部调入内存就可以运行，这使得有限的内存运行大程序成为可能。例如有一台计算机可以产生 16 位地址，那么一个程序的地址空间范围是 0\~64K。该计算机只有 32KB 的物理内存，虚拟内存技术允许该计算机运行一个 64K 大小的程序。
-1 和 P2 所请求的资源都得不到满足，只有进程 P3 可以，让 P3 执行，之后释放 P3 拥有的资源，此时 A = (2 2 2 0)。P2 可以执行，执行后释放 P2 拥有的资源，A = (4 2 2 1) 。P1 也可以执行。所有进程都可以顺利执行，没有死锁。
+进程 P1 和 P3 所请求的资源都得不到满足，只有进程 P2 可以，让 P2 执行，之后释放 P2 拥有的资源，此时 A = (3 1 2)。P1 可以执行，执行后释放 P1 拥有的资源，A = (4 2 2)。P3 也可以执行。所有进程都可以顺利执行，没有死锁。
算法总结如下：
@@ -115,9 +119,9 @@
### 1. 安全状态
-8 = 0.12 ms；光纤中信号的传播速度约为 2 × 108 m/s，北京到广州约 2000 km 的线路传播时延约为 10 ms。传输时延取决于数据量和带宽，传播时延只取决于距离，提高带宽不能缩短传播时延。
## 计算机网络体系结构
diff --git "a/notes/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234 - \347\211\251\347\220\206\345\261\202.md" "b/notes/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234 - \347\211\251\347\220\206\345\261\202.md"
index 2a10290f4..b751e3962 100644
--- "a/notes/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234 - \347\211\251\347\220\206\345\261\202.md"
+++ "b/notes/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234 - \347\211\251\347\220\206\345\261\202.md"
@@ -18,5 +18,9 @@
模拟信号是连续的信号，数字信号是离散的信号。带通调制把数字信号转换为模拟信号。
-
+
+
+
+
+
+
+
+
+
+ ACID：原子性、隔离性、持久性是手段，一致性是目的
+ 原子性
+ undo log 回滚
+ 隔离性
+ 锁和 MVCC
+ 持久性
+ redo log 刷盘
+ 一致性
+ 满足约束和业务规则
+ 没有并发时
+ 有并发时还需要
+ 事务的结果正确
+ 系统崩溃后
+ 已提交的修改不丢失
+ 例如转账：原子性保证不会只扣款不入账，隔离性保证并发的转账互不干扰，持久性保证提交之后断电也不丢。
+
diff --git a/tools/diagram/src/adapter-turkey.svg b/tools/diagram/src/adapter-turkey.svg
new file mode 100644
index 000000000..91d93d1c3
--- /dev/null
+++ b/tools/diagram/src/adapter-turkey.svg
@@ -0,0 +1,52 @@
+
+
+
+
+
+
+
+
+
+
+ 适配器：让火鸡冒充鸭子
+ 客户端
+ 只认 Duck 接口
+ quack()
+ TurkeyAdapter
+ implements Duck
+ quack() → gobble()
+ gobble()
+ WildTurkey
+ gobble()
+ 输出 gobble!
+ 适配器实现客户端需要的接口，内部持有被适配的对象，把调用转换过去；两边的代码都不用修改。
+
diff --git a/tools/diagram/src/cdn.svg b/tools/diagram/src/cdn.svg
new file mode 100644
index 000000000..8df0e3561
--- /dev/null
+++ b/tools/diagram/src/cdn.svg
@@ -0,0 +1,75 @@
+
+
+
+
+
+
+
+
+
+
+ CDN：用户访问离自己最近的节点
+ 杭州的用户
+ DNS 调度
+ 返回杭州节点的 IP
+ CDN 杭州节点
+ 缓存了 logo.png
+ 源站（北京）
+ ① 解析 img.example.com
+ ② 请求 logo.png
+ ③ 未命中时回源，取回后缓存
+ ④ 返回，命中时不经过源站
+ 静态资源由离用户最近的节点返回，延迟低，源站的带宽压力也小；资源更新后要刷新 CDN 缓存，或者在文件名中带上版本号。
+
diff --git a/tools/diagram/src/cert-chain.svg b/tools/diagram/src/cert-chain.svg
new file mode 100644
index 000000000..fbcda6c8d
--- /dev/null
+++ b/tools/diagram/src/cert-chain.svg
@@ -0,0 +1,58 @@
+
+
+
+
+
+
+
+
+
+
+ 证书链：www.baidu.com 的证书如何被信任
+ 服务器证书
+ baidu.com
+ 公钥：RSA 2048 位
+ 有效期 2026-07-09 ～ 2027-01-24
+ 中间证书
+ GlobalSign RSA OV SSL CA 2018
+ 由根证书签名
+ 随服务器证书一起发送
+ 根证书
+ GlobalSign Root R3
+ 自签名
+ 预装在操作系统的信任列表中
+ 用中间证书的公钥验证服务器证书的签名
+ 用根证书的公钥验证中间证书
+ 浏览器还要检查：访问的域名 www.baidu.com 与证书中的域名匹配（Subject Alternative Name 中有 *.baidu.com），
+ 证书在有效期内且没有被吊销。任何一步失败都会提示“连接不是私密连接”。
+ 证书和签名是公开的，伪造者拿不到 CA 的私钥，就无法为自己的公钥生成有效签名。
+
diff --git a/tools/diagram/src/clock.svg b/tools/diagram/src/clock.svg
new file mode 100644
index 000000000..fbbe6153e
--- /dev/null
+++ b/tools/diagram/src/clock.svg
@@ -0,0 +1,61 @@
+
+
+
+
+
+
+
+
+
+
+ 时钟算法：用环形链表代替移动页面
+ A R=1
+ B R=0
+ C R=1
+ D R=1
+ E R=0
+ F R=1
+ G R=0
+ H R=1
+ 指针
+ 发生缺页时，从指针处开始检查：
+ C 的 R = 1：清零，指针前进
+ D 的 R = 1：清零，指针前进
+ E 的 R = 0：换出 E，新页面放在这里，
+ 指针指向 F
+ 效果与第二次机会相同，但只移动指针，
+ 不用在链表中移动页面。
+ 图中灰色的 C、D 在这次检查中被清零；淡紫色的 E 被换出。
+
diff --git a/tools/diagram/src/coding-agent.svg b/tools/diagram/src/coding-agent.svg
new file mode 100644
index 000000000..108cfbb8c
--- /dev/null
+++ b/tools/diagram/src/coding-agent.svg
@@ -0,0 +1,82 @@
+
+
+
+
+
+
+
+
+
+
+ AI 编程助手修复一个失败的测试（示意）
+ 开发者
+ “OrderServiceTest 挂了，修一下”
+ 收集上下文
+ Bash
+ mvn test → 1 个测试失败：期望 59.9，实际 0.0
+ Grep
+ grep -rn "calcAmount" src/ → OrderService.java:42
+ Read
+ 读取 OrderService.java 第 30～60 行
+ 修改
+ Edit
+ 把 discount 为 null 时的分支改为按原价计算
+ 验证
+ Bash
+ mvn test → 全部通过
+ 失败就
+ 继续循环
+ 每一步都是一次模型调用：模型选择工具，应用执行后把输出放回上下文。
+ 上下文中有什么
+ 系统提示词、工具定义
+ CLAUDE.md 等项目约定
+ 对话和每次工具的输出
+ 接近上限时压缩为摘要
+ 子 Agent 在自己的上下文中
+ 搜索大量文件，只返回结论
+ 修改文件前自动保存快照，可以撤销；执行命令、修改文件前按权限设置决定是否请求开发者确认。
+
diff --git a/tools/diagram/src/command-remote.svg b/tools/diagram/src/command-remote.svg
new file mode 100644
index 000000000..369780ef7
--- /dev/null
+++ b/tools/diagram/src/command-remote.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+
+
+
+
+ 命令：遥控器只认 Command 接口
+ Invoker（遥控器）
+ on[0]
+ off[0]
+ on[1]
+ off[1]
+ on[2]
+ off[2]
+ on[3]
+ off[3]
+ LightOnCommand
+ execute() { light.on(); }
+ LightOffCommand
+ execute() { light.off(); }
+ Light（接收者）
+ on()
+ off()
+ onButtonWasPushed(0) 只调用 onCommands[0].execute()，不知道背后是电灯还是空调；换一个命令对象，按钮就有了新功能。
+
diff --git a/tools/diagram/src/compile-pipeline.svg b/tools/diagram/src/compile-pipeline.svg
new file mode 100644
index 000000000..81cc14c1e
--- /dev/null
+++ b/tools/diagram/src/compile-pipeline.svg
@@ -0,0 +1,89 @@
+
+
+
+
+
+
+
+
+
+
+ gcc -o hello hello.c 的四个阶段
+ hello.c
+ 源程序
+ 预处理器 cpp
+ gcc -E
+ hello.i
+ 预处理后的源程序
+ 编译器 cc1
+ gcc -S
+ hello.s
+ 汇编程序
+ 汇编器 as
+ gcc -c
+ hello.o
+ 可重定位目标文件
+ 链接器 ld
+ hello
+ 可执行目标文件
+ printf.o 等
+ 库中的目标文件
+ 前三步各自可以用 gcc 的选项单独执行；.i、.s 是文本文件，.o 和 hello 是二进制的 ELF 文件。
+
diff --git a/tools/diagram/src/consistent-hash.svg b/tools/diagram/src/consistent-hash.svg
new file mode 100644
index 000000000..1957ef122
--- /dev/null
+++ b/tools/diagram/src/consistent-hash.svg
@@ -0,0 +1,83 @@
+
+
+
+
+
+
+
+
+
+
+ 一致性哈希：数据放在顺时针方向的第一个节点上
+ A
+ B
+ C
+ D
+ k1
+ k2
+ k3
+ k4
+ X
+ 新增 X
+ 哈希环
+ 0 ～ 2³² − 1
+ 顺时针找第一个节点：k1 → B，k2、k3 → C，k4 → D。
+ 在 B、C 之间新增 X 后，只有 k2 改由 X 负责，
+ k3 和其它节点上的数据都不动。
+ 10 万个键（MD5 取前 32 位）的实测结果
+ 每节点 1 个点
+ 每节点 150 个
+ 最多 / 最少
+ 41.6 倍
+ 1.17 倍
+ 新增 1 个节点迁移
+ 33.8%
+ 20.7%
+ 4 个节点各放 1 个点时，位置是随机的，最多的节点分到
+ 55.4% 的键，最少的只有 1.3%；新增节点后应迁移约 1/5，
+ 实际迁移了 33.8%。每个节点放 150 个虚拟节点后就接近均匀。
+ 对比：hash % 4 改为 hash % 5，79.7% 的键要迁移。
+ 左图是示意，节点位置不按比例；右表是实际计算的结果。
+
diff --git a/tools/diagram/src/crypto-asymmetric.svg b/tools/diagram/src/crypto-asymmetric.svg
new file mode 100644
index 000000000..3c7c6842a
--- /dev/null
+++ b/tools/diagram/src/crypto-asymmetric.svg
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+
+
+
+
+ 非对称加密：公钥加密、私钥解密；私钥签名、公钥验证
+ 加密
+ 会话密钥
+ 服务器公钥
+ 密文 256 字节
+ 服务器私钥
+ 会话密钥
+ 任何人都能用公钥加密，只有持有私钥的服务器能解开
+ 签名
+ 证书内容
+ CA 私钥签名
+ 签名
+ CA 公钥验证
+ 签名有效
+ 只有 CA 能生成签名，任何人都能用 CA 的公钥检查，内容改动一个字节签名就对不上
+ 2048 位 RSA 的密文和签名都是 256 字节。非对称运算比对称加密慢得多，所以只用在握手阶段。
+
diff --git a/tools/diagram/src/crypto-symmetric.svg b/tools/diagram/src/crypto-symmetric.svg
new file mode 100644
index 000000000..2978ca6a2
--- /dev/null
+++ b/tools/diagram/src/crypto-symmetric.svg
@@ -0,0 +1,50 @@
+
+
+
+
+
+
+
+
+
+
+ 对称加密：加密和解密用同一个密钥
+ 转账 100 元
+ AES 加密
+ c0b9bea2112248bbc17e8d6a15e542de
+ AES 解密
+ 转账 100 元
+ 同一个密钥 K = 000102…0e0f（16 字节）
+ 用 openssl 实际计算（AES-128-CBC）：14 字节的明文补齐到 16 字节；没有 K 无法还原，但 K 本身怎样安全地交给对方是个问题。
+
diff --git a/tools/diagram/src/deadlock-banker-multi.svg b/tools/diagram/src/deadlock-banker-multi.svg
new file mode 100644
index 000000000..a02a79619
--- /dev/null
+++ b/tools/diagram/src/deadlock-banker-multi.svg
@@ -0,0 +1,121 @@
+
+
+
+
+
+
+
+
+
+
+ 多个资源的银行家算法：找出一个安全序列
+ E 总量
+ 9
+ 5
+ 7
+ Available
+ 1
+ 1
+ 2
+ Allocation 已分配
+ P1
+ 2
+ 1
+ 1
+ P2
+ 3
+ 0
+ 2
+ P3
+ 1
+ 2
+ 1
+ P4
+ 2
+ 1
+ 1
+ Need 还需要
+ P1
+ 3
+ 2
+ 2
+ P2
+ 1
+ 0
+ 2
+ P3
+ 5
+ 2
+ 0
+ P4
+ 0
+ 1
+ 1
+ 安全序列 P2 → P4 → P1 → P3
+ 1. P2 需要 (1 0 2) ≤ (1 1 2)
+ 归还后 Available = (4 1 4)
+ 2. P4 需要 (0 1 1) ≤ (4 1 4)
+ 归还后 Available = (6 2 5)
+ 3. P1 需要 (3 2 2) ≤ (6 2 5)
+ 归还后 Available = (8 3 6)
+ 4. P3 需要 (5 2 0) ≤ (8 3 6)
+ 归还后 Available = (9 5 7)
+ Need = 最大需求 − 已分配。一开始只有 P2 的需求能被满足，P1 缺 R2、P3 缺 R1；
+ 收到新的申请时，先假设分配，再用这个方法检查，找不到安全序列就拒绝。
+
diff --git a/tools/diagram/src/deadlock-banker-single.svg b/tools/diagram/src/deadlock-banker-single.svg
new file mode 100644
index 000000000..eac2d55f6
--- /dev/null
+++ b/tools/diagram/src/deadlock-banker-single.svg
@@ -0,0 +1,84 @@
+
+
+
+
+
+
+
+
+
+
+ 单个资源的银行家算法：共 12 个，分配前先检查分配后是否安全
+ (a) 当前状态
+ A
+ 3 / 8
+ B
+ 2 / 4
+ C
+ 4 / 9
+ Free 3
+ 安全：B → A → C
+ (b) C 再申请 2 个
+ A
+ 3 / 8
+ B
+ 2 / 4
+ C
+ 6 / 9
+ Free 1
+ 不安全：谁都补不齐，拒绝
+ (c) B 再申请 1 个
+ A
+ 3 / 8
+ B
+ 3 / 4
+ C
+ 4 / 9
+ Free 2
+ 安全：B → A → C，分配
+ (b) 中 A、B、C 分别还需要 5、2、3 个，Free 只有 1，任何进程都无法运行完，可能发生死锁，所以拒绝这次申请，
+ 让 C 等待；(c) 中 B 只差 1 个，运行完归还 4 个后 Free = 5，A 和 C 也能依次完成，所以可以分配。
+
diff --git a/tools/diagram/src/deadlock-detect-graph.svg b/tools/diagram/src/deadlock-detect-graph.svg
new file mode 100644
index 000000000..23a2c3462
--- /dev/null
+++ b/tools/diagram/src/deadlock-detect-graph.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+
+
+
+
+
+ 每种资源只有一个：在资源分配图中找环
+ P1
+ P2
+ P3
+ P4
+ R1
+ R2
+ R3
+ R4
+ 资源指向进程表示已分配，进程指向资源表示正在请求。红色的边构成环 P1 → R1 → P2 → R2 → P3 → R3 → P1，
+ 三个进程互相等待，发生死锁；P4 不在环上，但它请求的 R2 被 P2 持有，也会一直等下去。
+
diff --git a/tools/diagram/src/deadlock-detect-matrix.svg b/tools/diagram/src/deadlock-detect-matrix.svg
new file mode 100644
index 000000000..29a497930
--- /dev/null
+++ b/tools/diagram/src/deadlock-detect-matrix.svg
@@ -0,0 +1,105 @@
+
+
+
+
+
+
+
+
+
+
+ 每种资源有多个：逐个找能满足请求的进程
+ 资源 R1、R2、R3
+ E 总量
+ 5
+ 3
+ 4
+ A 剩余
+ 1
+ 1
+ 1
+ C 已分配
+ P1
+ 1
+ 1
+ 0
+ P2
+ 2
+ 0
+ 1
+ P3
+ 1
+ 1
+ 2
+ R 还在请求
+ P1
+ 2
+ 0
+ 1
+ P2
+ 1
+ 1
+ 0
+ P3
+ 1
+ 2
+ 1
+ 按算法依次标记
+ 1. P2 请求 (1 1 0) ≤ A，可以运行
+ 结束后归还 (2 0 1)，A = (3 1 2)
+ 2. P1 请求 (2 0 1) ≤ A，可以运行
+ 结束后归还 (1 1 0)，A = (4 2 2)
+ 3. P3 请求 (1 2 1) ≤ A，可以运行
+ 结束后归还 (1 1 2)，A = (5 3 4)
+ 开始时 A 只满足 P2 的请求；P2 结束后归还资源，P1、P3 才依次得到满足。
+ 所有进程都能被标记，没有死锁；如果某一步找不到能满足的进程，剩下没被标记的进程就处于死锁中。
+
diff --git a/tools/diagram/src/deadlock-safe-state.svg b/tools/diagram/src/deadlock-safe-state.svg
new file mode 100644
index 000000000..747bd4727
--- /dev/null
+++ b/tools/diagram/src/deadlock-safe-state.svg
@@ -0,0 +1,85 @@
+
+
+
+
+
+
+
+
+
+
+ 安全状态：共 10 个资源，存在一个能让所有进程运行完的顺序
+ (a) 初始
+ A
+ 2 / 7
+ B
+ 3 / 5
+ C
+ 2 / 4
+ Free 3
+ (b) B 再拿 2 个，运行结束
+ A
+ 2 / 7
+ B
+ 已完成
+ C
+ 2 / 4
+ Free 6
+ (c) A 再拿 5 个，运行结束
+ A
+ 已完成
+ B
+ 已完成
+ C
+ 2 / 4
+ Free 8
+ (d) C 再拿 2 个，运行结束
+ A
+ 已完成
+ B
+ 已完成
+ C
+ 已完成
+ Free 10
+ 条形的长度是最大需求，浅蓝部分是已持有的数量。(a) 中 Free = 10 − 2 − 3 − 2 = 3，只够 B 补齐，
+ B 运行完归还 5 个后 Free = 6，又够 A 补齐 5 个，依此类推。
+ 安全不代表一定按这个顺序执行，只说明不管进程怎样申请，系统都能找到一条出路。
+
diff --git a/tools/diagram/src/deadlock-transfer.svg b/tools/diagram/src/deadlock-transfer.svg
new file mode 100644
index 000000000..2a85d548b
--- /dev/null
+++ b/tools/diagram/src/deadlock-transfer.svg
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+ 死锁：两个线程反向转账
+ T1
+ T2
+ alice
+ bob
+ 持有
+ 持有
+ 等待
+ 等待
+ transfer(alice, bob)
+ transfer(bob, alice)
+ 圆形是线程，方形是账户上的锁
+ 四个条件同时满足：
+ 互斥
+ 一把锁同一时刻只能被一个线程持有
+ 占有和等待
+ T1 持有 alice 的锁，还在等 bob 的锁
+ 不可抢占
+ bob 的锁只能由 T2 自己释放
+ 环路等待
+ T1 → bob → T2 → alice → T1
+
diff --git a/tools/diagram/src/decorator-cost.svg b/tools/diagram/src/decorator-cost.svg
new file mode 100644
index 000000000..99a06c499
--- /dev/null
+++ b/tools/diagram/src/decorator-cost.svg
@@ -0,0 +1,49 @@
+
+
+
+
+
+
+
+
+
+
+ 装饰者：一层套一层，cost() 由外向内调用
+ Milk
+ Mocha
+ HouseBlend
+ cost() = 1
+ cost() = 1 + 1
+ cost() = 1 + 2
+ ① Milk.cost() 调用 Mocha.cost()
+ ② Mocha.cost() 调用 HouseBlend.cost()
+ ③ HouseBlend 返回 1
+ ④ Mocha 返回 1 + 1 = 2
+ ⑤ Milk 返回 1 + 2 = 3，输出 3.0
+ Milk、Mocha 和 HouseBlend 都实现 Beverage，所以装饰者可以继续被装饰；new Milk(new Mocha(new HouseBlend()))。
+
diff --git a/tools/diagram/src/dhcp.svg b/tools/diagram/src/dhcp.svg
new file mode 100644
index 000000000..05108bcaa
--- /dev/null
+++ b/tools/diagram/src/dhcp.svg
@@ -0,0 +1,53 @@
+
+
+
+
+
+
+
+
+
+
+ DHCP：新接入的主机获取 IP 地址
+ 客户端（还没有 IP）
+ DHCP 服务器 192.168.1.1
+ ① Discover 0.0.0.0:68 → 255.255.255.255:67
+ 广播：有没有 DHCP 服务器？
+ ② Offer 可以用 192.168.1.100，租期 1 天
+ 附带子网掩码、网关、DNS 服务器
+ ③ Request 我要 192.168.1.1 提供的这个地址
+ 仍是广播，其它服务器收回提议
+ ④ Ack 确认，从现在起租期 1 天
+ 客户端开始使用这个地址
+ 前两步用广播是因为客户端还没有地址，也不知道服务器在哪；租期过半时客户端会向同一台服务器申请续租。
+
diff --git a/tools/diagram/src/disk-scan.svg b/tools/diagram/src/disk-scan.svg
new file mode 100644
index 000000000..58e09ed76
--- /dev/null
+++ b/tools/diagram/src/disk-scan.svg
@@ -0,0 +1,90 @@
+
+
+
+
+
+
+
+
+
+
+ 电梯算法：磁头在 50，先向磁道号增大的方向移动
+ 0
+ 10
+ 20
+ 30
+ 40
+ 50
+ 60
+ 70
+ 80
+ 90
+ 100
+ 磁道
+ 50
+ 56
+ 72
+ 81
+ 95
+ 44
+ 30
+ 12
+ 起点
+ 淡紫色点是待处理的请求。磁头移动的总距离为 128 个磁道。按先来先服务需要 318 个磁道。
+
diff --git a/tools/diagram/src/disk-sstf.svg b/tools/diagram/src/disk-sstf.svg
new file mode 100644
index 000000000..4cb4d76f4
--- /dev/null
+++ b/tools/diagram/src/disk-sstf.svg
@@ -0,0 +1,90 @@
+
+
+
+
+
+
+
+
+
+
+ 最短寻道时间优先：磁头在 50，请求 72、30、95、56、12、81、44
+ 0
+ 10
+ 20
+ 30
+ 40
+ 50
+ 60
+ 70
+ 80
+ 90
+ 100
+ 磁道
+ 50
+ 44
+ 56
+ 72
+ 81
+ 95
+ 30
+ 12
+ 起点
+ 淡紫色点是待处理的请求。磁头移动的总距离为 140 个磁道。30 和 12 离得远，一直被推后。
+
diff --git a/tools/diagram/src/dns-resolve.svg b/tools/diagram/src/dns-resolve.svg
new file mode 100644
index 000000000..b814d2490
--- /dev/null
+++ b/tools/diagram/src/dns-resolve.svg
@@ -0,0 +1,97 @@
+
+
+
+
+
+
+
+
+
+
+ DNS 解析 www.example.com
+ 主机
+ 先查浏览器缓存、
+ 系统缓存和 hosts
+ 本地 DNS 服务器
+ 运营商或公司提供
+ 根服务器
+ a.root-servers.net
+ 去问 com 的服务器
+ a.gtld-servers.net 等
+ com 顶级域服务器
+ a.gtld-servers.net
+ 去问 example.com 的服务器
+ hera.ns.cloudflare.com 等
+ 权威服务器
+ hera.ns.cloudflare.com
+ www.example.com 的 A 记录
+ 104.20.23.154，TTL 300
+ ① 递归查询
+ ④ 返回结果
+ ② 迭代查询：每台服务器
+ 只告诉下一步去问谁
+ ③ 按 TTL 缓存 300 秒
+ 图中的服务器和 TTL 是本机用 dig 逐级查询的结果：根服务器和 com 服务器返回的是下一级的 NS 记录（缓存 2 天），
+ 只有权威服务器的回答带有 aa（权威回答）标志。缓存命中时，前面任何一级都可以直接返回，不必走完全程。
+
diff --git a/tools/diagram/src/docker-layers.svg b/tools/diagram/src/docker-layers.svg
new file mode 100644
index 000000000..56d0a462b
--- /dev/null
+++ b/tools/diagram/src/docker-layers.svg
@@ -0,0 +1,49 @@
+
+
+
+
+
+
+
+
+
+
+ 镜像分层与容器的可写层
+ 容器的可写层：运行时的修改都写在这里
+ RUN pip install flask
+ COPY app.py /app/
+ FROM python:3.12-slim（基础镜像的多层）
+ 可读写，容器删除后就没有了
+ 镜像的只读层
+ Dockerfile 的每条指令生成一层，
+ 多个镜像共享相同的层
+ 容器修改镜像中的文件时，先把文件复制到可写层再修改（写时复制），只读层不变，所以同一个镜像可以启动多个容器。
+ Dockerfile 中把变化少的指令放在前面，修改代码后重新构建时前面的层可以直接复用缓存。
+
diff --git a/tools/diagram/src/docker-vs-vm.svg b/tools/diagram/src/docker-vs-vm.svg
new file mode 100644
index 000000000..13a5b0539
--- /dev/null
+++ b/tools/diagram/src/docker-vs-vm.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+
+
+
+
+ 虚拟机与容器
+ 虚拟机
+ App A
+ App B
+ 依赖库
+ 依赖库
+ 客户机 OS
+ 客户机 OS
+ Hypervisor
+ 宿主机 OS
+ 服务器
+ 容器
+ App A
+ App B
+ 依赖库
+ 依赖库
+ 容器运行时（Docker Engine）
+ 宿主机 OS（共享一个内核）
+ 服务器
+ 虚拟机为每个应用运行一个完整的操作系统，启动要几十秒、占用 GB 级内存；容器只是宿主机上隔离的进程，
+ 共享宿主机的内核，启动通常在 1 秒以内。代价是隔离性不如虚拟机，也不能在 Linux 宿主机上直接运行 Windows 容器。
+
diff --git a/tools/diagram/src/docker-why.svg b/tools/diagram/src/docker-why.svg
new file mode 100644
index 000000000..af62ee2d2
--- /dev/null
+++ b/tools/diagram/src/docker-why.svg
@@ -0,0 +1,61 @@
+
+
+
+
+
+
+
+
+
+
+ 容器：把应用和依赖打包在一起
+ 容器
+ 订单服务
+ JDK 21
+ Debian
+ 容器
+ 推荐服务
+ Python 3.12
+ Ubuntu
+ 容器
+ 网关
+ 静态二进制
+ Alpine
+ 宿主机的 Linux 内核
+ 各容器的依赖互不影响，同一个镜像在开发机、测试环境和生产环境中运行结果一致。
+
diff --git a/tools/diagram/src/dynamic-link.svg b/tools/diagram/src/dynamic-link.svg
new file mode 100644
index 000000000..f30c7836f
--- /dev/null
+++ b/tools/diagram/src/dynamic-link.svg
@@ -0,0 +1,74 @@
+
+
+
+
+
+
+
+
+
+
+ 动态链接：链接时只记录依赖，运行时再加载共享库
+ 构建时
+ 运行时
+ main.o
+ libmath.so
+ 只读取符号表
+ ld
+ prog
+ prog 中只记下依赖 libmath.so 和 libc.so，
+ 不包含它们的代码
+ execve 加载 prog
+ 动态链接器 ld-linux.so
+ 把 libmath.so、libc.so
+ 映射进内存，完成重定位
+ 多个进程共享同一份库的代码（.text），
+ 库更新后不用重新链接程序
+ 用 ldd prog 可以查看程序依赖的共享库；找不到某个库时程序启动失败，报 cannot open shared object file。
+
diff --git a/tools/diagram/src/email-flow.svg b/tools/diagram/src/email-flow.svg
new file mode 100644
index 000000000..293446094
--- /dev/null
+++ b/tools/diagram/src/email-flow.svg
@@ -0,0 +1,76 @@
+
+
+
+
+
+
+
+
+
+
+ 电子邮件：alice@a.com 发信给 bob@b.com
+ alice
+ 用户代理
+ a.com 邮件服务器
+ b.com 邮件服务器
+ bob
+ 用户代理
+ SMTP
+ SMTP（端口 25）
+ 先查 b.com 的 MX 记录
+ 找到对方的邮件服务器
+ POP3 或 IMAP
+ bob 主动来取
+ 发送和服务器之间的转发用 SMTP，是“推”；收件人读取用 POP3 或 IMAP，是“拉”。
+ 邮件先存放在收件方的服务器上，bob 不在线也不影响 alice 发信。
+ （用户代理到发件服务器之间通常使用端口 587 并要求登录。）
+
diff --git a/tools/diagram/src/ext-layout.svg b/tools/diagram/src/ext-layout.svg
new file mode 100644
index 000000000..15fb786c9
--- /dev/null
+++ b/tools/diagram/src/ext-layout.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+
+
+
+
+
+ ext2/ext4 文件系统：分区被分成多个块组
+ 启动块
+ 块组 0
+ 块组 1
+ 块组 2
+ …
+ superblock
+ 块组描述符
+ block bitmap
+ inode bitmap
+ inode table
+ data blocks
+ superblock 记录 inode 和 block 的总数与剩余数（多个块组中有备份）；两个 bitmap 用 1 位表示一个 block 或 inode 是否已被使用；
+ inode table 存放 inode，data blocks 存放文件内容。找空闲块时只需要扫描 bitmap。
+
diff --git a/tools/diagram/src/facade-movie.svg b/tools/diagram/src/facade-movie.svg
new file mode 100644
index 000000000..0d07afca5
--- /dev/null
+++ b/tools/diagram/src/facade-movie.svg
@@ -0,0 +1,53 @@
+
+
+
+
+
+
+
+
+
+
+ 外观：一个方法替客户端完成一串调用
+ Client
+ Facade
+ watchMovie()
+ SubSystem
+ ① turnOnTV()
+ ② setCD("a movie")
+ ③ startWatching()
+ 客户端只调用 watchMovie()，不需要知道子系统中有哪些类、调用顺序是什么；需要精细控制时仍然可以直接使用子系统。
+
diff --git a/tools/diagram/src/feed-push-pull.svg b/tools/diagram/src/feed-push-pull.svg
new file mode 100644
index 000000000..cc552a717
--- /dev/null
+++ b/tools/diagram/src/feed-push-pull.svg
@@ -0,0 +1,116 @@
+
+
+
+
+
+
+
+
+
+
+ Feed 流：拉模式在读时合并，推模式在写时分发
+ 拉模式（读扩散）
+ 张三关注了 A、B 和大 V，打开首页时现场合并
+ A 的发件箱
+ a2 10:05
+ a1 09:00
+ B 的发件箱
+ b1 10:20
+ 大 V 的发件箱
+ v3 10:30
+ v2 08:10
+ 张三刷新首页
+ 合并后按时间倒序
+ v3 10:30
+ b1 10:20
+ a2 10:05
+ a1 09:00
+ 关注的人越多，读一次首页越慢
+ 推模式（写扩散）
+ A 发帖时，写入每个粉丝的收件箱
+ A 发了 a3
+ 张三的收件箱
+ a3 10:40
+ v3 10:30
+ b1 10:20
+ 李四的收件箱
+ a3 10:40
+ a2 10:05
+ 读首页只需读自己的收件箱：
+ ZREVRANGE inbox:张三 0 19
+ 问题：大 V 有 1000 万粉丝，发一条就要写 1000 万次
+ 解决：粉丝多的用户不推，粉丝打开首页时再拉取
+ 合并（推拉结合）；只推给最近活跃的粉丝
+ 本机 Redis 7.4 实测
+ 推：10 万个收件箱各写 1 条
+ 532 ms，内存 +10 MB
+ 推：读自己的收件箱一页
+ 0.12 ms
+ 拉：合并 500 个发件箱
+ 24.5 ms
+ 左右两边的帖子和时间是示意；表中的数字是用流水线在本机执行得到的，拉模式包括在客户端合并排序的时间。
+
diff --git a/tools/diagram/src/fifo.svg b/tools/diagram/src/fifo.svg
new file mode 100644
index 000000000..b5f5ad17e
--- /dev/null
+++ b/tools/diagram/src/fifo.svg
@@ -0,0 +1,53 @@
+
+
+
+
+
+
+
+
+
+
+ FIFO：不相关的进程通过路径名通信
+ 客户进程 1
+ 客户进程 2
+ 客户进程 3
+ /tmp/server.fifo
+ 服务器进程
+ mkfifo 在文件系统中创建一个特殊文件，任何有权限的进程都可以打开它读写，数据仍然经过内核，不写入磁盘。
+
diff --git a/tools/diagram/src/ftp-modes.svg b/tools/diagram/src/ftp-modes.svg
new file mode 100644
index 000000000..281bf44a4
--- /dev/null
+++ b/tools/diagram/src/ftp-modes.svg
@@ -0,0 +1,82 @@
+
+
+
+
+
+
+
+
+
+
+ FTP 的主动模式与被动模式
+ 主动模式
+ 客户端
+ 服务器
+ 控制连接 → 21
+ PORT 192,168,1,10,195,81
+ 数据连接 20 → 50001
+ 服务器主动连接客户端的 50001，
+ 客户端的防火墙要放行
+ 被动模式
+ 客户端
+ 服务器
+ 控制连接 → 21
+ PASV → 227 (…,195,82)
+ 数据连接 → 50002
+ 客户端主动连接服务器的 50002，
+ 服务器要开放一段端口
+ PORT 和 PASV 的回复中，最后两个数字表示端口：195 × 256 + 81 = 50001，195 × 256 + 82 = 50002。
+ 客户端通常在 NAT 和防火墙之后，服务器连不进来，所以现在多用被动模式。
+
diff --git a/tools/diagram/src/gc-cms.svg b/tools/diagram/src/gc-cms.svg
new file mode 100644
index 000000000..4168ec352
--- /dev/null
+++ b/tools/diagram/src/gc-cms.svg
@@ -0,0 +1,68 @@
+
+
+
+
+
+
+
+
+
+
+ CMS：大部分时间与用户线程并发
+ 用户线程
+ 初始标记
+ 停顿
+ 并发标记
+ 重新标记
+ 停顿
+ 并发清除
+ 浅蓝是用户线程，浅青是 GC 线程，红线之间所有用户线程暂停（Stop The World）。
+ 只有初始标记和重新标记需要停顿；并发阶段占用一个 CPU，用户线程变慢，所以吞吐量较低。
+
diff --git a/tools/diagram/src/gc-collectors.svg b/tools/diagram/src/gc-collectors.svg
new file mode 100644
index 000000000..1103f4d7c
--- /dev/null
+++ b/tools/diagram/src/gc-collectors.svg
@@ -0,0 +1,63 @@
+
+
+
+
+
+
+
+
+
+
+ HotSpot 的 7 个经典垃圾收集器
+ 新生代
+ 老年代
+ Serial
+ ParNew
+ Parallel Scavenge
+ CMS
+ Serial Old
+ Parallel Old
+ G1
+ 整个堆
+ 失败时退回
+ 实线是可以配合使用的组合；红色虚线的两种组合在 JDK 9 中移除（JEP 214）。JDK 9 起默认使用 G1，
+ CMS 在 JDK 14 中移除（JEP 363）。新的 ZGC、Shenandoah 不在图中。
+
diff --git a/tools/diagram/src/gc-g1-cycle.svg b/tools/diagram/src/gc-g1-cycle.svg
new file mode 100644
index 000000000..cb61fa087
--- /dev/null
+++ b/tools/diagram/src/gc-g1-cycle.svg
@@ -0,0 +1,65 @@
+
+
+
+
+
+
+
+
+
+
+ G1 的一次并发标记周期（JDK 21 实测，堆 128 MB）
+ 56 ms
+ 60 ms
+ 64 ms
+ 68 ms
+ 并发标记 11.4 ms：与用户线程同时运行，2 个并发线程
+ Young (Concurrent Start) 1.649 ms
+ Remark 0.096 ms
+ Cleanup 0.046 ms
+ Mixed 0.585 ms
+ 柱子是停顿，高度表示时长。① 一次年轻代回收顺带开始标记（Concurrent Start）；② 并发标记期间年轻代回收照常进行；
+ ③ 最终标记 Remark 和 ④ 清理 Cleanup 只停顿不到 0.1 ms；⑤ 之后的混合回收（Mixed）同时回收年轻代和
+ 垃圾最多的老年代 Region。这次运行共 88 次停顿，最长 2.38 ms。
+
diff --git a/tools/diagram/src/gc-g1-regions.svg b/tools/diagram/src/gc-g1-regions.svg
new file mode 100644
index 000000000..b2c2b45f3
--- /dev/null
+++ b/tools/diagram/src/gc-g1-regions.svg
@@ -0,0 +1,178 @@
+
+
+
+
+
+
+
+
+
+
+ G1 把堆分成大小相等的 Region
+ E
+ O
+ E
+ O
+ O
+ E
+ O
+ E
+ S
+ E
+ O
+ E
+ O
+ H
+ H
+ H
+ O
+ O
+ O
+ S
+ E
+ O
+ O
+ S
+ O
+ O
+ E
+ E
+ E
+ O
+ O
+ E
+ O
+ E
+ E
+ O
+ E
+ E
+ Eden
+ S
+ Survivor
+ O
+ 老年代
+ H
+ 大对象（Humongous）
+ 空闲
+ 每个 Region 的角色可以变化。不小于半个 Region 的对象放在连续的大对象 Region 中。堆 128 MB 时 Region 为 1 MB，本机默认堆时为 4 MB。
+
diff --git a/tools/diagram/src/gc-generations.svg b/tools/diagram/src/gc-generations.svg
new file mode 100644
index 000000000..7377a9b80
--- /dev/null
+++ b/tools/diagram/src/gc-generations.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+
+
+
+
+ 分代的堆：其它收集器按新生代、老年代整体回收
+ Eden
+ S0
+ S1
+ 老年代
+ 新生代：Eden 与两个 Survivor 默认 8 : 1 : 1
+ 老年代：默认是新生代的 2 倍（NewRatio = 2）
+ 新对象在 Eden 分配；Minor GC 时把存活对象复制到 Survivor，年龄够了晋升到老年代。
+ 类的元数据不在堆中，JDK 8 起放在本地内存的元空间（Metaspace）。
+
diff --git a/tools/diagram/src/gc-parallel.svg b/tools/diagram/src/gc-parallel.svg
new file mode 100644
index 000000000..c6dadf49b
--- /dev/null
+++ b/tools/diagram/src/gc-parallel.svg
@@ -0,0 +1,65 @@
+
+
+
+
+
+
+
+
+
+
+ Parallel Scavenge 与 Parallel Old：两代都多线程
+ 用户线程
+ 新生代复制
+ 停顿
+ 老年代标记 - 整理
+ 停顿
+ 浅蓝是用户线程，浅青是 GC 线程，红线之间所有用户线程暂停（Stop The World）。
+ 目标是吞吐量：用户线程运行时间占总时间的比例越高越好。
+
diff --git a/tools/diagram/src/gc-parnew.svg b/tools/diagram/src/gc-parnew.svg
new file mode 100644
index 000000000..260fd117e
--- /dev/null
+++ b/tools/diagram/src/gc-parnew.svg
@@ -0,0 +1,62 @@
+
+
+
+
+
+
+
+
+
+
+ ParNew：多线程收集新生代
+ 用户线程
+ 新生代复制
+ 停顿
+ Serial Old
+ 停顿
+ 浅蓝是用户线程，浅青是 GC 线程，红线之间所有用户线程暂停（Stop The World）。
+ 新生代用多个 GC 线程并行复制，停顿更短；老年代仍由单线程的 Serial Old 或 CMS 回收。
+
diff --git a/tools/diagram/src/gc-serial.svg b/tools/diagram/src/gc-serial.svg
new file mode 100644
index 000000000..148152238
--- /dev/null
+++ b/tools/diagram/src/gc-serial.svg
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+
+
+
+
+ Serial 与 Serial Old：单线程收集
+ 用户线程
+ 新生代复制
+ 停顿
+ 老年代标记 - 整理
+ 停顿
+ 浅蓝是用户线程，浅青是 GC 线程，红线之间所有用户线程暂停（Stop The World）。
+ 收集期间只有一个 GC 线程工作，其它 CPU 空闲。
+
diff --git a/tools/diagram/src/gpt-layout.svg b/tools/diagram/src/gpt-layout.svg
new file mode 100644
index 000000000..55ae94607
--- /dev/null
+++ b/tools/diagram/src/gpt-layout.svg
@@ -0,0 +1,54 @@
+
+
+
+
+
+
+
+
+
+
+ GPT 分区表的布局（LBA 为 512 字节）
+ 保护性 MBR
+ LBA 0
+ GPT 表头
+ LBA 1
+ 分区项 × 128
+ LBA 2～33
+ 各个分区
+ 分区项备份
+ 表头备份
+ 最后
+ 每个分区项 128 字节，一个 LBA 放 4 个，32 个 LBA 共 128 个分区；表头带 CRC32 校验，损坏时用末尾的备份恢复。
+ LBA 是 64 位的，按 512 字节计算最大支持 2⁶⁴ × 512 字节 = 8 ZiB；MBR 只有 32 位，最大 2 TiB。
+
diff --git a/tools/diagram/src/h2-frames.svg b/tools/diagram/src/h2-frames.svg
new file mode 100644
index 000000000..1d5573769
--- /dev/null
+++ b/tools/diagram/src/h2-frames.svg
@@ -0,0 +1,72 @@
+
+
+
+
+
+
+
+
+
+
+ HTTP/2 的二进制分帧：一次 GET 请求和响应
+ GET /index.html HTTP/1.1
+ Host: www.example.com
+ User-Agent: Mozilla/5.0 …
+ Accept: text/html
+ HTTP/1.1：文本，150 字节
+ HTTP/2
+ HEADERS
+ stream 1
+ 78 字节
+ 请求首部
+ HEADERS
+ stream 1
+ … 字节
+ 响应首部
+ DATA
+ stream 1
+ 577 字节
+ 页面内容
+ 服务器返回：
+ 每个帧前面有 9 字节的帧头：长度、类型、标志和流 ID。请求和响应属于同一个流（stream 1），
+ 所以多个请求可以在一个 TCP 连接上交错发送，接收方按流 ID 重新组装。
+ 78 字节是用 hpack 库按图中首部实际编码的结果；577 字节是 www.example.com 首页的大小。
+
diff --git a/tools/diagram/src/h2-push.svg b/tools/diagram/src/h2-push.svg
new file mode 100644
index 000000000..7b9294b1d
--- /dev/null
+++ b/tools/diagram/src/h2-push.svg
@@ -0,0 +1,49 @@
+
+
+
+
+
+
+
+
+
+
+ 服务端推送：请求页面时一起发送样式
+ 浏览器
+ 服务器
+ stream 1：GET /page.html
+ stream 1：PUSH_PROMISE /style.css
+ stream 1：page.html 的内容
+ stream 2：style.css 的内容
+ 服务器推送的流 ID 为偶数。浏览器解析到 style.css 时它已经在缓存里，省去一次请求的往返。
+
diff --git a/tools/diagram/src/h2-streams.svg b/tools/diagram/src/h2-streams.svg
new file mode 100644
index 000000000..c3df994c7
--- /dev/null
+++ b/tools/diagram/src/h2-streams.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+
+
+
+
+
+ 多路复用：三个请求共用一个 TCP 连接
+ HEADERS 1
+ HEADERS 3
+ DATA 1
+ HEADERS 5
+ DATA 3
+ DATA 1
+ DATA 5
+ DATA 3
+ DATA 5
+ 一个 TCP 连接
+ stream 1：/index.html
+ stream 3：/style.css
+ stream 5：/app.js
+ 帧可以交错发送，一个响应慢不会挡住其它响应；但 TCP 丢包时所有流都要等重传，这是 HTTP/3 改用 QUIC 的原因。
+ 客户端发起的流 ID 为奇数。
+
diff --git a/tools/diagram/src/harness-loop.svg b/tools/diagram/src/harness-loop.svg
new file mode 100644
index 000000000..5b25c94e3
--- /dev/null
+++ b/tools/diagram/src/harness-loop.svg
@@ -0,0 +1,92 @@
+
+
+
+
+
+
+
+
+
+
+ Harness 中的引导与反馈：以分层规范为例
+ 引导：动手之前
+ CLAUDE.md、AGENTS.md
+ Controller 只能调用 Service
+ 架构文档、代码示例
+ 需要时再读取
+ Skill
+ 按需加载的操作步骤
+ Agent
+ 模型 + Agent 循环
+ OrderController.java
+ mapper.selectById(id);
+ Agent 第一次写的代码
+ 跳过了 Service 层
+ 反馈：动手之后
+ 编译、单元测试
+ 确定，速度快
+ 架构检查（ArchUnit）
+ 确定，速度快
+ 模型审查
+ 能查语义，较慢且不确定
+ 未通过
+ Architecture Violation [Priority: MEDIUM] - Rule 'no classes that reside in a package
+ '..controller..' should depend on classes that reside in a package '..mapper..',
+ because Controller 只能调用 Service' was violated (3 times):
+ Method <OrderController.get(long)> calls method <OrderMapper.selectById(long)>
+ in (OrderController.java:7)
+ 错误信息作为工具结果发回，Agent 改为调用 OrderService
+ 开发者：同一个问题反复出现时，补一条规范（引导）或一个检查（反馈），而不是每次在对话中纠正。
+ 确定的检查放在前面，便宜又可靠；模型审查用来发现规则写不出来的问题。
+ 错误信息是本机用 ArchUnit 1.3 检查示例代码的真实输出，省略了包名。
+
diff --git a/tools/diagram/src/hpack.svg b/tools/diagram/src/hpack.svg
new file mode 100644
index 000000000..bb0474e50
--- /dev/null
+++ b/tools/diagram/src/hpack.svg
@@ -0,0 +1,93 @@
+
+
+
+
+
+
+
+
+
+
+ 首部压缩：第二次请求只需 21 字节
+ 首部
+ 值
+ 编码方式
+ 字节数
+ :method
+ GET
+ 静态表第 2 项
+ 1
+ :scheme
+ https
+ 静态表第 7 项
+ 1
+ :authority
+ www.example.com
+ 动态表（第一次请求时加入）
+ 1
+ :path
+ /style.css
+ 新值：名字用静态表，值用 Huffman 编码
+ 9
+ user-agent
+ Mozilla/5.0 …（64 字节）
+ 动态表（第一次请求时加入）
+ 1
+ accept
+ text/css
+ 新值：名字用静态表，值用 Huffman 编码
+ 8
+ 同样的请求用 HTTP/1.1 的文本格式是 148 字节；第一次请求要建立动态表，编码后 78 字节。
+ 静态表是协议规定的 61 个常见首部；动态表由双方各自维护，保存本连接中出现过的首部，之后只发送序号。
+ 以上字节数由 hpack 4.0 库编码得到（RFC 7541）。
+
diff --git a/tools/diagram/src/http-connect.svg b/tools/diagram/src/http-connect.svg
new file mode 100644
index 000000000..efc802aa0
--- /dev/null
+++ b/tools/diagram/src/http-connect.svg
@@ -0,0 +1,52 @@
+
+
+
+
+
+
+
+
+
+
+ CONNECT：通过代理建立隧道
+ 浏览器
+ 代理 proxy:8080
+ www.example.com:443
+ CONNECT www.example.com:443 HTTP/1.1
+ 建立 TCP 连接
+ HTTP/1.1 200 Connection Established
+ TLS 握手和加密的 HTTP 报文，代理只转发字节，看不到内容
+ 代理只知道目标主机和端口；之后它像一根管道，把两端的数据原样转发。
+
diff --git a/tools/diagram/src/http-connections.svg b/tools/diagram/src/http-connections.svg
new file mode 100644
index 000000000..c52e35dee
--- /dev/null
+++ b/tools/diagram/src/http-connections.svg
@@ -0,0 +1,74 @@
+
+
+
+
+
+
+
+
+
+
+ 短连接、长连接与流水线：请求 3 个资源
+ 短连接
+ 握手
+ 请求 1
+ 握手
+ 请求 2
+ 握手
+ 请求 3
+ 6 个 RTT
+ 长连接
+ 握手
+ 请求 1
+ 请求 2
+ 请求 3
+ 4 个 RTT
+ 流水线
+ 握手
+ 请求 1、2、3 连续发出
+ 约 2 个 RTT
+ 0
+ 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ RTT
+ 灰色是 TCP 三次握手，每段约 1 个 RTT。HTTP/1.1 默认使用长连接；流水线中响应仍需按顺序返回，前一个慢了会阻塞后面的。
+
diff --git a/tools/diagram/src/http-proxy.svg b/tools/diagram/src/http-proxy.svg
new file mode 100644
index 000000000..c87013234
--- /dev/null
+++ b/tools/diagram/src/http-proxy.svg
@@ -0,0 +1,109 @@
+
+
+
+
+
+
+
+
+
+
+ 正向代理与反向代理
+ 正向代理
+ 内网
+ 客户端
+ 代理
+ 网站
+ 互联网
+ 代理客户端：服务器看到的是代理的地址
+ 反向代理
+ 机房
+ 客户端
+ Nginx
+ 代理服务器：客户端只知道代理的地址
+
diff --git a/tools/diagram/src/https-hybrid.svg b/tools/diagram/src/https-hybrid.svg
new file mode 100644
index 000000000..828061c1c
--- /dev/null
+++ b/tools/diagram/src/https-hybrid.svg
@@ -0,0 +1,51 @@
+
+
+
+
+
+
+
+
+
+
+ 混合加密：用非对称加密传递会话密钥（TLS 1.2 的 RSA 密钥交换）
+ 浏览器
+ 服务器（持有私钥）
+ ① 客户端随机数
+ ② 服务器随机数 + 证书（含公钥）
+ ③ 用公钥加密的预主密钥
+ 三者算出会话密钥
+ 解密后算出同样的会话密钥
+ ④ 之后的 HTTP 报文用会话密钥对称加密（例如 AES-GCM）
+ 这种方式下私钥一旦泄露，之前录下的通信都能被解密，TLS 1.3 已经去掉它，改用 ECDHE 密钥交换。
+
diff --git a/tools/diagram/src/https-layers.svg b/tools/diagram/src/https-layers.svg
new file mode 100644
index 000000000..7c78f2b85
--- /dev/null
+++ b/tools/diagram/src/https-layers.svg
@@ -0,0 +1,62 @@
+
+
+
+
+
+
+
+
+
+
+ HTTPS：HTTP 报文交给 TLS 加密后再交给 TCP
+ HTTP
+ HTTP
+ TCP
+ IP
+ HTTPS
+ HTTP
+ TLS
+ TCP
+ IP
+ 抓包能看到的内容
+ IP、TCP 首部
+ 明文：双方的地址和端口
+ TLS 记录头
+ 明文：类型、版本、长度
+ HTTP 请求行、首部、主体
+ 全部加密，包括 URL 和 Cookie
+ HTTPS 默认端口 443。握手时 ClientHello 中的 SNI（要访问的域名）仍是明文，
+ 所以中间人能知道访问的是哪个网站，但看不到访问了哪个页面、提交了什么内容。
+
diff --git a/tools/diagram/src/inode-pointers.svg b/tools/diagram/src/inode-pointers.svg
new file mode 100644
index 000000000..0436519bf
--- /dev/null
+++ b/tools/diagram/src/inode-pointers.svg
@@ -0,0 +1,75 @@
+
+
+
+
+
+
+
+
+
+
+ inode 中的 block 指针（block 大小为 1 KB）
+ inode
+ 权限、拥有者
+ 大小、时间
+ 直接指针 × 12
+ 一级间接
+ 二级间接
+ 三级间接
+ 12 个数据块：12 KB
+ 256 个指针
+ 256 个数据块：256 KB
+ 256
+ 256 × 256
+ 65536 个数据块：64 MB
+ 256
+ 256²
+ 256³
+ 16777216 个数据块：16 GB
+ 一个 1 KB 的块能存 1024 / 4 = 256 个块号，合计 12 + 256 + 256² + 256³ = 16843020 个块，约 16 GB，与 ext2 的最大文件一致。
+
diff --git a/tools/diagram/src/io-async.svg b/tools/diagram/src/io-async.svg
new file mode 100644
index 000000000..a2b50970b
--- /dev/null
+++ b/tools/diagram/src/io-async.svg
@@ -0,0 +1,55 @@
+
+
+
+
+
+
+
+
+
+
+ 异步 I/O
+ 应用进程
+ 内核
+ ① 等待数据
+ 例如等对方发来 hello
+ ② 复制到用户缓冲区
+ 数据到达
+ aio_read(fd, buf, 1024)
+ 立即返回
+ 继续执行其它代码
+ 完成通知：buf 中已经是 hello
+ 两个阶段都由内核完成，进程收到通知时数据已经在自己的缓冲区中。Linux 上实际的异步 I/O 多用 io_uring。
+
diff --git a/tools/diagram/src/io-blocking.svg b/tools/diagram/src/io-blocking.svg
new file mode 100644
index 000000000..7233fcea2
--- /dev/null
+++ b/tools/diagram/src/io-blocking.svg
@@ -0,0 +1,53 @@
+
+
+
+
+
+
+
+
+
+
+ 阻塞式 I/O
+ 应用进程
+ 内核
+ ① 等待数据
+ 例如等对方发来 hello
+ ② 复制到用户缓冲区
+ 数据到达
+ recvfrom(fd, buf, 1024)
+ 两个阶段都阻塞
+ 返回 5（读到 hello）
+ 本机测试：对方 300 ms 后才发送，recv 阻塞 0.31 秒后返回。等待期间线程不占用 CPU，但也不能做别的事。
+
diff --git a/tools/diagram/src/io-compare.svg b/tools/diagram/src/io-compare.svg
new file mode 100644
index 000000000..c477b96b1
--- /dev/null
+++ b/tools/diagram/src/io-compare.svg
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+ 五种 I/O 模型的比较
+ ① 等待数据
+ ② 复制数据
+ 阻塞式
+ 阻塞
+ 阻塞
+ 非阻塞式
+ 反复轮询
+ 阻塞
+ I/O 复用
+ 阻塞在 select
+ 阻塞
+ 信号驱动
+ 不阻塞
+ 阻塞
+ 异步
+ 不阻塞
+ 不阻塞
+ 同步 I/O：第二阶段由进程自己 recvfrom，都会阻塞
+ 异步 I/O
+ 红色表示进程阻塞，浅青色表示进程可以做别的事。前四种的区别只在第一阶段。
+
diff --git a/tools/diagram/src/io-multiplex.svg b/tools/diagram/src/io-multiplex.svg
new file mode 100644
index 000000000..962b47f5f
--- /dev/null
+++ b/tools/diagram/src/io-multiplex.svg
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+
+
+
+
+ I/O 复用
+ 应用进程
+ 内核
+ ① 等待数据
+ 例如等对方发来 hello
+ ② 复制到用户缓冲区
+ 数据到达
+ select([fd1, fd2, …])
+ 阻塞在 select
+ fd1 可读
+ recvfrom(fd1)
+ 复制时阻塞
+ 返回 5
+ 和阻塞式 I/O 一样要等，但一次可以等很多个连接，任何一个就绪就返回，一个线程就能处理大量连接。
+
diff --git a/tools/diagram/src/io-nonblocking.svg b/tools/diagram/src/io-nonblocking.svg
new file mode 100644
index 000000000..7d9b9a532
--- /dev/null
+++ b/tools/diagram/src/io-nonblocking.svg
@@ -0,0 +1,63 @@
+
+
+
+
+
+
+
+
+
+
+ 非阻塞式 I/O
+ 应用进程
+ 内核
+ ① 等待数据
+ 例如等对方发来 hello
+ ② 复制到用户缓冲区
+ 数据到达
+ recvfrom
+ EAGAIN（没有数据）
+ recvfrom
+ EAGAIN ……共 6 次
+ recvfrom
+ 轮询
+ 复制时阻塞
+ 返回 5
+ 本机测试：每 50 ms 调用一次 recv，前 6 次返回 EAGAIN（没有数据），第 7 次读到 hello。轮询本身要消耗 CPU。
+
diff --git a/tools/diagram/src/io-signal.svg b/tools/diagram/src/io-signal.svg
new file mode 100644
index 000000000..4f9892826
--- /dev/null
+++ b/tools/diagram/src/io-signal.svg
@@ -0,0 +1,61 @@
+
+
+
+
+
+
+
+
+
+
+ 信号驱动 I/O
+ 应用进程
+ 内核
+ ① 等待数据
+ 例如等对方发来 hello
+ ② 复制到用户缓冲区
+ 数据到达
+ sigaction(SIGIO, handler)
+ 立即返回
+ 继续执行其它代码
+ SIGIO 信号
+ 在处理函数中 recvfrom
+ 复制时阻塞
+ 返回 5
+ 等待阶段不阻塞，数据到达时内核发信号通知“可以读了”，读取仍由进程自己完成。
+
diff --git a/tools/diagram/src/java-exceptions.svg b/tools/diagram/src/java-exceptions.svg
new file mode 100644
index 000000000..a4530ff93
--- /dev/null
+++ b/tools/diagram/src/java-exceptions.svg
@@ -0,0 +1,69 @@
+
+
+
+
+
+
+
+
+
+
+ Java 异常的层次
+ Throwable
+ Error
+ Exception
+ OutOfMemoryError
+ StackOverflowError
+ RuntimeException
+ IOException
+ SQLException
+ NullPointerException
+ ArithmeticException
+ FileNotFoundException
+ 淡紫色的 Error、RuntimeException 及它们的子类
+ 是非受检异常，编译器不强制处理；
+ 其余的 Exception（浅蓝）是受检异常，必须
+ 捕获或者用 throws 声明。
+
diff --git a/tools/diagram/src/jc-atomic-cas.svg b/tools/diagram/src/jc-atomic-cas.svg
new file mode 100644
index 000000000..613e3683c
--- /dev/null
+++ b/tools/diagram/src/jc-atomic-cas.svg
@@ -0,0 +1,63 @@
+
+
+
+
+
+
+
+
+
+
+ AtomicInteger：CAS 失败就重新读取再试
+ 线程 T1
+ incrementAndGet()
+ 线程 T2
+ incrementAndGet()
+ 时间
+ 读取当前值
+ → 0
+ 读取当前值
+ → 0
+ CAS(期望 0，新值 1)
+ 成功
+ CAS(期望 0，新值 1)
+ 失败，当前是 1
+ 重新读取当前值
+ → 1
+ CAS(期望 1，新值 2)
+ 成功
+ 结果为 2。CAS 由 CPU 的一条原子指令完成：只有当前值等于期望值时才写入新值。
+
diff --git a/tools/diagram/src/jc-cnt-race.svg b/tools/diagram/src/jc-cnt-race.svg
new file mode 100644
index 000000000..70eec535a
--- /dev/null
+++ b/tools/diagram/src/jc-cnt-race.svg
@@ -0,0 +1,64 @@
+
+
+
+
+
+
+
+
+
+
+ 两个线程同时执行 cnt++，结果只加了 1
+ 线程 T1
+ cnt++
+ 线程 T2
+ cnt++
+ 时间
+ load：从主内存读入 cnt
+ → 0
+ load：从主内存读入 cnt
+ → 0
+ assign：cnt = 0 + 1
+ → 1
+ assign：cnt = 0 + 1
+ → 1
+ store：写回主内存
+ cnt = 1
+ store：写回主内存
+ cnt = 1
+ 执行了两次自增，主内存中的 cnt 是 1 而不是 2。
+ load、assign、store 每一步都是原子的，但三步合在一起不是。
+
diff --git a/tools/diagram/src/jc-countdownlatch.svg b/tools/diagram/src/jc-countdownlatch.svg
new file mode 100644
index 000000000..14b67d354
--- /dev/null
+++ b/tools/diagram/src/jc-countdownlatch.svg
@@ -0,0 +1,68 @@
+
+
+
+
+
+
+
+
+
+
+ CountDownLatch：计数减到 0 时唤醒等待的线程
+ main
+ worker-1
+ worker-2
+ worker-3
+ 执行
+ await()，等待
+ 被唤醒，继续执行
+ 执行任务
+ countDown()
+ 执行任务
+ countDown()
+ 执行任务
+ countDown()
+ count = 3
+ 2
+ 1
+ 0
+ 示意：new CountDownLatch(3)，main 调用 await() 等待 3 个工作线程各调用一次 countDown()。计数不能重置，只能使用一次。
+
diff --git a/tools/diagram/src/jc-cpu-cache.svg b/tools/diagram/src/jc-cpu-cache.svg
new file mode 100644
index 000000000..3779c5a69
--- /dev/null
+++ b/tools/diagram/src/jc-cpu-cache.svg
@@ -0,0 +1,79 @@
+
+
+
+
+
+
+
+
+
+
+ CPU 缓存：每个核心先读写自己的缓存
+ 核心 0
+ L1 数据缓存
+ 128 KB
+ 核心 1
+ L1 数据缓存
+ 128 KB
+ 核心 2
+ L1 数据缓存
+ 128 KB
+ 核心 3
+ L1 数据缓存
+ 128 KB
+ L2 缓存，4 个性能核共享
+ 12 MB
+ 主内存
+ 32 GB
+ 以本机 Apple M1 Pro 为例（sysctl）
+ 缓存以缓存行为单位读写，
+ 本机的缓存行为 128 字节。
+ 核心 0 修改了缓存中的变量，
+ 其它核心缓存里可能还是旧值，
+ 缓存一致性协议负责让它们失效，
+ 但编译器和 CPU 的重排序、
+ 写缓冲仍会导致其它线程看不到
+ 最新的值。
+ 图中只画了一组 4 个性能核；本机共有 8 个性能核和 2 个能效核。
+
diff --git a/tools/diagram/src/jc-cyclicbarrier.svg b/tools/diagram/src/jc-cyclicbarrier.svg
new file mode 100644
index 000000000..10804b065
--- /dev/null
+++ b/tools/diagram/src/jc-cyclicbarrier.svg
@@ -0,0 +1,68 @@
+
+
+
+
+
+
+
+
+
+
+ CyclicBarrier：线程到齐后一起继续，然后自动开始下一轮
+ thread-0
+ thread-1
+ thread-2
+ 第 1 轮
+ await()
+ 第 2 轮
+ await()
+ 第 1 轮
+ await()
+ 第 2 轮
+ await()
+ 第 1 轮
+ 第 2 轮
+ 屏障打开
+ 执行 barrierAction
+ 再次打开
+ 执行 barrierAction
+ new CyclicBarrier(3, barrierAction)：先到的线程在 await() 处等待，第 3 个线程到达时屏障打开；
+ 计数随即恢复为 3，同一个对象可以用于下一轮。在 JDK 21 上运行两轮，barrierAction 各执行了一次。
+
diff --git a/tools/diagram/src/jc-hb-join.svg b/tools/diagram/src/jc-hb-join.svg
new file mode 100644
index 000000000..9dd8f88f3
--- /dev/null
+++ b/tools/diagram/src/jc-hb-join.svg
@@ -0,0 +1,50 @@
+
+
+
+
+
+
+
+
+
+
+ 线程加入规则
+ 线程 t
+ main
+ x = 1;
+ // 线程结束
+ t.join(); // 返回
+ print(x); // 1
+ 线程 t 中的所有操作先行发生于其它线程从 t.join() 返回。
+
diff --git a/tools/diagram/src/jc-hb-monitor.svg b/tools/diagram/src/jc-hb-monitor.svg
new file mode 100644
index 000000000..a12e21394
--- /dev/null
+++ b/tools/diagram/src/jc-hb-monitor.svg
@@ -0,0 +1,51 @@
+
+
+
+
+
+
+
+
+
+
+ 管程锁定规则
+ 线程 T1
+ 线程 T2
+ synchronized (lock) {
+ x = 1;
+ } // unlock
+ synchronized (lock) { // lock
+ print(x); // 1
+ T1 释放锁先行发生于 T2 之后获得同一把锁，T1 在锁内的修改对 T2 可见。
+
diff --git a/tools/diagram/src/jc-hb-program-order.svg b/tools/diagram/src/jc-hb-program-order.svg
new file mode 100644
index 000000000..df9922ecd
--- /dev/null
+++ b/tools/diagram/src/jc-hb-program-order.svg
@@ -0,0 +1,45 @@
+
+
+
+
+
+
+
+
+
+
+ 单一线程原则
+ 线程 T
+ x = 1;
+ y = x + 1;
+ print(y); // 2
+ 同一个线程内，前面的操作先行发生于后面的操作。
+
diff --git a/tools/diagram/src/jc-hb-start.svg b/tools/diagram/src/jc-hb-start.svg
new file mode 100644
index 000000000..a6f1bb94a
--- /dev/null
+++ b/tools/diagram/src/jc-hb-start.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+
+
+
+
+ 线程启动规则
+ main
+ 线程 t
+ x = 1;
+ t.start();
+ print(x); // 1
+ start() 先行发生于新线程中的每一个操作。
+
diff --git a/tools/diagram/src/jc-hb-volatile.svg b/tools/diagram/src/jc-hb-volatile.svg
new file mode 100644
index 000000000..652b537b3
--- /dev/null
+++ b/tools/diagram/src/jc-hb-volatile.svg
@@ -0,0 +1,50 @@
+
+
+
+
+
+
+
+
+
+
+ volatile 变量规则
+ 线程 T1
+ 线程 T2
+ data = 42;
+ ready = true; // volatile
+ if (ready) // 读到 true
+ print(data); // 42
+ 写 volatile 变量先行发生于之后读到这个值；加上传递性，T2 也能看到 data = 42。
+
diff --git a/tools/diagram/src/jc-jmm-ops.svg b/tools/diagram/src/jc-jmm-ops.svg
new file mode 100644
index 000000000..44076873e
--- /dev/null
+++ b/tools/diagram/src/jc-jmm-ops.svg
@@ -0,0 +1,54 @@
+
+
+
+
+
+
+
+
+
+
+ 主内存与工作内存之间的 8 种操作
+ 主内存
+ 变量 cnt
+ 工作内存
+ cnt 的副本
+ 执行引擎
+ cnt + 1
+ read → load
+ store → write
+ use
+ assign
+ lock / unlock
+ 作用于主内存中的变量
+ read 把值从主内存传到工作内存，load 放入副本；store 把副本传回主内存，write 写入变量。
+
diff --git a/tools/diagram/src/jc-jmm.svg b/tools/diagram/src/jc-jmm.svg
new file mode 100644
index 000000000..ca5cf4aec
--- /dev/null
+++ b/tools/diagram/src/jc-jmm.svg
@@ -0,0 +1,61 @@
+
+
+
+
+
+
+
+
+
+
+ Java 内存模型：线程读写自己的工作内存，通过主内存交换数据
+ 线程 1
+ 工作内存
+ cnt = 1
+ 已修改，还没写回
+ 线程 2
+ 工作内存
+ cnt = 0
+ 读到的是旧值
+ 线程 3
+ 工作内存
+ cnt = 0
+ 主内存
+ cnt = 0
+ 工作内存是对寄存器、缓存等的抽象。线程 1 把 cnt 改为 1 但还没有写回主内存，线程 2 读到的仍然是 0。
+
diff --git a/tools/diagram/src/jc-threadlocal.svg b/tools/diagram/src/jc-threadlocal.svg
new file mode 100644
index 000000000..b1f3a5728
--- /dev/null
+++ b/tools/diagram/src/jc-threadlocal.svg
@@ -0,0 +1,73 @@
+
+
+
+
+
+
+
+
+
+
+ ThreadLocal：值保存在每个线程自己的 ThreadLocalMap 中
+ Thread1.threadLocals
+ value
+ 1
+ 1
+ key（弱引用）
+ threadLocal1
+ threadLocal2
+ Thread2.threadLocals
+ key（弱引用）
+ threadLocal1
+ threadLocal2
+ value
+ 2
+ 2
+ threadLocal1
+ threadLocal2
+ ThreadLocal 对象
+ 每个线程的 Map 以 ThreadLocal 对象为 key：同一个 threadLocal1，在两个线程中取到的值不同。
+ Entry 对 key 是弱引用，对 value 是强引用；线程池中的线程一直存活，value 不 remove() 就一直留在 Map 中。
+
diff --git a/tools/diagram/src/jc-work-stealing.svg b/tools/diagram/src/jc-work-stealing.svg
new file mode 100644
index 000000000..1bb217df9
--- /dev/null
+++ b/tools/diagram/src/jc-work-stealing.svg
@@ -0,0 +1,53 @@
+
+
+
+
+
+
+
+
+
+
+ 工作窃取：自己从队列一端取，窃取从另一端取
+ Thread1 的双端队列
+ Task1
+ Task2
+ Task3
+ 旧
+ 新
+ Thread1 自己取出最新的 Task3
+ （后进先出）
+ Thread2 的队列为空
+ Thread2 窃取最早的 Task1（先进先出）
+ 所有者和窃取者在队列的两端操作，只有队列中只剩一个任务时才会发生竞争。
+ 先放入的任务通常是拆分前更大的任务，窃取它能让空闲线程分到更多的工作。
+
diff --git a/tools/diagram/src/kafka-topic.svg b/tools/diagram/src/kafka-topic.svg
new file mode 100644
index 000000000..f8cc881b3
--- /dev/null
+++ b/tools/diagram/src/kafka-topic.svg
@@ -0,0 +1,111 @@
+
+
+
+
+
+
+
+
+
+
+ Kafka：按 key 选分区，组内每个分区只交给一个消费者
+ key value
+ 1024 下单
+ 1025 下单
+ 1024 支付
+ 1026 下单
+ 1024 发货
+ 1025 支付
+ 生产者按顺序发送
+ hash(key) % 3 选分区
+ 分区 0
+ 1026
+ 下单
+ 0
+ 分区 1
+ 分区 2
+ 1024
+ 下单
+ 0
+ 1025
+ 下单
+ 1
+ 1024
+ 支付
+ 2
+ 1024
+ 发货
+ 3
+ 1025
+ 支付
+ 4
+ 订单 1024 的三条消息都在分区 2，顺序不变
+ 偏移量
+ 消费者组 billing
+ consumer-1
+ consumer-2
+ consumer-3
+ consumer-4
+ 没有分到分区
+ 本机 3 个节点的 Kafka 4.4 实测：key 为 1024 和 1025 的消息都落在分区 2，1026 落在分区 0；
+ 4 个消费者分 3 个分区，consumer-4 空闲。停掉 consumer-3 后触发重平衡，分区 2 改由 consumer-4 消费。
+
diff --git a/tools/diagram/src/lb-dns.svg b/tools/diagram/src/lb-dns.svg
new file mode 100644
index 000000000..fc4f41a56
--- /dev/null
+++ b/tools/diagram/src/lb-dns.svg
@@ -0,0 +1,65 @@
+
+
+
+
+
+
+
+
+
+
+ DNS 负载均衡：解析域名时选出服务器
+ 客户端
+ DNS 服务器
+ 按地域或轮询返回 IP
+ Server 2
+ 203.0.113.12
+ ① 查询 www.example.com
+ ② A 203.0.113.12，TTL 600
+ ③ GET http://www.example.com/
+ 600 秒内本地和各级 DNS 缓存都直接返回这个地址，下线 Server 2 后要等缓存过期才生效。
+
diff --git a/tools/diagram/src/lb-http-redirect.svg b/tools/diagram/src/lb-http-redirect.svg
new file mode 100644
index 000000000..4b4474981
--- /dev/null
+++ b/tools/diagram/src/lb-http-redirect.svg
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+ HTTP 重定向：负载均衡器只返回目标地址
+ 浏览器
+ 负载均衡器
+ www.example.com
+ Server 2
+ 203.0.113.12
+ ① GET http://www.example.com/
+ ② 302 Found
+ Location: http://203.0.113.12/
+ ③ GET http://203.0.113.12/
+ 浏览器要发两次请求，之后直接访问 203.0.113.12，负载均衡器无法再调整。
+
diff --git a/tools/diagram/src/lb-ip-hash.svg b/tools/diagram/src/lb-ip-hash.svg
new file mode 100644
index 000000000..812913782
--- /dev/null
+++ b/tools/diagram/src/lb-ip-hash.svg
@@ -0,0 +1,85 @@
+
+
+
+
+
+
+
+
+
+
+ 源地址哈希：同一个 IP 总是落到同一台服务器
+ 192.0.2.30
+ crc32(IP) % 2 = 0
+ 198.51.100.8
+ crc32(IP) % 2 = 0
+ 203.0.113.11
+ crc32(IP) % 2 = 1
+ 198.51.100.7
+ crc32(IP) % 2 = 1
+ Server 1
+ 余数为 0 的客户端
+ Server 2
+ 余数为 1 的客户端
+ 示意：用 crc32(IP) % 服务器数 选择服务器。服务器数量变化时，大部分客户端的结果都会改变。
+
diff --git a/tools/diagram/src/lb-least-conn-problem.svg b/tools/diagram/src/lb-least-conn-problem.svg
new file mode 100644
index 000000000..d78ed0a94
--- /dev/null
+++ b/tools/diagram/src/lb-least-conn-problem.svg
@@ -0,0 +1,63 @@
+
+
+
+
+
+
+
+
+
+
+ 轮询不考虑连接的持续时间
+ Server 1
+ Server 2
+ 请求 1
+ 请求 2
+ 请求 3
+ 请求 4
+ 请求 5
+ 请求 6
+ 0
+ 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 7
+ 8
+ 时间
+ 请求 6 到达时：Server 1 有 1 个连接，Server 2 有 2 个
+ 请求 1、3 很快结束，请求 2 结束前又来了 4 和 6：轮询把 6 发给了已有 2 个连接的 Server 2。
+
diff --git a/tools/diagram/src/lb-least-conn.svg b/tools/diagram/src/lb-least-conn.svg
new file mode 100644
index 000000000..4c7f0e793
--- /dev/null
+++ b/tools/diagram/src/lb-least-conn.svg
@@ -0,0 +1,63 @@
+
+
+
+
+
+
+
+
+
+
+ 最少连接：发给当前连接数最少的服务器
+ Server 1
+ Server 2
+ 请求 1
+ 请求 2
+ 请求 3
+ 请求 4
+ 请求 5
+ 请求 6
+ 0
+ 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 7
+ 8
+ 时间
+ 请求 6 到达时：Server 1 有 1 个连接，Server 2 有 2 个
+ 同样的请求，最少连接算法把请求 6 发给只有 1 个连接的 Server 1，两台各有 2 个连接。
+
diff --git a/tools/diagram/src/lb-random.svg b/tools/diagram/src/lb-random.svg
new file mode 100644
index 000000000..f35835ee7
--- /dev/null
+++ b/tools/diagram/src/lb-random.svg
@@ -0,0 +1,94 @@
+
+
+
+
+
+
+
+
+
+
+ 随机：每个请求随机选一台服务器
+ 请求按顺序到达
+ 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 负载均衡器
+ 随机
+ Server 1
+ 1
+ 2
+ 4
+ Server 2
+ 3
+ 5
+ 6
+ 请求少时分配可能不均，请求多时接近平均：模拟 10000 个请求，两台分到 5055 和 4945 个。
+
diff --git a/tools/diagram/src/lb-round-robin-weak.svg b/tools/diagram/src/lb-round-robin-weak.svg
new file mode 100644
index 000000000..569e0be76
--- /dev/null
+++ b/tools/diagram/src/lb-round-robin-weak.svg
@@ -0,0 +1,96 @@
+
+
+
+
+
+
+
+
+
+
+ 轮询不考虑服务器的性能
+ 请求按顺序到达
+ 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 负载均衡器
+ 轮询
+ Server 1
+ 1
+ 3
+ 5
+ 8 核，CPU 30%
+ Server 2
+ 2
+ 4
+ 6
+ 2 核，CPU 95%，请求排队
+ 两台分到的请求一样多，但 Server 2 的处理能力只有 Server 1 的四分之一。
+
diff --git a/tools/diagram/src/lb-round-robin.svg b/tools/diagram/src/lb-round-robin.svg
new file mode 100644
index 000000000..f8ffe4375
--- /dev/null
+++ b/tools/diagram/src/lb-round-robin.svg
@@ -0,0 +1,94 @@
+
+
+
+
+
+
+
+
+
+
+ 轮询：请求轮流发给每台服务器
+ 请求按顺序到达
+ 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 负载均衡器
+ 轮询
+ Server 1
+ 1
+ 3
+ 5
+ Server 2
+ 2
+ 4
+ 6
+ 两台服务器各分到 3 个请求，适合性能相近的服务器。
+
diff --git a/tools/diagram/src/lb-weighted-round-robin.svg b/tools/diagram/src/lb-weighted-round-robin.svg
new file mode 100644
index 000000000..6d99265e7
--- /dev/null
+++ b/tools/diagram/src/lb-weighted-round-robin.svg
@@ -0,0 +1,122 @@
+
+
+
+
+
+
+
+
+
+
+ 加权轮询：按权重分配请求
+ 请求按顺序到达
+ 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 负载均衡器
+ 加权轮询
+ Server 1
+ 1
+ 2
+ 3
+ 4
+ 5
+ 权重 5
+ Server 2
+ 6
+ 权重 1
+ 6 个请求依次发给：
+ 按权重连续分配
+ S1
+ S1
+ S1
+ S1
+ S1
+ S2
+ Nginx 平滑加权轮询
+ S1
+ S1
+ S1
+ S2
+ S1
+ S1
+
diff --git a/tools/diagram/src/lock-level-1.svg b/tools/diagram/src/lock-level-1.svg
new file mode 100644
index 000000000..c174f8610
--- /dev/null
+++ b/tools/diagram/src/lock-level-1.svg
@@ -0,0 +1,61 @@
+
+
+
+
+
+
+
+
+
+
+ 一级封锁协议：修改前加 X 锁，事务结束才释放
+ 事务 T1
+ 事务 T2
+ 时间
+ lock-x(A)
+ read A
+ → 100
+ lock-x(A)，等待 T1 释放
+ write A = 70
+ commit，unlock(A)
+ 获得 X 锁，read A
+ → 70
+ write A = 120
+ commit，unlock(A)
+ 解决丢失修改：T2 只能在 T1 提交之后读取并修改，结果为 120。
+
diff --git a/tools/diagram/src/lock-level-2.svg b/tools/diagram/src/lock-level-2.svg
new file mode 100644
index 000000000..478ff3ed4
--- /dev/null
+++ b/tools/diagram/src/lock-level-2.svg
@@ -0,0 +1,56 @@
+
+
+
+
+
+
+
+
+
+
+ 二级封锁协议：读取前加 S 锁，读完立即释放
+ 事务 T1
+ 事务 T2
+ 时间
+ lock-x(A)
+ write A = 200
+ lock-s(A)，等待 T1 释放
+ rollback，unlock(A)
+ 获得 S 锁，read A
+ → 100
+ unlock(A)
+ 解决读脏数据：T1 持有 X 锁期间，T2 加不上 S 锁，读不到 T1 未提交的 200。
+
diff --git a/tools/diagram/src/lock-level-3.svg b/tools/diagram/src/lock-level-3.svg
new file mode 100644
index 000000000..60c86a6c5
--- /dev/null
+++ b/tools/diagram/src/lock-level-3.svg
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+
+
+
+
+ 三级封锁协议：读取前加 S 锁，事务结束才释放
+ 事务 T1
+ 事务 T2
+ 时间
+ lock-s(A)
+ read A
+ → 100
+ lock-x(A)，等待 T2 释放
+ read A
+ → 100
+ commit，unlock(A)
+ 获得 X 锁，write A = 200
+ commit，unlock(A)
+ 解决不可重复读：T2 结束之前，T1 无法修改 A，T2 两次读到的都是 100。
+
diff --git a/tools/diagram/src/lock-record.svg b/tools/diagram/src/lock-record.svg
new file mode 100644
index 000000000..b39e73772
--- /dev/null
+++ b/tools/diagram/src/lock-record.svg
@@ -0,0 +1,52 @@
+
+
+
+
+
+
+
+
+
+
+ 轻量级锁：加锁就是一次 CAS
+ 线程 T1 的栈
+ 其它栈帧
+ Lock Record
+ 保存原来的 Mark Word …01
+ 锁对象
+ Mark Word：Lock Record 的地址 …00
+ 类型指针
+ 字段
+ CAS 成功
+ CAS 期望 Mark Word 仍是原来的 …01，成功就加锁完成；失败说明已被其它线程持有（或是当前线程重入），竞争时膨胀为重量级锁。
+
diff --git a/tools/diagram/src/lock-states.svg b/tools/diagram/src/lock-states.svg
new file mode 100644
index 000000000..0fa4a66fa
--- /dev/null
+++ b/tools/diagram/src/lock-states.svg
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+
+
+
+
+ synchronized 的锁状态变化（JDK 21 用 JOL 实测 Mark Word）
+ 无锁
+ 0x0000000000000001
+ 末尾 01
+ 轻量级锁
+ 0x000000016faceae0
+ 末尾 00
+ 指向加锁线程栈中的 Lock Record
+ 重量级锁
+ 0x000000015b630a72
+ 末尾 10
+ 指向 ObjectMonitor
+ 进入 synchronized：CAS 把 Mark Word 换成
+ Lock Record 地址；退出时 CAS 换回
+ 另一个线程加锁时 CAS 失败，
+ 膨胀为重量级锁，抢不到的线程阻塞
+ 实测：① 新建的对象是 0x…01；② 一个线程进入 synchronized 后变为 thin lock；③ 退出后恢复为 0x…01；
+ ④ 另一个线程持有锁时再去加锁，变为 fat lock；⑤ 两个线程都退出后仍是 fat lock，空闲的监视器由 JVM 之后回收。
+ 如果对象调用过 hashCode()，哈希值会写进 Mark Word，例如 0x00000028ac3dc301 中的 28ac3dc3。
+ 锁只会从轻量级膨胀为重量级，不会在使用中降级；JDK 15 之前，一个线程反复加锁时还会先进入偏向锁。
+
diff --git a/tools/diagram/src/lru-stack.svg b/tools/diagram/src/lru-stack.svg
new file mode 100644
index 000000000..8989597d0
--- /dev/null
+++ b/tools/diagram/src/lru-stack.svg
@@ -0,0 +1,153 @@
+
+
+
+
+
+
+
+
+
+
+ LRU：5 个页框，链表头是最近访问的页面
+ 访问
+ 缺页
+ 4
+ 4
+ 缺页
+ 7
+ 7
+ 4
+ 缺页
+ 0
+ 0
+ 7
+ 4
+ 缺页
+ 7
+ 7
+ 0
+ 4
+ 1
+ 1
+ 7
+ 0
+ 4
+ 缺页
+ 0
+ 0
+ 1
+ 7
+ 4
+ 1
+ 1
+ 0
+ 7
+ 4
+ 2
+ 2
+ 1
+ 0
+ 7
+ 4
+ 缺页
+ 1
+ 1
+ 2
+ 0
+ 7
+ 4
+ 2
+ 2
+ 1
+ 0
+ 7
+ 4
+ 6
+ 6
+ 2
+ 1
+ 0
+ 7
+ 缺页
+ 换出 4
+ 头
+ 尾
+ 被访问的页面移到链表头（淡紫色）；访问 6 时 5 个页框已满，换出链表尾部最久没有访问的 4。11 次访问共缺页 6 次。
+
diff --git a/tools/diagram/src/markword.svg b/tools/diagram/src/markword.svg
new file mode 100644
index 000000000..e9e53f4ec
--- /dev/null
+++ b/tools/diagram/src/markword.svg
@@ -0,0 +1,79 @@
+
+
+
+
+
+
+
+
+
+
+ 64 位 HotSpot 的 Mark Word（JDK 8）
+ 是否偏向
+ 锁标志
+ 无锁
+ unused 25
+ hashCode 31
+ 1
+ age 4
+ 0
+ 01
+ 偏向锁
+ 线程 ID 54
+ epoch 2
+ 1
+ age 4
+ 1
+ 01
+ 轻量级锁
+ 指向栈中 Lock Record 的指针 62
+ 00
+ 重量级锁
+ 指向 ObjectMonitor 的指针 62
+ 10
+ GC 标记
+ 11
+ 末尾两位是锁标志，01 时再看倒数第 3 位区分无锁和偏向锁。偏向锁在 JDK 15 默认禁用（JEP 374），之后被移除，
+ 现在对象只在无锁、轻量级锁、重量级锁之间转换。依据 jdk8u 的 markOop.hpp。
+
diff --git a/tools/diagram/src/mbr-multiboot.svg b/tools/diagram/src/mbr-multiboot.svg
new file mode 100644
index 000000000..f21d0900f
--- /dev/null
+++ b/tools/diagram/src/mbr-multiboot.svg
@@ -0,0 +1,53 @@
+
+
+
+
+
+
+
+
+
+
+ MBR 与多重引导
+ 第 1 个扇区
+ 分区 1：Windows
+ 分区 2：Linux
+ 446 字节开机管理程序
+ + 64 字节分区表
+ 启动扇区
+ 开机菜单
+ M1：Windows M2：转交
+ M1 直接加载
+ M2 转交给 Linux 分区启动扇区中的 GRUB
+ BIOS 读取第 1 个扇区并执行其中的开机管理程序；先装 Windows 再装 Linux，因为安装 Windows 会覆盖 MBR 中的开机管理程序。
+
diff --git a/tools/diagram/src/mediator-after.svg b/tools/diagram/src/mediator-after.svg
new file mode 100644
index 000000000..583c5353c
--- /dev/null
+++ b/tools/diagram/src/mediator-after.svg
@@ -0,0 +1,49 @@
+
+
+
+
+
+
+
+
+
+
+ 中介者：网状依赖变成星形
+ Alarm
+ CoffeePot
+ Calendar
+ Sprinkler
+ Mediator
+ 每个对象只把事件交给 Mediator，由它决定通知谁，例如闹钟响了就调用咖啡壶、日历和喷头。
+
diff --git a/tools/diagram/src/mediator-before.svg b/tools/diagram/src/mediator-before.svg
new file mode 100644
index 000000000..a671a0b10
--- /dev/null
+++ b/tools/diagram/src/mediator-before.svg
@@ -0,0 +1,49 @@
+
+
+
+
+
+
+
+
+
+
+ 没有中介者：对象之间互相调用
+ Alarm
+ CoffeePot
+ Calendar
+ Sprinkler
+ 4 个对象之间有 6 条依赖，新增一个对象就要修改其它所有对象。
+
diff --git a/tools/diagram/src/mime.svg b/tools/diagram/src/mime.svg
new file mode 100644
index 000000000..7073e7181
--- /dev/null
+++ b/tools/diagram/src/mime.svg
@@ -0,0 +1,52 @@
+
+
+
+
+
+
+
+
+
+
+ MIME：把非 ASCII 内容编码成 ASCII 字符
+ 邮件主题
+ 你好
+ UTF-8 编码
+ e4 bd a0 e5 a5 bd
+ Base64
+ 5L2g5aW9
+ 邮件首部
+ =?utf-8?b?5L2g5aW9?=
+ SMTP 最初只能传送 7 位 ASCII 文本。MIME 不改变 SMTP，只规定如何把中文、图片、附件等内容编码成 ASCII：
+ Base64 把每 3 个字节变成 4 个可打印字符，6 个字节的“你好”编码后是 8 个字符；收件方按首部中注明的
+ 字符集和编码方式还原。
+
diff --git a/tools/diagram/src/modulation.svg b/tools/diagram/src/modulation.svg
new file mode 100644
index 000000000..11cb2c28e
--- /dev/null
+++ b/tools/diagram/src/modulation.svg
@@ -0,0 +1,73 @@
+
+
+
+
+
+
+
+
+
+
+ 带通调制：用载波的振幅、频率或相位表示 0 和 1
+ 0
+ 1
+ 0
+ 1
+ 1
+ 0
+ 0
+ 1
+ 数字信号
+ 基带信号
+ 调幅 AM
+ 1 有载波，0 没有
+ 调频 FM
+ 1 频率高，0 频率低
+ 调相 PM
+ 0 和 1 的相位差 180°
+ 调相中圆圈标出了 0 和 1 交替处的相位跳变。示意图，每一位画 2 个载波周期（调频中 1 画 4 个）。
+
diff --git a/tools/diagram/src/multilevel-cache.svg b/tools/diagram/src/multilevel-cache.svg
new file mode 100644
index 000000000..cdad034bd
--- /dev/null
+++ b/tools/diagram/src/multilevel-cache.svg
@@ -0,0 +1,81 @@
+
+
+
+
+
+
+
+
+
+
+ 多级缓存：本地缓存 → Redis → 数据库
+ 应用实例 1
+ 本地缓存 Caffeine
+ 约 21 ns
+ 应用实例 2
+ 本地缓存 Caffeine
+ 约 21 ns
+ Redis
+ 约 71 μs（本机回环）
+ MySQL
+ 毫秒级
+ ① 未命中
+ ② 未命中
+ 回填
+ 回填
+ 数据更新：写数据库，删除 Redis，再广播删除本地缓存
+ （Redis Pub/Sub 或消息队列）
+ 热点数据在本地内存中直接命中，不经过网络，也不会集中打到 Redis 的某一个节点；
+ 代价是每个实例各存一份，更新时要通知所有实例，并给本地缓存设置较短的过期时间兜底。
+
diff --git a/tools/diagram/src/mvcc-readview.svg b/tools/diagram/src/mvcc-readview.svg
new file mode 100644
index 000000000..316238c0b
--- /dev/null
+++ b/tools/diagram/src/mvcc-readview.svg
@@ -0,0 +1,76 @@
+
+
+
+
+
+
+
+
+
+
+ ReadView：沿版本链找到第一个对自己可见的版本
+ 读事务开始读取时，事务 103、105 还没有提交，下一个要分配的事务 ID 是 106：
+ TRX_IDs = {103, 105}，TRX_ID_MIN = 103，TRX_ID_MAX = 106
+ 事务 ID
+ 101
+ 可见
+ 已提交
+ 102
+ 可见
+ 已提交
+ 103
+ 不可见
+ 在 TRX_IDs 中
+ 104
+ 可见
+ 已提交
+ 105
+ 不可见
+ 在 TRX_IDs 中
+ 106
+ 不可见
+ 之后才开始
+ TRX_ID_MIN
+ TRX_ID_MAX
+ 读取 id = 1 这一行：
+ 版本 x = 'c'
+ DB_TRX_ID = 103，在 TRX_IDs 中
+ 不可见，沿回滚指针找上一个版本
+ 版本 x = 'b'
+ DB_TRX_ID = 102，小于 TRX_ID_MIN
+ 可见，读到 'b'
+ 可重复读在第一次读取时创建 ReadView，之后一直使用它；提交读每次读取都创建新的 ReadView，103 提交后就能读到 'c'。
+ 事务 ID 为示意；读到的结果在 MySQL 8.0 上实测一致。
+
diff --git a/tools/diagram/src/mvcc-undo-chain.svg b/tools/diagram/src/mvcc-undo-chain.svg
new file mode 100644
index 000000000..5a9c4c479
--- /dev/null
+++ b/tools/diagram/src/mvcc-undo-chain.svg
@@ -0,0 +1,91 @@
+
+
+
+
+
+
+
+
+
+
+ Undo 版本链：每次修改都把旧版本写入 undo log，用回滚指针连起来
+ 当前的数据行
+ id
+ x
+ DB_TRX_ID
+ DB_ROLL_PTR
+ 1
+ c
+ 103
+ → 版本 2
+ UPDATE t SET x = 'c'（事务 103）
+ undo log 中的版本 2
+ id
+ x
+ DB_TRX_ID
+ DB_ROLL_PTR
+ 1
+ b
+ 102
+ → 版本 1
+ UPDATE t SET x = 'b'（事务 102）
+ undo log 中的版本 1
+ id
+ x
+ DB_TRX_ID
+ DB_ROLL_PTR
+ 1
+ a
+ 101
+ 无更早版本
+ INSERT INTO t VALUES (1, 'a')（事务 101）
+ DB_TRX_ID 是最后修改这一行的事务 ID，DB_ROLL_PTR 指向上一个版本；事务 ID 为示意。
+
diff --git a/tools/diagram/src/mysql-replication.svg b/tools/diagram/src/mysql-replication.svg
new file mode 100644
index 000000000..f6eed3d00
--- /dev/null
+++ b/tools/diagram/src/mysql-replication.svg
@@ -0,0 +1,73 @@
+
+
+
+
+
+
+
+
+
+
+ 主从复制（MySQL 8.0 本机实测的线程）
+ 主库 :3307
+ 从库 :3308
+ 数据
+ binlog
+ 提交
+ Binlog Dump 线程
+ I/O 线程
+ 发送 binlog 事件
+ relay log
+ SQL 线程 + 4 个 worker
+ 数据
+ 主库提交时不等从库，从库落后的时间就是复制延迟。8.0.27 起默认 4 个 worker 并行重放（replica_parallel_workers = 4）。
+
diff --git a/tools/diagram/src/mysql-rw-split.svg b/tools/diagram/src/mysql-rw-split.svg
new file mode 100644
index 000000000..a67227364
--- /dev/null
+++ b/tools/diagram/src/mysql-rw-split.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+
+
+
+
+ 读写分离与复制延迟
+ 应用
+ 代理或数据源路由
+ 按 SQL 类型转发
+ 主库：写和实时读
+ 从库 1：读
+ 从库 2：读
+ 复制
+ INSERT、UPDATE
+ SELECT
+ 本机实测：主库一个事务插入 50 万行，从库在 1.4 秒后才一次性看到这些行。刚写完就去从库读，可能读不到自己写的数据。
+ 常用做法：写入后的一段时间内这个用户的读请求走主库，或者把要求实时的读请求固定发到主库。
+
diff --git a/tools/diagram/src/network-of-networks.svg b/tools/diagram/src/network-of-networks.svg
new file mode 100644
index 000000000..a7fb90b02
--- /dev/null
+++ b/tools/diagram/src/network-of-networks.svg
@@ -0,0 +1,88 @@
+
+
+
+
+
+
+
+
+
+
+ 互联网：网络的网络
+ 公司 A 的局域网
+ 运营商 1 的网络
+ 运营商 2 的网络
+ 学校 B 的局域网
+ 每朵云是一个独立的网络，浅青色的路由器把它们连接起来；互联网就是由许多这样的网络互连而成的。
+
diff --git a/tools/diagram/src/next-key-locks-v2.svg b/tools/diagram/src/next-key-locks-v2.svg
new file mode 100644
index 000000000..68de180a4
--- /dev/null
+++ b/tools/diagram/src/next-key-locks-v2.svg
@@ -0,0 +1,79 @@
+
+
+
+
+
+
+
+
+
+
+ Next-Key Locks：锁住记录和它前面的间隙
+ ① SELECT * FROM t WHERE c = 11 FOR UPDATE
+ (10, 11]
+ (11, 13)
+ -∞
+ c=10
+ c=11
+ c=13
+ c=20
+ +∞
+ data_locks：c = 11 的记录上是 X（Next-Key Lock），c = 13 上是 X,GAP；插入 c = 12 被阻塞，c = 9、14、21 可以插入
+ ② SELECT * FROM t WHERE c BETWEEN 10 AND 20 FOR UPDATE
+ (-∞, 10]
+ (10, 11]
+ (11, 13]
+ (13, 20]
+ (20, +∞]
+ -∞
+ c=10
+ c=11
+ c=13
+ c=20
+ +∞
+ data_locks：c = 10、11、13、20 和 supremum 上都是 X；插入 c = 9、12、14、21 都被阻塞
+ Next-Key Lock（前开后闭）
+ Gap Lock（开区间）
+ MySQL 8.0，c 上有普通索引，可重复读
+
diff --git a/tools/diagram/src/oauth-code-flow.svg b/tools/diagram/src/oauth-code-flow.svg
new file mode 100644
index 000000000..6a7aa7639
--- /dev/null
+++ b/tools/diagram/src/oauth-code-flow.svg
@@ -0,0 +1,64 @@
+
+
+
+
+
+
+
+
+
+
+ OAuth 2.0 授权码流程：令牌由后端换取，不经过浏览器
+ 用户的浏览器
+ 笔记网站 notes.example.com
+ 授权服务器 id.example.com
+ ① 点击“用账号中心登录”
+ ② 302 到 id.example.com/authorize
+ 带上 state 和 code_challenge
+ ③ GET /authorize，用户登录并点击同意
+ ④ 302 到 notes.example.com/callback
+ ?code=R9Ydi...&state=x7Kp2
+ ⑤ GET /callback?code=R9Ydi...&state=x7Kp2
+ ⑥ POST /token：code + code_verifier
+ ⑦ {"access_token": "v-7Dl...", "expires_in": 3600}
+ ⑧ GET /userinfo，Authorization: Bearer v-7Dl...
+ ⑨ 登录成功，Set-Cookie: 笔记网站自己的会话
+ 绿色是笔记网站后端与授权服务器之间的直接请求，访问令牌不经过浏览器；授权码经过浏览器，但只能用一次，换令牌时还要提供 code_verifier。
+
diff --git a/tools/diagram/src/observer-intent.svg b/tools/diagram/src/observer-intent.svg
new file mode 100644
index 000000000..f3f14cf8c
--- /dev/null
+++ b/tools/diagram/src/observer-intent.svg
@@ -0,0 +1,58 @@
+
+
+
+
+
+
+
+
+
+
+ 观察者：一个主题，多个观察者
+ WeatherData（主题）
+ registerObserver(o)
+ removeObserver(o)
+ notifyObserver()
+ observers = [布告板 1, 布告板 2]
+ CurrentConditionsDisplay
+ update(temp, humidity, pressure)
+ StatisticsDisplay
+ update(temp, humidity, pressure)
+ 以后新增的布告板
+ update(temp, humidity, pressure)
+ 状态改变时逐个调用 update
+ 主题只依赖 Observer 接口，不知道具体有哪些布告板；新增布告板时只需要调用 registerObserver 注册，主题的代码不用改。
+
diff --git a/tools/diagram/src/observer-run.svg b/tools/diagram/src/observer-run.svg
new file mode 100644
index 000000000..f8941114a
--- /dev/null
+++ b/tools/diagram/src/observer-run.svg
@@ -0,0 +1,55 @@
+
+
+
+
+
+
+
+
+
+
+ setMeasurements(1, 1, 1) 之后发生了什么
+ WeatherStation
+ WeatherData
+ CurrentConditionsDisplay
+ StatisticsDisplay
+ setMeasurements(1, 1, 1)
+ notifyObserver()
+ update(1.0, 1.0, 1.0)
+ update(1.0, 1.0, 1.0)
+ 实际输出：CurrentConditionsDisplay.update: 1.0 1.0 1.0，接着是 StatisticsDisplay.update: 1.0 1.0 1.0，顺序与注册的顺序相同。
+
diff --git a/tools/diagram/src/os-kernels.svg b/tools/diagram/src/os-kernels.svg
new file mode 100644
index 000000000..28df38a9f
--- /dev/null
+++ b/tools/diagram/src/os-kernels.svg
@@ -0,0 +1,73 @@
+
+
+
+
+
+
+
+
+
+
+ 宏内核与微内核
+ 宏内核（Linux）
+ 用户态
+ 内核态
+ 应用程序
+ 文件系统
+ 设备驱动
+ 内存管理
+ 进程调度
+ 进程间通信
+ 硬件
+ 微内核（Minix、QNX）
+ 用户态
+ 内核态
+ 应用程序
+ 文件系统
+ 设备驱动
+ 内存管理
+ 进程调度
+ 进程间通信
+ 硬件
+ 微内核把文件系统、驱动等移到用户态，通过消息与内核通信：一个驱动崩溃不会拖垮整个系统，但每次请求多了几次用户态和内核态的切换。
+
diff --git a/tools/diagram/src/os-syscall.svg b/tools/diagram/src/os-syscall.svg
new file mode 100644
index 000000000..fe27b007f
--- /dev/null
+++ b/tools/diagram/src/os-syscall.svg
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+
+
+
+
+ 系统调用：open() 从用户态进入内核态
+ 用户态
+ 内核态
+ fd = open("a.txt", O_RDONLY);
+ C 库的 open 包装函数
+ 系统调用表
+ 按系统调用号查找
+ 内核的 open 实现
+ 系统调用号放进寄存器，
+ 执行陷入指令（x86-64 上是 syscall）
+ 返回文件描述符
+ 进入内核时 CPU 切换到特权级，执行完再切回用户态。这一来一回比普通函数调用慢得多，所以频繁的小读写要用缓冲区合并。
+
diff --git a/tools/diagram/src/page-translate.svg b/tools/diagram/src/page-translate.svg
new file mode 100644
index 000000000..13520ac59
--- /dev/null
+++ b/tools/diagram/src/page-translate.svg
@@ -0,0 +1,145 @@
+
+
+
+
+
+
+
+
+
+
+ 地址转换：虚拟地址 0x3ABC
+ 虚拟地址
+ 0
+ 0
+ 1
+ 1
+ 1
+ 0
+ 1
+ 0
+ 1
+ 0
+ 1
+ 1
+ 1
+ 1
+ 0
+ 0
+ 页号 3
+ 偏移量 0xABC（12 位）
+ 页表
+ 页框号
+ 存在
+ 0
+ 010
+ 1
+ 1
+ 111
+ 1
+ 2
+ ---
+ 0
+ 3
+ 101
+ 1
+ 4
+ ---
+ 0
+ 5
+ 000
+ 1
+ ……共 16 项
+ 用页号作下标
+ 物理地址
+ 1
+ 0
+ 1
+ 1
+ 0
+ 1
+ 0
+ 1
+ 0
+ 1
+ 1
+ 1
+ 1
+ 0
+ 0
+ 页框号 101（5）
+ 偏移量原样复制
+ = 0x5ABC
+ 4 KB 的页需要 12 位偏移量，16 位地址剩下的 4 位就是页号，页表一共 16 项。
+ 如果查到的“存在”位是 0（例如页 4），说明这一页不在内存中，CPU 触发缺页中断。
+
diff --git a/tools/diagram/src/paxos-roles.svg b/tools/diagram/src/paxos-roles.svg
new file mode 100644
index 000000000..b23788deb
--- /dev/null
+++ b/tools/diagram/src/paxos-roles.svg
@@ -0,0 +1,58 @@
+
+
+
+
+
+
+
+
+
+
+ Paxos 的三类角色
+ Proposer A
+ Proposer B
+ Acceptor X
+ Acceptor Y
+ Acceptor Z
+ Learner
+ Prepare、Accept
+ 接受的提议
+ Proposer 向所有 Acceptor 发请求，超过一半 Acceptor 接受同一个提议，这个值就被选定；Learner 只负责得知结果。
+
diff --git a/tools/diagram/src/philosophers.svg b/tools/diagram/src/philosophers.svg
new file mode 100644
index 000000000..82f5f51ae
--- /dev/null
+++ b/tools/diagram/src/philosophers.svg
@@ -0,0 +1,68 @@
+
+
+
+
+
+
+
+
+
+
+ 哲学家进餐：5 个人、5 根筷子
+ P0
+ 0
+ P1
+ 1
+ P2
+ 2
+ P3
+ 3
+ P4
+ 4
+ 如果每个人都先拿编号与自己相同的筷子：
+ P0 拿 0、P1 拿 1……P4 拿 4，再去拿另一根：
+ P0 等 4、P1 等 0……P4 等 3，形成环路，死锁。
+ 解决方法：
+ ① 只有左右两根都能拿到时才拿（下面的代码）；
+ ② 都先拿编号小的那根：P0 改为先拿 0 再拿 4，
+ 与 P1 争抢 0，环路被打破；
+ ③ 最多允许 4 个人同时拿筷子。
+
diff --git a/tools/diagram/src/pipe.svg b/tools/diagram/src/pipe.svg
new file mode 100644
index 000000000..5d3e6ea2d
--- /dev/null
+++ b/tools/diagram/src/pipe.svg
@@ -0,0 +1,54 @@
+
+
+
+
+
+
+
+
+
+
+ 管道：fork 之后父进程写、子进程读
+ 父进程
+ 子进程
+ fd[1] 写端
+ fd[0] 关闭
+ fd[0] 读端
+ fd[1] 关闭
+ 内核中的管道缓冲区
+ Linux 默认 64 KB
+ write(fd[1], "hello")
+ read(fd[0], buf)
+ pipe 返回两个文件描述符，fork 后父子进程都持有两端，各自关闭不用的一端，数据只能单向流动。
+
diff --git a/tools/diagram/src/process-concurrent.svg b/tools/diagram/src/process-concurrent.svg
new file mode 100644
index 000000000..94b9eac0f
--- /dev/null
+++ b/tools/diagram/src/process-concurrent.svg
@@ -0,0 +1,57 @@
+
+
+
+
+
+
+
+
+
+
+ 4 个进程在一个 CPU 上并发执行
+ 进程 A
+ 进程 B
+ 进程 C
+ 进程 D
+ 时间
+ 任一时刻只有一个进程在 CPU 上运行；操作系统按时间片轮流切换，宏观上看 4 个进程在同时推进。
+
diff --git a/tools/diagram/src/process-mlfq.svg b/tools/diagram/src/process-mlfq.svg
new file mode 100644
index 000000000..9ba84849c
--- /dev/null
+++ b/tools/diagram/src/process-mlfq.svg
@@ -0,0 +1,114 @@
+
+
+
+
+
+
+
+
+
+
+ 多级反馈队列：一个需要 100 个时间片的进程
+ 队列 1
+ 时间片 1
+ 累计运行 1
+ 队列 2
+ 时间片 2
+ 累计运行 3
+ 队列 3
+ 时间片 4
+ 累计运行 7
+ 队列 4
+ 时间片 8
+ 累计运行 15
+ 队列 5
+ 时间片 16
+ 累计运行 31
+ 队列 6
+ 时间片 32
+ 累计运行 63
+ 队列 7
+ 时间片 64
+ 累计运行 100，完成
+ 没用完时间片就进入下一级。这个进程只被调度 7 次，而时间片固定为 1 时要调度 100 次；新来的短进程在上面的高优先级队列中很快完成。
+
diff --git a/tools/diagram/src/process-rr.svg b/tools/diagram/src/process-rr.svg
new file mode 100644
index 000000000..b476548ca
--- /dev/null
+++ b/tools/diagram/src/process-rr.svg
@@ -0,0 +1,62 @@
+
+
+
+
+
+
+
+
+
+
+ 时间片轮转：时间片为 2，A、B、C 分别需要运行 5、3、2
+ A
+ B
+ C
+ A
+ B
+ A
+ 0
+ 1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 7
+ 8
+ 9
+ 10
+ C 在 6 结束
+ B 在 9 结束
+ A 在 10 结束
+ 用完时间片的进程回到队尾。平均完成时间 (10 + 9 + 6) / 3 ≈ 8.3；时间片越小响应越快，但切换次数越多，
+ 每次切换都要保存和恢复上下文。
+
diff --git a/tools/diagram/src/process-states.svg b/tools/diagram/src/process-states.svg
new file mode 100644
index 000000000..852a184bc
--- /dev/null
+++ b/tools/diagram/src/process-states.svg
@@ -0,0 +1,57 @@
+
+
+
+
+
+
+
+
+
+
+ 进程状态的切换
+ 新建
+ 就绪
+ 运行
+ 阻塞
+ 终止
+ 创建完成
+ 被调度
+ 时间片用完
+ 结束
+ 等待 I/O 或事件
+ I/O 完成
+ 只有就绪和运行可以相互转换；阻塞的进程即使 CPU 空闲也不能运行，要先回到就绪队列。
+
diff --git a/tools/diagram/src/process-threads.svg b/tools/diagram/src/process-threads.svg
new file mode 100644
index 000000000..6a37f0b65
--- /dev/null
+++ b/tools/diagram/src/process-threads.svg
@@ -0,0 +1,67 @@
+
+
+
+
+
+
+
+
+
+
+ 浏览器进程中的多个线程
+ 浏览器进程
+ 所有线程共享：
+ 代码
+ 全局数据
+ 堆
+ 打开的文件、网络连接
+ 网络请求线程
+ 自己的栈
+ 寄存器、程序计数器
+ 独立调度
+ 事件响应线程
+ 自己的栈
+ 寄存器、程序计数器
+ 独立调度
+ 渲染线程
+ 自己的栈
+ 寄存器、程序计数器
+ 独立调度
+ 线程共享进程的内存，可以直接读写同一个变量通信；每个线程只有自己的栈和寄存器，所以创建和切换的开销比进程小。
+
diff --git a/tools/diagram/src/raft-election.svg b/tools/diagram/src/raft-election.svg
new file mode 100644
index 000000000..add22dc08
--- /dev/null
+++ b/tools/diagram/src/raft-election.svg
@@ -0,0 +1,74 @@
+
+
+
+
+
+
+
+
+
+
+ Raft 选举：A 的竞选计时器最先到期
+ 节点 A
+ 超时 180 ms
+ Follower，等待心跳
+ Leader，任期 1
+ 节点 B
+ 超时 260 ms
+ Follower
+ 原定 260 ms 超时
+ 节点 C
+ 超时 230 ms
+ Follower
+ 原定 230 ms 超时
+ 180 ms 超时：成为候选人，任期加 1，投自己一票，向 B、C 请求投票
+ B、C 投票给 A，3 票中得到 3 票
+ 浅青色短条是 Leader 当选后立即发出、之后每 50 ms 发一次的心跳，Follower 收到后重新计时
+ 0 ms
+ 100 ms
+ 200 ms
+ 300 ms
+ 400 ms
+ 每个节点的竞选超时在 150～300 ms 中随机选取，通常只有一个节点先超时，它在别人超时前就能拿到多数票。
+
diff --git a/tools/diagram/src/raft-log.svg b/tools/diagram/src/raft-log.svg
new file mode 100644
index 000000000..e67eb8364
--- /dev/null
+++ b/tools/diagram/src/raft-log.svg
@@ -0,0 +1,88 @@
+
+
+
+
+
+
+
+
+
+
+ Raft 日志复制：SET x = 5
+ ① 写入 Leader 的日志
+ Leader
+ 1 y=1
+ 1 x=5
+ B
+ 1 y=1
+ C
+ 1 y=1
+ ② 复制给 Follower
+ 1 y=1
+ 1 x=5
+ 1 y=1
+ 1 x=5
+ 1 y=1
+ ③ 多数写入后提交
+ 1 y=1
+ 1 x=5
+ 1 y=1
+ 1 x=5
+ 1 y=1
+ ④ 心跳通知 Follower 提交
+ 1 y=1
+ 1 x=5
+ 1 y=1
+ 1 x=5
+ 1 y=1
+ 1 x=5
+ 格子中是任期号和命令。浅青色已提交，淡紫色已写入日志但未提交。
+ 第 ③ 步时 C 还没有写入，但 Leader 和 B 已经构成 3 个节点中的多数，Leader 就可以提交、执行并回复客户端；
+ 已提交的日志一定在多数节点上，新 Leader 也一定包含它，所以不会丢失。C 落后或宕机恢复后，Leader 再把缺少的日志补给它。
+
diff --git a/tools/diagram/src/raft-split.svg b/tools/diagram/src/raft-split.svg
new file mode 100644
index 000000000..8f096d4f9
--- /dev/null
+++ b/tools/diagram/src/raft-split.svg
@@ -0,0 +1,63 @@
+
+
+
+
+
+
+
+
+
+
+ Raft 选举：选票被瓜分时进入下一个任期
+ 任期 4
+ 节点 A
+ 投 B
+ 节点 B
+ 候选人，2 票
+ 节点 C
+ 投 D
+ 节点 D
+ 候选人，2 票
+ B、D 同时超时，各得 2 票，都不足 3 票（4 个节点的多数），没有 Leader
+ 任期 5
+ 节点 A
+ 投 D
+ 节点 B
+ 投 D
+ 节点 C
+ 投 D
+ 节点 D
+ 候选人，4 票
+ 重新随机超时，D 先超时，得到全部选票，成为 Leader
+ 淡紫色是候选人，浅青色是当选的 Leader。随机超时让两个节点再次同时超时的概率很低。
+
diff --git a/tools/diagram/src/redis-aof-rewrite.svg b/tools/diagram/src/redis-aof-rewrite.svg
new file mode 100644
index 000000000..13dff8f69
--- /dev/null
+++ b/tools/diagram/src/redis-aof-rewrite.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+
+
+
+
+ AOF 重写：对 counter 执行 1000 次 INCR
+ 重写前
+ appendonly.aof.1.incr.aof
+ 27023 字节，1000 条命令
+ *2 $4 INCR $7 counter
+ *2 $4 INCR $7 counter
+ *2 $4 INCR $7 counter
+ ……
+ BGREWRITEAOF
+ 子进程按当前数据
+ 重新生成
+ 重写后
+ appendonly.aof.2.base.rdb
+ 105 字节，RDB 格式：counter = 1000
+ appendonly.aof.2.incr.aof
+ 0 字节，之后的写命令追加到这里
+ Redis 7.4 实测，文件在 appendonlydir 目录中，由 appendonly.aof.manifest 记录；aof-use-rdb-preamble 默认开启，基础文件用 RDB 格式。
+
diff --git a/tools/diagram/src/redis-article-hash.svg b/tools/diagram/src/redis-article-hash.svg
new file mode 100644
index 000000000..d0ac62044
--- /dev/null
+++ b/tools/diagram/src/redis-article-hash.svg
@@ -0,0 +1,63 @@
+
+
+
+
+
+
+
+
+
+
+ 文章信息：一篇文章是一个 HASH
+ article:1001
+ article
+ 命名空间
+ 1001
+ ID
+ 字段
+ 值
+ title
+ Redis 为什么快
+ author
+ user:2001
+ time
+ 1760923800（2025-10-20 09:30）
+ votes
+ 3
+ 相当于关系型数据库中 article 表里 id = 1001 的一行。
+
diff --git a/tools/diagram/src/redis-article-vote.svg b/tools/diagram/src/redis-article-vote.svg
new file mode 100644
index 000000000..e9d15569b
--- /dev/null
+++ b/tools/diagram/src/redis-article-vote.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+
+
+
+
+ 点赞：user:2004 给 article:1001 点赞
+ user:2004
+ ① SADD voted:1001 user:2004
+ 返回 1：第一次点赞
+ 返回 0：点过了
+ 拒绝
+ ② HINCRBY article:1001 votes 1
+ → 4
+ ③ ZINCRBY votes: 1 article:1001
+ → 4
+ voted:1001（SET）
+ user:2002
+ user:2003
+ user:2005
+ user:2004
+ 新增
+ EXPIRE 604800：7 天后自动删除
+ 超过一周不能再点赞，也不再占用内存
+ 已点赞的用户记在集合里，SADD 的返回值说明这个用户是否点过，防止重复点赞。
+ 三步可以放进一个 Lua 脚本中原子执行，避免只执行了一部分。
+
diff --git a/tools/diagram/src/redis-article-zsets.svg b/tools/diagram/src/redis-article-zsets.svg
new file mode 100644
index 000000000..4e1a90d6b
--- /dev/null
+++ b/tools/diagram/src/redis-article-zsets.svg
@@ -0,0 +1,73 @@
+
+
+
+
+
+
+
+
+
+
+ 排序：两个有序集合，成员都是文章 ID
+ time:（分值是发布时间）
+ 成员
+ 分值
+ article:1001
+ 1760923800
+ article:1002
+ 1761026400
+ article:1003
+ 1761135300
+ ZRANGE time: 0 9 REV
+ 最新的 10 篇：1003、1002、1001
+ votes:（分值是点赞数）
+ 成员
+ 分值
+ article:1003
+ 1
+ article:1001
+ 4
+ article:1002
+ 8
+ ZRANGE votes: 0 9 REV
+ 点赞最多的 10 篇：1002、1001、1003
+ 有序集合按分值从小到大排列，REV 表示倒序取；取到文章 ID 后再用 HGETALL 读出每篇文章的信息。
+
diff --git a/tools/diagram/src/redis-event-loop.svg b/tools/diagram/src/redis-event-loop.svg
new file mode 100644
index 000000000..c31a6a2e2
--- /dev/null
+++ b/tools/diagram/src/redis-event-loop.svg
@@ -0,0 +1,55 @@
+
+
+
+
+
+
+
+
+
+
+ 事件循环
+ 初始化服务器
+ ① 找到最近的时间事件
+ 例如 serverCron 还有 30 ms 到期
+ ② epoll_wait 最多等待 30 ms
+ 期间有文件事件就提前返回
+ ③ 处理已就绪的文件事件
+ 接受连接、执行命令、写回结果
+ ④ 处理已到期的时间事件
+ serverCron 默认每 100 ms 执行一次
+ 直到关闭
+ 等待时间由最近的时间事件决定：既不会一直阻塞在 epoll_wait 上，也不会空转。
+
diff --git a/tools/diagram/src/redis-file-event.svg b/tools/diagram/src/redis-file-event.svg
new file mode 100644
index 000000000..c0ddebd6b
--- /dev/null
+++ b/tools/diagram/src/redis-file-event.svg
@@ -0,0 +1,84 @@
+
+
+
+
+
+
+
+
+
+
+ 文件事件：一个线程处理多个客户端
+ 客户端 A
+ 新连接
+ 客户端 B
+ 发来 GET k
+ 客户端 C
+ 可以写回结果
+ I/O 多路复用
+ epoll_wait
+ 同时监听所有套接字
+ A
+ B
+ C
+ 就绪的事件
+ 分派
+ 连接应答处理器
+ A：accept 新连接
+ 命令请求处理器
+ B：读出并执行 GET k
+ 命令回复处理器
+ C：把结果写给客户端
+ 执行命令的始终是一个线程：事件按顺序逐个处理，所以单条命令是原子的，但一条慢命令会阻塞其它客户端。
+
diff --git a/tools/diagram/src/redis-hash.svg b/tools/diagram/src/redis-hash.svg
new file mode 100644
index 000000000..0d339f57b
--- /dev/null
+++ b/tools/diagram/src/redis-hash.svg
@@ -0,0 +1,57 @@
+
+
+
+
+
+
+
+
+
+
+ HASH
+ user:1001
+ 字段
+ 值
+ name
+ alice
+ age
+ 25
+ city
+ hangzhou
+ HGET、HINCRBY
+ 只读写一个字段
+ 一个键下存放多个字段和值，适合存储对象，修改一个字段不用读出整个对象。
+
diff --git a/tools/diagram/src/redis-list.svg b/tools/diagram/src/redis-list.svg
new file mode 100644
index 000000000..76ced145b
--- /dev/null
+++ b/tools/diagram/src/redis-list.svg
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+
+
+
+
+ LIST
+ orders:queue
+ 1024
+ 0
+ -3
+ 1025
+ 1
+ -2
+ 1026
+ 2
+ -1
+ 下标
+ 负数下标
+ LPUSH / LPOP
+ RPUSH / RPOP
+ 按插入顺序排列，元素可以重复；在两端插入和弹出是 O(1)，按下标访问要从一端数过去。
+
diff --git a/tools/diagram/src/redis-replica-chain.svg b/tools/diagram/src/redis-replica-chain.svg
new file mode 100644
index 000000000..2be345868
--- /dev/null
+++ b/tools/diagram/src/redis-replica-chain.svg
@@ -0,0 +1,90 @@
+
+
+
+
+
+
+
+
+
+
+ 主从链：中间层分担复制
+ 主服务器
+ 从服务器 1
+ 从服务器 2
+ 从服务器 3
+ 中间层既是上一层的从服务器，又是下一层的主服务器；主服务器只需向 3 台发送数据，而不是 12 台。
+
diff --git a/tools/diagram/src/redis-sentinel-failover.svg b/tools/diagram/src/redis-sentinel-failover.svg
new file mode 100644
index 000000000..5ba926c72
--- /dev/null
+++ b/tools/diagram/src/redis-sentinel-failover.svg
@@ -0,0 +1,76 @@
+
+
+
+
+
+
+
+
+
+
+ 哨兵故障转移：kill -9 主服务器之后（本机实测）
+ 0 s
+ 1 s
+ 2 s
+ 3 s
+ 4 s
+ 5 s
+ 6 s
+ 哨兵在 down-after-milliseconds（5 秒）内收不到回复
+ kill -9 主服务器 6400
+ 5.04 s ① 主观下线 +sdown
+ 5.14 s ② 客观下线 +odown，3 个哨兵都同意（quorum 2）
+ 5.22 s ③ 投票选出领头哨兵 +elected-leader
+ 5.28 s ④ 选中 6402 +selected-slave
+ 6.37 s ⑤ 6402 升为主服务器 +promoted-slave
+ 6.47 s ⑥ 通知切换 +switch-master
+ 1 主 2 从、3 个哨兵，quorum 为 2。约 6.5 秒后客户端从哨兵查到新地址 6402，之前写入的 order:1024 仍在；
+ 重启的 6400 被哨兵改为 6402 的从服务器。超时检测占了大部分时间，down-after-milliseconds 越小切换越快，
+ 但网络抖动时也越容易误判。
+
diff --git a/tools/diagram/src/redis-set.svg b/tools/diagram/src/redis-set.svg
new file mode 100644
index 000000000..d65db1892
--- /dev/null
+++ b/tools/diagram/src/redis-set.svg
@@ -0,0 +1,45 @@
+
+
+
+
+
+
+
+
+
+
+ SET
+ cache
+ nosql
+ redis
+ mysql
+ article:7:tags
+ article:8:tags
+ SINTER 得到交集 redis
+ 元素不重复，
+ 没有顺序
+
diff --git a/tools/diagram/src/redis-skiplist.svg b/tools/diagram/src/redis-skiplist.svg
new file mode 100644
index 000000000..53406c0ef
--- /dev/null
+++ b/tools/diagram/src/redis-skiplist.svg
@@ -0,0 +1,104 @@
+
+
+
+
+
+
+
+
+
+
+ 跳跃表：查找 26
+ 第 2 层
+ head
+ 15
+ 30
+ 第 1 层
+ head
+ 7
+ 15
+ 22
+ 30
+ 第 0 层
+ head
+ 3
+ 7
+ 11
+ 15
+ 19
+ 22
+ 26
+ 30
+ 37
+ 30 > 26，下降
+ 30 > 26，下降
+ 找到
+ 从最高层出发，下一个节点小于 26 就向右走，大于 26 就下降一层。
+ 共比较 5 次（15、30、22、30、26）；在最底层的链表中逐个查找要比较 7 次，节点越多差距越大。
+
diff --git a/tools/diagram/src/redis-string.svg b/tools/diagram/src/redis-string.svg
new file mode 100644
index 000000000..1fe0e4222
--- /dev/null
+++ b/tools/diagram/src/redis-string.svg
@@ -0,0 +1,49 @@
+
+
+
+
+
+
+
+
+
+
+ STRING
+ user:1001:name
+ alice
+ 字符串
+ page:views
+ 42
+ 整数，可以 INCR 自增
+ 一个键对应一个值，值可以是字符串、整数或浮点数，最大 512 MB。
+
diff --git a/tools/diagram/src/redis-zset.svg b/tools/diagram/src/redis-zset.svg
new file mode 100644
index 000000000..23a77e2e8
--- /dev/null
+++ b/tools/diagram/src/redis-zset.svg
@@ -0,0 +1,62 @@
+
+
+
+
+
+
+
+
+
+
+ ZSET
+ rank:score
+ 成员
+ 分值
+ bob
+ 85
+ 名次 0
+ alice
+ 92
+ 名次 1
+ carol
+ 97
+ 名次 2
+ 按分值从小到大排列，名次从 0 开始
+ 成员不重复，每个成员带一个分值；可以按名次或分值范围查询，适合排行榜。
+
diff --git a/tools/diagram/src/second-chance.svg b/tools/diagram/src/second-chance.svg
new file mode 100644
index 000000000..f41d3c914
--- /dev/null
+++ b/tools/diagram/src/second-chance.svg
@@ -0,0 +1,76 @@
+
+
+
+
+
+
+
+
+
+
+ 第二次机会：访问过的页面再给一次机会
+ (a) 时间 20 缺页
+ A R=1
+ 装入 0
+ B R=0
+ 装入 3
+ C R=1
+ 装入 7
+ D R=0
+ 装入 8
+ E R=1
+ 装入 12
+ 最老的 A 的 R = 1：清零，移到队尾，装入时间改为 20；再看 B，R = 0，换出 B
+ (b) 处理之后
+ C R=1
+ 装入 7
+ D R=0
+ 装入 8
+ E R=1
+ 装入 12
+ A R=0
+ 装入 20
+ 新页 R=1
+ 装入 20
+ 队头是最早装入的页面。FIFO 会直接换出刚被访问过的 A，第二次机会算法换出的是又老又没被访问的 B。
+
diff --git a/tools/diagram/src/segments.svg b/tools/diagram/src/segments.svg
new file mode 100644
index 000000000..9b3ccd967
--- /dev/null
+++ b/tools/diagram/src/segments.svg
@@ -0,0 +1,91 @@
+
+
+
+
+
+
+
+
+
+
+ 分段：每个段是独立的地址空间
+ 代码
+ 段 0
+ 长 12K
+ 全局数据
+ 段 1
+ 长 4K
+ 堆
+ 段 2
+ 长 8K
+ 可增长
+ 栈
+ 段 3
+ 长 8K
+ 可增长
+ 段表
+ 段号
+ 基址
+ 长度
+ 0
+ 0x4000
+ 12K
+ 1
+ 0x9000
+ 4K
+ 2
+ 0xC000
+ 8K
+ 3
+ 0x1C000
+ 8K
+ 地址 = (段号 2, 偏移 0x300)
+ 0x300 < 8K，没有越界
+ 物理地址 = 0xC000 + 0x300 = 0xC300
+ 偏移 ≥ 段长时触发越界异常
+ 各段长度不同、可以单独增长，并且可以按段设置权限（例如代码段只读）；但段的大小不固定，
+ 内存中会留下大小不一的空闲碎片。段页式在每个段内再分页，兼顾两者。
+
diff --git a/tools/diagram/src/shard-horizontal.svg b/tools/diagram/src/shard-horizontal.svg
new file mode 100644
index 000000000..3eb2c1404
--- /dev/null
+++ b/tools/diagram/src/shard-horizontal.svg
@@ -0,0 +1,87 @@
+
+
+
+
+
+
+
+
+
+
+ 水平切分：按 user_id % 2 把行分到两个库
+ orders（切分前）
+ order_id
+ user_id
+ 1024
+ 7
+ 1025
+ 8
+ 1026
+ 9
+ 1027
+ 10
+ 库 0 的 orders
+ order_id
+ user_id
+ 1025
+ 8
+ 1027
+ 10
+ 库 1 的 orders
+ order_id
+ user_id
+ 1024
+ 7
+ 1026
+ 9
+ 表结构相同，每个库只存一部分行
+ 按 user_id 查询只访问一个库；
+ 按其它条件查询要访问所有库
+ 同一个用户的订单落在同一个库，查询“某用户的订单”不需要跨库。
+
diff --git a/tools/diagram/src/shard-vertical.svg b/tools/diagram/src/shard-vertical.svg
new file mode 100644
index 000000000..f746e1844
--- /dev/null
+++ b/tools/diagram/src/shard-vertical.svg
@@ -0,0 +1,76 @@
+
+
+
+
+
+
+
+
+
+
+ 垂直切分：按列拆成两张表
+ product（切分前）
+ id
+ 1024
+ name
+ 键盘
+ price
+ 199
+ detail_html
+ <div>…20 KB…</div>
+ id
+ 1024
+ name
+ 键盘
+ price
+ 199
+ product：常用的列
+ id
+ 1024
+ detail_html
+ <div>…20 KB…</div>
+ product_detail：大字段
+ 列表页只查 product，一页能放下更多行；打开详情时再按 id 查 product_detail。
+
diff --git a/tools/diagram/src/short-url.svg b/tools/diagram/src/short-url.svg
new file mode 100644
index 000000000..2d03c47c6
--- /dev/null
+++ b/tools/diagram/src/short-url.svg
@@ -0,0 +1,100 @@
+
+
+
+
+
+
+
+
+
+
+ 短链系统：生成时取 ID 转 Base62，访问时查缓存返回 302
+ 生成
+ 运营人员
+ 短链服务
+ POST /shorten
+ 发号器
+ 号段 100000000～100000999
+ 本次取到 100000000
+ 100000000 转 Base62 → 6LAze
+ MySQL
+ 6LAze →
+ https://shop.example.com/item/1024
+ 访问
+ 浏览器
+ 短链服务
+ ① GET s.example/6LAze
+ Redis
+ ② 查 6LAze
+ 命中：返回长链接
+ 未命中时查 MySQL
+ 再写入缓存
+ ③ 302 Found
+ Location: https://shop.example.com/...
+ 浏览器收到 302 后再访问长链接。用 301 时浏览器会缓存跳转，之后的点击不再经过短链服务，无法统计点击量。
+
diff --git a/tools/diagram/src/snowflake.svg b/tools/diagram/src/snowflake.svg
new file mode 100644
index 000000000..1df1330cb
--- /dev/null
+++ b/tools/diagram/src/snowflake.svg
@@ -0,0 +1,56 @@
+
+
+
+
+
+
+
+
+
+
+ 雪花算法：64 位 ID 的组成
+ 0
+ 符号位
+ 1 位，固定为 0
+ 00001010010110100100001001111001110111101
+ 时间戳
+ 41 位：距 2024-01-01 的毫秒数
+ 0000000101
+ 机器 ID
+ 10 位：0～1023
+ 000000000000
+ 序号
+ 12 位：同一毫秒内 0～4095
+ 本机生成的一个 ID：372990889737342976
+ 时间戳 88927957949 ms → 2026-10-26 06:12:37.949（UTC），机器 ID 5，序号 0
+ 41 位毫秒数可以用 69.7 年；每台机器每毫秒最多 4096 个，即每秒约 409 万个。
+ 高位是时间，多台机器生成的 ID 整体上按时间递增，作为 InnoDB 主键时基本是顺序插入。
+ 需要注意的是，ID 依赖本机时钟：时钟回拨后可能生成重复的 ID，生成器发现当前时间小于上次的时间时，
+ 回拨很小就等待追上，较大就报错，由运维排查时钟同步。
+
diff --git a/tools/diagram/src/sql-flow.svg b/tools/diagram/src/sql-flow.svg
new file mode 100644
index 000000000..2db2a9479
--- /dev/null
+++ b/tools/diagram/src/sql-flow.svg
@@ -0,0 +1,95 @@
+
+
+
+
+
+
+
+
+
+
+ 一条 SELECT 在 MySQL 中的执行过程
+ SELECT * FROM orders WHERE user_id = 1024
+ AND create_time > '2025-01-10'
+ Server 层
+ 连接器
+ 校验用户名、密码和权限，维持连接
+ 解析器
+ 词法、语法分析，生成语法树
+ 写成 selec 时报 ERROR 1064
+ 预处理
+ 检查表和列是否存在
+ 写成 amout 时报 ERROR 1054 Unknown column
+ 优化器
+ 估算各种执行方式的代价，
+ 选择代价最小的（右表）
+ 执行器
+ 按执行计划调用存储引擎的接口，过滤、返回结果
+ 优化器估算的代价（optimizer trace）
+ 方案
+ 估算行数
+ 代价
+ 全表扫描
+ 1978736 行
+ 222512
+ idx_create_time
+ 989368 行
+ 934036
+ idx_user_status_time
+ 20 行
+ 2.27
+ InnoDB：先在 Buffer Pool 中找数据页，不在内存中才从磁盘读入
+ 按 idx_user_status_time 找到 20 条索引记录，用索引条件下推过滤 create_time，再回表取整行
+
diff --git a/tools/diagram/src/state-gumball.svg b/tools/diagram/src/state-gumball.svg
new file mode 100644
index 000000000..c2c2172c8
--- /dev/null
+++ b/tools/diagram/src/state-gumball.svg
@@ -0,0 +1,57 @@
+
+
+
+
+
+
+
+
+
+
+ 糖果机的状态转移
+ NoQuarterState
+ 没有投币
+ HasQuarterState
+ 已投币
+ SoldState
+ 出货中
+ SoldOutState
+ 售罄
+ insertQuarter()
+ ejectQuarter()
+ turnCrank()
+ dispense()，count > 0
+ dispense()，count == 0
+ GumballMachine 把每个操作转交给当前状态对象，状态对象在合适的时候调用 setState 切换状态，避免一大串 if-else。
+
diff --git a/tools/diagram/src/static-link.svg b/tools/diagram/src/static-link.svg
new file mode 100644
index 000000000..4bdb8ea4a
--- /dev/null
+++ b/tools/diagram/src/static-link.svg
@@ -0,0 +1,85 @@
+
+
+
+
+
+
+
+
+
+
+ 静态链接：符号解析和重定位
+ // main.c
+ int sum(int *a, int n);
+ int main() { return sum(arr, 2); }
+ // sum.c
+ int sum(int *a, int n) {
+ ... }
+ main.o
+ 引用 sum，地址未知
+ sum.o
+ 定义 sum
+ 链接器 ld
+ prog
+ 可执行目标文件
+ ① 符号解析：把 main.o 中
+ 对 sum 的引用对应到
+ sum.o 中的定义
+ ② 重定位：合并代码后确定
+ sum 的地址，填回 main 中
+ 调用指令的地址字段
+ 找不到定义时报 undefined reference，出现两个同名的强定义时报 multiple definition，都是在符号解析这一步发现的。
+
diff --git a/tools/diagram/src/template-recipe.svg b/tools/diagram/src/template-recipe.svg
new file mode 100644
index 000000000..ed04f7e2f
--- /dev/null
+++ b/tools/diagram/src/template-recipe.svg
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+
+
+
+
+ 模板方法：流程固定在父类，变化的步骤交给子类
+ CaffeineBeverage.prepareRecipe()
+ boilWater()
+ brew()
+ Coffee.brew
+ Tea.brew
+ pourInCup()
+ addCondiments()
+ Coffee.addCondiments
+ Tea.addCondiments
+ 咖啡
+ 茶
+ 灰色步骤在父类中实现，所有饮料共用；淡紫色是抽象方法，由子类实现。prepareRecipe 是 final 的，子类不能改变步骤的顺序。
+
diff --git a/tools/diagram/src/tls-handshake.svg b/tools/diagram/src/tls-handshake.svg
new file mode 100644
index 000000000..739766096
--- /dev/null
+++ b/tools/diagram/src/tls-handshake.svg
@@ -0,0 +1,82 @@
+
+
+
+
+
+
+
+
+
+
+ TLS 1.2 与 TLS 1.3 的握手（本机 openssl 实测的报文顺序）
+ TLS 1.2：www.baidu.com
+ 客户端
+ 服务器
+ ClientHello
+ ServerHello
+ Certificate
+ ServerKeyExchange
+ ECDHE 公钥 + 签名
+ ServerHelloDone
+ ClientKeyExchange
+ ECDHE 公钥
+ ChangeCipherSpec, Finished
+ ChangeCipherSpec, Finished
+ HTTP 请求（加密）
+ 2 个 RTT 后才能发送请求
+ TLS 1.3：www.example.com
+ 客户端
+ 服务器
+ ClientHello + key_share
+ 带上 ECDHE 公钥
+ ServerHello + key_share
+ {EncryptedExtensions}
+ {Certificate}
+ {CertificateVerify}
+ 用私钥签名
+ {Finished}
+ {Finished} + HTTP 请求
+ 1 个 RTT 后就能发送请求
+
diff --git a/tools/diagram/src/tool-call-text.svg b/tools/diagram/src/tool-call-text.svg
new file mode 100644
index 000000000..92b2b023f
--- /dev/null
+++ b/tools/diagram/src/tool-call-text.svg
@@ -0,0 +1,69 @@
+
+
+
+
+
+
+
+
+
+
+ Qwen2.5-7B 实际收到和输出的文本
+ <|im_start|>system
+ 系统消息
+ 你是电商客服助手，回答要简短。
+ # Tools ... <tools>
+ 推理服务按模板
+ {"name": "get_order", "description": "按订单号查询…"}
+ 拼入的工具定义
+ {"name": "get_logistics", ...}</tools>
+ <|im_start|>user 订单 1024 到哪了？
+ 用户消息
+ <|im_start|>assistant
+ <tool_call>
+ 模型生成的文本
+ {"name": "get_order", "arguments": {"order_id": "1024"}}
+ </tool_call>
+ <|im_start|>user
+ 应用执行工具后，
+ <tool_response>{"status": "已发货", "tracking_no": "SF1234567"}
+ 把结果放回去
+ </tool_response>
+ 第 2 次调用时，上面的全部文本加上工具结果一起重新发给模型，共 327 个 Token；第 1 次是 255 个。
+ tool_calls、tool 角色这些结构化字段，在模型看来都只是这样一段特定格式的文本。
+
diff --git a/tools/diagram/src/txn-dirty-read.svg b/tools/diagram/src/txn-dirty-read.svg
new file mode 100644
index 000000000..48e300656
--- /dev/null
+++ b/tools/diagram/src/txn-dirty-read.svg
@@ -0,0 +1,57 @@
+
+
+
+
+
+
+
+
+
+
+ 读脏数据：读到了另一个事务没有提交的修改
+ 事务 T1
+ 事务 T2
+ READ UNCOMMITTED
+ 时间
+ BEGIN
+ UPDATE account SET balance = 200 WHERE id = 1
+ SELECT balance FROM account WHERE id = 1
+ → 200
+ ROLLBACK
+ SELECT balance FROM account WHERE id = 1
+ → 100
+ T2 读到的 200 从来没有提交过。
+ T2 的隔离级别为 READ COMMITTED 及以上时，第一次读到的是 100。
+
diff --git a/tools/diagram/src/txn-flow.svg b/tools/diagram/src/txn-flow.svg
new file mode 100644
index 000000000..7971e3086
--- /dev/null
+++ b/tools/diagram/src/txn-flow.svg
@@ -0,0 +1,62 @@
+
+
+
+
+
+
+
+
+
+
+ 事务：要么全部提交，要么全部回滚
+ 从 A 账户向 B 账户转账 30 元
+ 一致的状态
+ A = 100
+ B = 0
+ 中间状态
+ A = 70
+ B = 0
+ 中间状态
+ A = 70
+ B = 30
+ 一致的状态
+ A = 70
+ B = 30
+ A − 30
+ B + 30
+ COMMIT
+ 出错或执行 ROLLBACK：用 undo log 撤销已做的修改，回到初始状态
+ 在提交读及以上的隔离级别下，中间状态只有当前事务看得到；提交后修改才对其它事务可见，并由 redo log 保证不会丢失。
+ A、B 两个账户的余额总和在事务前后都是 100，这就是一致性。
+
diff --git a/tools/diagram/src/txn-lost-update.svg b/tools/diagram/src/txn-lost-update.svg
new file mode 100644
index 000000000..4d0ef5781
--- /dev/null
+++ b/tools/diagram/src/txn-lost-update.svg
@@ -0,0 +1,63 @@
+
+
+
+
+
+
+
+
+
+
+ 丢失修改：两个事务基于同一个旧值计算后写回
+ 事务 T1：取出 30 元
+ REPEATABLE READ
+ 事务 T2：存入 50 元
+ REPEATABLE READ
+ 时间
+ SELECT balance FROM account WHERE id = 1
+ → 100
+ SELECT balance FROM account WHERE id = 1
+ → 100
+ UPDATE account SET balance = 70 WHERE id = 1
+ COMMIT
+ UPDATE account SET balance = 150 WHERE id = 1
+ COMMIT
+ SELECT balance FROM account WHERE id = 1
+ → 150
+ 正确结果应为 120，T1 取出的 30 元丢失了。
+ 改为 SET balance = balance - 30 后，T2 的 UPDATE 会等待 T1 的行锁，再在 70 的基础上加 50，结果为 120。
+
diff --git a/tools/diagram/src/txn-non-repeatable.svg b/tools/diagram/src/txn-non-repeatable.svg
new file mode 100644
index 000000000..d309655cb
--- /dev/null
+++ b/tools/diagram/src/txn-non-repeatable.svg
@@ -0,0 +1,58 @@
+
+
+
+
+
+
+
+
+
+
+ 不可重复读：同一个事务两次读取同一行，结果不同
+ 事务 T1
+ 自动提交
+ 事务 T2
+ READ COMMITTED
+ 时间
+ BEGIN
+ SELECT balance FROM account WHERE id = 1
+ → 100
+ UPDATE account SET balance = 200 WHERE id = 1
+ SELECT balance FROM account WHERE id = 1
+ → 200
+ COMMIT
+ T1 在 T2 的两次读取之间修改并提交了这一行。
+ T2 的隔离级别为 REPEATABLE READ 时，第二次读到的仍然是 100。
+
diff --git a/tools/diagram/src/txn-phantom.svg b/tools/diagram/src/txn-phantom.svg
new file mode 100644
index 000000000..4f783d82c
--- /dev/null
+++ b/tools/diagram/src/txn-phantom.svg
@@ -0,0 +1,58 @@
+
+
+
+
+
+
+
+
+
+
+ 幻影读：同一个事务两次范围查询，行数不同
+ 事务 T1
+ 自动提交
+ 事务 T2
+ READ COMMITTED
+ 时间
+ BEGIN
+ SELECT id FROM account WHERE balance > 50
+ → 1,2
+ INSERT INTO account VALUES (3, 100)
+ SELECT id FROM account WHERE balance > 50
+ → 1,2,3
+ COMMIT
+ T1 在 T2 查询的范围内插入了新的一行。
+ T2 的隔离级别为 REPEATABLE READ 时，第二次查询仍然只有 1、2。
+
diff --git a/tools/diagram/src/url-timeline.svg b/tools/diagram/src/url-timeline.svg
new file mode 100644
index 000000000..f7faea580
--- /dev/null
+++ b/tools/diagram/src/url-timeline.svg
@@ -0,0 +1,63 @@
+
+
+
+
+
+
+
+
+
+
+ 访问 https://www.example.com/ 的耗时（本机一次实测，RTT 约 200 ms）
+ DNS 解析
+ 10 ms，命中缓存
+ TCP 三次握手
+ 1 个 RTT
+ TLS 1.3 握手
+ 1 个 RTT
+ 请求到首字节
+ 1 个 RTT + 服务器处理
+ 0 ms
+ 100 ms
+ 200 ms
+ 300 ms
+ 400 ms
+ 500 ms
+ 600 ms
+ curl -w 测得：time_connect 0.210 s、time_appconnect 0.423 s、time_starttransfer 0.629 s。
+ HTTPS 首次请求至少要 3 个 RTT 才能收到响应，这也是连接复用、TLS 会话恢复和 HTTP/3 要解决的问题。
+
diff --git a/tools/diagram/src/vm-mapping.svg b/tools/diagram/src/vm-mapping.svg
new file mode 100644
index 000000000..0987ac221
--- /dev/null
+++ b/tools/diagram/src/vm-mapping.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+
+
+
+
+ 虚拟内存：64 KB 的地址空间，只有 32 KB 物理内存
+ 虚拟页（4 KB 一页）
+ 2
+ 0K～4K
+ 0
+ 7
+ 4K～8K
+ 1
+ ×
+ 8K～12K
+ 2
+ 5
+ 12K～16K
+ 3
+ ×
+ 16K～20K
+ 4
+ 0
+ 20K～24K
+ 5
+ ×
+ 24K～28K
+ 6
+ ×
+ 28K～32K
+ 7
+ 3
+ 32K～36K
+ 8
+ ×
+ 36K～40K
+ 9
+ ×
+ 40K～44K
+ 10
+ 6
+ 44K～48K
+ 11
+ ×
+ 48K～52K
+ 12
+ ×
+ 52K～56K
+ 13
+ 4
+ 56K～60K
+ 14
+ ×
+ 60K～64K
+ 15
+ 物理页框
+ 页 5
+ 0K～4K
+ 0
+ 空闲
+ 4K～8K
+ 1
+ 页 0
+ 8K～12K
+ 2
+ 页 8
+ 12K～16K
+ 3
+ 页 14
+ 16K～20K
+ 4
+ 页 3
+ 20K～24K
+ 5
+ 页 11
+ 24K～28K
+ 6
+ 页 1
+ 28K～32K
+ 7
+ 左边格子中的数字是页框号，× 表示这一页不在内存中，访问它会触发缺页中断，由操作系统从磁盘调入。
+ 只有 7 页在内存中，程序照样可以运行；各页映射到哪个页框没有顺序要求。
+
diff --git a/tools/diagram/src/zero-copy.svg b/tools/diagram/src/zero-copy.svg
new file mode 100644
index 000000000..6894606e5
--- /dev/null
+++ b/tools/diagram/src/zero-copy.svg
@@ -0,0 +1,85 @@
+
+
+
+
+
+
+
+
+
+
+ 零拷贝：sendfile 让数据不经过用户空间
+ read + write：4 次拷贝，2 次系统调用带来 4 次用户态与内核态的切换
+ 用户空间
+ 内核空间
+ 硬件
+ 磁盘
+ 页缓存
+ 应用的缓冲区
+ Socket 缓冲区
+ 网卡
+ ① DMA
+ ② CPU
+ ③ CPU
+ ④ DMA
+ read()
+ write()
+ sendfile：数据留在内核中，网卡支持 SG-DMA 时 CPU 不拷贝数据
+ 用户空间
+ 内核空间
+ 硬件
+ 磁盘
+ 页缓存
+ Socket 缓冲区
+ 网卡
+ 应用只调用一次 sendfile()
+ ① DMA
+ 只追加地址和长度
+ ② DMA：网卡直接从页缓存读取
+ Kafka 的 broker 把日志文件发给消费者时使用 sendfile。启用 TLS 后数据要在用户空间加密，就不再使用零拷贝。
+ 网卡不支持 SG-DMA 时，sendfile 仍要由 CPU 把页缓存中的数据拷贝到 Socket 缓冲区，共 3 次拷贝。
+
