Merge 0682a55265856bc7594e39b1c71c63335be26654 into 02ec4e4150e46d0ec9be08778c525cc622caab79

缓存雪崩中笔误校正

docs/cs-basics/operating-system/operating-system-basic-questions-02.md

@@ -321,8 +321,12 @@ LRU 算法是实际使用中应用的比较多，也被认为是最接近 OPT
 
 在段页式机制下，地址翻译的过程分为两个步骤：
 
-1. 段式地址映射：段式转换将虚拟地址（段选择符+段内偏移）转换为线性地址（通过段基址+偏移计算）。
+1. **段式地址映射（虚拟地址 → 线性地址）：**
-2. 页式地址映射：页式转换将线性地址拆分为页号+页内偏移，通过页表映射到物理地址。
+   - 虚拟地址 = 段选择符（段号）+ 段内偏移。
+   - 根据段号查段表，找到段基址，加上段内偏移得到线性地址。
+2. **页式地址映射（线性地址 → 物理地址）：**
+   - 线性地址 = 页号 + 页内偏移。
+   - 根据页号查页表，找到物理页框号，加上页内偏移得到物理地址。
 
 ### 局部性原理
 

docs/database/redis/redis-questions-02.md

@@ -703,7 +703,7 @@ Bloom Filter 会使用一个较大的 bit 数组来保存所有的数据，数
 
 ![缓存雪崩](https://oss.javaguide.cn/github/javaguide/database/redis/redis-cache-avalanche.png)
 
-举个例子：数据库中的大量数据在同一时间过期，这个时候突然有大量的请求需要访问这些过期的数据。这就导致大量的请求直接落到数据库上，对数据库造成了巨大的压力。
+举个例子：缓存中的大量数据在同一时间过期，这个时候突然有大量的请求需要访问这些过期的数据。这就导致大量的请求直接落到数据库上，对数据库造成了巨大的压力。
 
 #### 有哪些解决办法？
 
@@ -779,7 +779,7 @@ Cache Aside Pattern 中遇到写请求是这样的：更新数据库，然后直
 1. 使用连接池：避免频繁创建关闭客户端连接。
 2. 尽量不使用 O(n) 指令，使用 O(n) 命令时要关注 n 的数量：像 `KEYS *`、`HGETALL`、`LRANGE`、`SMEMBERS`、`SINTER`/`SUNION`/`SDIFF` 等 O(n) 命令并非不能使用，但是需要明确 n 的值。另外，有遍历的需求可以使用 `HSCAN`、`SSCAN`、`ZSCAN` 代替。
 3. 使用批量操作减少网络传输：原生批量操作命令（比如 `MGET`、`MSET` 等等）、pipeline、Lua 脚本。
-4. 尽量不适用 Redis 事务：Redis 事务实现的功能比较鸡肋，可以使用 Lua 脚本代替。
+4. 尽量不使用 Redis 事务：Redis 事务实现的功能比较鸡肋，可以使用 Lua 脚本代替。
 5. 禁止长时间开启 monitor：对性能影响比较大。
 6. 控制 key 的生命周期：避免 Redis 中存放了太多不经常被访问的数据。
 7. ……

docs/java/collection/arrayblockingqueue-source-code.md

@@ -11,7 +11,7 @@ tag:
 
 Java 阻塞队列的历史可以追溯到 JDK1.5 版本，当时 Java 平台增加了 `java.util.concurrent`，即我们常说的 JUC 包，其中包含了各种并发流程控制工具、并发容器、原子类等。这其中自然也包含了我们这篇文章所讨论的阻塞队列。
 
-为了解决高并发场景下多线程之间数据共享的问题，JDK1.5 版本中出现了 `ArrayBlockingQueue` 和 `LinkedBlockingQueue`，它们是带有生产者-消费者模式实现的并发容器。其中，`ArrayBlockingQueue` 是有界队列，即添加的元素达到上限之后，再次添加就会被阻塞或者抛出异常。而 `LinkedBlockingQueue` 则由链表构成的队列，正是因为链表的特性，所以 `LinkedBlockingQueue` 在添加元素上并不会向 `ArrayBlockingQueue` 那样有着较多的约束，所以 `LinkedBlockingQueue` 设置队列是否有界是可选的(注意这里的无界并不是指可以添加任务数量的元素，而是说队列的大小默认为 `Integer.MAX_VALUE`，近乎于无限大)。
+为了解决高并发场景下多线程之间数据共享的问题，JDK1.5 版本中出现了 `ArrayBlockingQueue` 和 `LinkedBlockingQueue`，它们是带有生产者-消费者模式实现的并发容器。其中，`ArrayBlockingQueue` 是有界队列，即添加的元素达到上限之后，再次添加就会被阻塞或者抛出异常。而 `LinkedBlockingQueue` 则由链表构成的队列，正是因为链表的特性，所以 `LinkedBlockingQueue` 在添加元素上并不会向 `ArrayBlockingQueue` 那样有着较多的约束，所以 `LinkedBlockingQueue` 设置队列是否有界是可选的(注意这里的无界并不是指可以添加任意数量的元素，而是说队列的大小默认为 `Integer.MAX_VALUE`，近乎于无限大)。
 
 随着 Java 的不断发展，JDK 后续的几个版本又对阻塞队列进行了不少的更新和完善:
 

docs/java/concurrent/atomic-classes.md

@@ -341,7 +341,7 @@ Final Reference: Daisy, Final Mark: true
 - `AtomicLongFieldUpdater`：原子更新长整形字段的更新器
 - `AtomicReferenceFieldUpdater`：原子更新引用类型里的字段的更新器
 
-要想原子地更新对象的属性需要两步。第一步，因为对象的属性修改类型原子类都是抽象类，所以每次使用都必须使用静态方法 newUpdater()创建一个更新器，并且需要设置想要更新的类和属性。第二步，更新的对象属性必须使用 public volatile 修饰符。
+要想原子地更新对象的属性需要两步。第一步，因为对象的属性修改类型原子类都是抽象类，所以每次使用都必须使用静态方法 newUpdater()创建一个更新器，并且需要设置想要更新的类和属性。第二步，更新的对象属性必须使用 volatile int 修饰符。
 
 上面三个类提供的方法几乎相同，所以我们这里以 `AtomicIntegerFieldUpdater`为例子来介绍。
 
@@ -351,8 +351,8 @@ Final Reference: Daisy, Final Mark: true
 // Person 类
 class Person {
     private String name;
-    // 要使用 AtomicIntegerFieldUpdater，字段必须是 public volatile
+    // 要使用 AtomicIntegerFieldUpdater，字段必须是 volatile int
-    private volatile int age;
+    volatile int age;
     //省略getter/setter和toString
 }