很多团队写批处理任务的第一反应是 MapReduce，但真正跑起来才发现：一个简单的 WordCount 要拆成 Map 和 Reduce 两个阶段，中间结果全部落盘 HDFS，稍复杂的迭代算法要串起十几个 MR 作业，每一个都在读写磁盘。Spark 用 DAG 执行引擎 + 基于内存的计算 把这个问题彻底重做了一遍。本文从原理到实战，把 Spark 最容易被问、最容易踩坑的部分一次讲透。

一、为什么需要 Spark：MapReduce 的三大痛点

MapReduce 是第一代批处理引擎，但它天生”腿短”：

Spark 生态覆盖了统一的计算场景：Spark Core（RDD 内核）、Spark SQL（结构化数据 + Catalyst 优化器）、Spark Streaming / Structured Streaming（流计算）、MLlib（机器学习）、GraphX（图计算）。部署上支持 Local、Standalone、YARN、Kubernetes 四种模式，生产以 YARN / K8s 为主。

二、RDD：Spark 的基石

2.1 RDD 是什么

RDD（Resilient Distributed Dataset，弹性分布式数据集）是一个不可变、可分区、可并行计算的元素集合。”弹性”体现在三层：

• 存储弹性：内存不够自动落盘，磁盘不够自动重算；
• 计算弹性：失败自动通过血缘（Lineage）重算恢复；
• 分区弹性：分区数随时可以重新划分（repartition / coalesce）。

源码里 RDD 的注释写明了五大特性，面试高频，务必能背出主干：

2.2 算子体系：Transformation 与 Action

RDD 算子分两类，这个区分决定了作业什么时候真正执行：

1
2
3
4
5
6

val lines = sc.textFile("hdfs://data/logs")            // Transformation：不执行
val errors = lines.filter(_.contains("ERROR"))          // Transformation：不执行
val wc = errors.flatMap(_.split(" "))
  .map((_, 1))
  .reduceByKey(_ + _)                                   // Transformation：仍不执行
wc.collect()                                            // Action：触发真正计算

三、宽窄依赖与 DAG：Stage 划分的分界线

3.1 宽依赖 vs 窄依赖

DAG 划分 Stage 的规则：从后往前，遇到宽依赖就切一刀。 每个切出来的阶段是一个 Stage，Stage 内部尽量流水线执行，Shuffle 是两个 Stage 之间的数据交换边界。

3.2 一个例子看懂 Stage 划分

1
2
3
4
5
6
7

sc.textFile("data.txt")          // Stage 0 开始
  .flatMap(_.split(" "))         // 窄
  .map((_, 1))                   // 窄
  .reduceByKey(_ + _)            // 宽依赖 → 在此切分 Stage
  .map(kv => (kv._2, kv._1))     // Stage 1
  .sortByKey(ascending = false)  // 宽依赖 → 切分
  .collect()                     // Stage 2（Action 触发 Job）

整条链被切成 3 个 Stage：前两个窄操作被”打包”进同一个 Stage 流水线执行，reduceByKey 和 sortByKey 各自切开一个新 Stage。

四、任务调度：从 Job 到 Task 的完整链路

一个 Action 触发后，调度链路如下：

1
2
3
4
5

Application
 └── Job（每个 Action 一个）
      └── Stage（DAGScheduler 按宽依赖切分）
           └── TaskSet（Stage 内所有分区的任务集合）
                └── Task（TaskScheduler 分发到 Executor 执行）

关键角色：

• DAGScheduler：负责把血缘 DAG 按 Stage 划分、维护 Stage 依赖、提交”没有父依赖”的 Stage；同时处理 ShuffleMapStage 与 ResultStage 的区分。
• TaskScheduler：把 TaskSet 里的 Task 按本地性级别（PROCESS_LOCAL → NODE_LOCAL → ANY）分发给 Executor，支持推测执行（Speculative Execution）：某个 Task 明显慢于同 Stage 均值时，另起一个备份 Task，谁先完成用谁的结果。
• Executor：以线程池方式执行 Task（MapReduce 是进程级，启动开销大），这是 Spark 秒级延迟的另一个原因。

五、Shuffle：性能问题的 80% 都在这

Shuffle 是宽依赖的数据交换过程——按 Key 把数据重新分发到不同的下游分区。它是 Spark 里最昂贵、也最值得调优的环节。

5.1 HashShuffle：为什么被淘汰

未优化的 HashShuffle 中，每个 Map Task 为每个 Reduce Task 生成一个文件：

1
2

小文件数 = Map Task 数 × Reduce Task 数
1000 map × 1000 reduce = 100 万个小文件

文件句柄耗尽、磁盘随机 IO 打爆、GC 频繁。优化后的 Consolidate 机制把同一 Executor 上 Core 的输出合并为 CPU 核数 × Reduce Task 数，但依然治标不治本。

5.2 SortShuffle：现在的默认机制（1.2+）

SortShuffle 的核心思路：每个 Map Task 只输出一个按分区有序的数据文件 + 一个索引文件。

1. 数据写入内存排序结构（PartitionedAppendOnlyMap），超过阈值后溢写成临时文件；
2. 最终把所有溢写文件归并成一个数据文件，按 Reduce 分区有序排列；
3. Reduce Task 根据索引文件偏移量拉取属于自己的数据段。

Bypass 机制是 SortShuffle 的”轻量通道”：当 Reduce Task 数 ≤ spark.shuffle.sort.bypassMergeThreshold（默认 200）且算子不需要 map 端聚合（如 groupBy，而非 reduceByKey）时，跳过排序，直接按分区写文件再归并——用 HashShuffle 的写法拿到单文件的好处。

5.3 Reduce 端拉取与关键参数

Reduce 端通过 HTTP 拉取数据，相关参数直接影响稳定性：

六、内存管理：统一内存管理模型

Spark 1.6+ 采用 UnifiedMemoryManager（统一内存管理），Executor 堆内空间划分如下：

1
2
3
4
5
6

Executor 堆内内存
├── Reserved Memory：固定 300MB
├── User Memory：(1 - spark.memory.fraction) × 堆，存用户数据结构、RDD 依赖等
└── Unified Memory（spark.memory.fraction = 0.6）
     ├── Execution Memory：Shuffle / Join / Sort / 聚合 —— 不被抢占
     └── Storage Memory（storageFraction = 0.5）：缓存 RDD / 广播变量 —— 可被驱逐落盘

堆外内存通过 spark.memory.offHeap.enabled 开启，用 spark.executor.memoryOverhead 预留堆外空间（YARN/K8s 下默认为堆的 10%），容器总内存 = 堆 + 堆外 + overhead，配小了会被 YARN 直接 kill。

七、持久化与容错：Lineage 与 Checkpoint

7.1 缓存：persist / cache

缓存本身不切断血缘——缓存分区丢失时，仍然沿血缘重算。

7.2 Checkpoint：斩断血缘

血缘太长时（迭代算法、长链路转换），单分区失败的重算代价会指数级膨胀。checkpoint 把 RDD 完整写入高可靠存储（HDFS）并清空血缘，失败后直接从 checkpoint 恢复：

1
2
3
4

sc.setCheckpointDir("hdfs://checkpoints")
val result = longLineageRdd.persist()
result.checkpoint()          // 必须在 Action 之前设置
result.count()               // 触发时顺带写入 checkpoint

实践口诀：先 persist 再 checkpoint——否则 checkpoint 会把血缘完整重算一遍，等于白算两次。

八、数据倾斜：定位与治理套路

8.1 现象与定位

• 现象：绝大多数 Task 几秒跑完，个别 Task 卡几十分钟甚至 OOM；
• 定位：Web UI 的 Stage 页看 Task 的 Shuffle Read Size 分布是否长尾；df.groupBy(key).count().orderBy("count", ascending=False) 检查热点 Key。

8.2 治理方案（按优先级）

方案一：过滤或单独处理异常 Key。 如果倾斜来自 null、"" 等脏数据，先过滤；如果是个别真实大 Key，把它们捞出来单独跑，再和主流程结果合并。

方案二：广播 Join（小表广播）。 大小表 Join 时避免 Shuffle：

1
2

import org.apache.spark.sql.functions.broadcast
val joined = bigDF.join(broadcast(smallDF), "user_id")   // 小表全量广播到各 Executor

阈值由 spark.sql.autoBroadcastJoinThreshold（默认 10MB）控制，超过时需手动 broadcast() 或调大阈值（注意广播本身占内存）。

方案三：加盐两阶段聚合。 对 reduceByKey 类聚合的倾斜 Key 加随机前缀，先局部聚合打散热点，再去前缀做全局聚合：

1
2
3
4
5
6

// 第一阶段：key 加 0~N 随机前缀，局部聚合
val partial = rdd.map { case (k, v) => ((Random.nextInt(10) + "_" + k), v) }
  .reduceByKey(_ + _)
// 第二阶段：去掉前缀，全局聚合
val global = partial.map { case (pk, v) => (pk.split("_")(1), v) }
  .reduceByKey(_ + _)

方案四：提高 Shuffle 并行度。 调大 spark.sql.shuffle.partitions，让热点 Key 的数据被切得更碎，缓解（而非根治）倾斜。

九、横向对比：Spark vs MapReduce vs Flink

选型经验：离线批处理选 Spark，实时流处理选 Flink，两者不是替代关系。Kafka + Spark/Flink 是流式架构最常见的组合（Kafka 负责缓冲与解耦，计算引擎负责处理）。

十、生产避坑清单

1. 并行度别拍脑袋：理想状态是 Task 数 = 总 Core 数的 2~3 倍；spark.sql.shuffle.partitions=200 对小数据是浪费、对大数据是瓶颈，按单分区 128MB~256MB 反推。
2. 别用 collect() 拉全量数据：Driver OOM 的头号来源，调试用 take(n) / limit(n)，落盘用 write。
3. 小文件问题：频繁写 Hive/对象存储会产生海量小文件，写入前 coalesce(n) 合并分区（保序减少数据移动用 coalesce，允许全量重分布用 repartition）。
4. Kryo 序列化：spark.serializer=org.apache.spark.serializer.KryoSerializer，自定义类注册 registerKryoClasses，比 Java 序列化快 10 倍、体积小一半。
5. 缓存不是越多越好：MEMORY_ONLY 缓存被频繁淘汰重算时反而更慢；缓存前先评估重用次数与分区大小，用 unpersist() 及时释放。
6. GC 调优顺序：先调内存分配（fraction / overhead），再看 GC 日志选收集器；spark.executor.cores=4~5 能减少 HDFS 客户端并发争抢。
7. 广播变量只读：Executor 端修改广播变量不会同步回 Driver，也看不到——它本质是只读快照。
8. Spill 不等于故障：Shuffle 溢写是正常兜底机制；持续大量 Spill 才说明内存给少了或倾斜了，结合 Web UI 的 Spill (memory/disk) 指标判断。

面试里问完并发、集合，下一个必考的就是 I/O 与网络编程。本文不重复线程池、《Java 并发编程核心》里的 volatile/CAS/AQS，也不展开集合源码，而是聚焦一个独立主题：Java 到底怎么读写数据、怎么用少量线程扛住海量连接。读完你能回答：BIO 为什么扛不住 C10K？Selector 凭什么一个线程管几万个连接？零拷贝究竟”零”掉了什么？

一、为什么 I/O 模型是 Java 工程师的分水岭

写业务代码时，I/O 往往被框架封装得无影无踪（Spring MVC 一个 @RequestMapping 就完事）。但一旦要写中间件、网关、RPC 框架、消息队列客户端，或者排查”线程一路涨到几万、GC 频繁、CPU 却不高”的线上问题，I/O 模型的理解深度就直接决定了你的定位能力。

I/O 的本质只有一句话：数据在「用户空间」与「内核空间」之间的搬运。所有模型差异，都是”这段搬运由谁触发、要不要阻塞线程、要不要来回切换”的组合。

二、先把概念厘清：阻塞/非阻塞、同步/异步

这两组词最容易被混用，必须彻底分开看，它们描述的是两个正交维度：

• 阻塞 vs 非阻塞：描述”应用程序发起系统调用后，线程会不会被挂起”。阻塞调用会交出 CPU 让出线程；非阻塞调用立刻返回，即使数据还没准备好。
• 同步 vs 异步：描述”数据从内核拷贝到用户空间这一步，由谁来完成、结果如何通知”。

UNIX 网络编程里经典的五种 I/O 模型：

1. 阻塞 I/O：最传统，读/写/accept 全程阻塞。
2. 非阻塞 I/O：轮询，CPU 空转严重。
3. I/O 多路复用：select/poll/epoll，一个线程监听多个 fd（NIO 的 Selector）。
4. 信号驱动 I/O：内核用信号通知就绪，实际使用少。
5. 异步 I/O：内核完成全部工作后通知（AIO，Linux 上实现有争议）。

三、BIO：传统阻塞式 I/O

3.1 字节流与字符流体系

Java 传统 I/O（java.io）以两个维度组织：输入/输出 × 字节/字符。

1
2
3
4
5
6
7
8
9

InputStream（字节输入）      OutputStream（字节输出）
 ├ FileInputStream           ├ FileOutputStream
 ├ ByteArrayInputStream      ├ ByteArrayOutputStream
 ├ BufferedInputStream       ├ BufferedOutputStream
 └ FilterInputStream         └ FilterOutputStream
Reader（字符输入）           Writer（字符输出）
 ├ FileReader                ├ FileWriter
 ├ InputStreamReader         ├ OutputStreamWriter
 └ BufferedReader            └ BufferedWriter

字节流以 8 位为单位，处理一切二进制数据（图片、音频、网络包）；字符流以 char（UTF-16 码元）为单位，内部靠 StreamDecoder/StreamEncoder 做编码转换。读写文本优先用字符流，避免手动处理编码导致中文乱码。

3.2 装饰器模式：缓冲流的真正价值

java.io 是装饰器模式的教科书实现：节点流负责”连到数据源”，处理流负责”增强能力”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 不加缓冲：每次 read() 都可能触发一次系统调用
try (InputStream in = new FileInputStream("big.txt")) {
    int b;
    while ((b = in.read()) != -1) { /* 逐字节读，慢 */ }
}

// 加缓冲：一次性读 8KB 到内存，后续命中缓冲区
try (BufferedReader br = new BufferedReader(
        new InputStreamReader(new FileInputStream("big.txt"), StandardCharsets.UTF_8))) {
    String line;
    while ((line = br.readLine()) != null) {
        System.out.println(line);
    }
}

3.3 BIO 的致命伤：一连接一线程

传统服务端写法：ServerSocket.accept() 会阻塞，每来一个连接就 new Thread 处理。

1
2
3
4
5

ServerSocket serverSocket = new ServerSocket(8080);
while (true) {
    Socket socket = serverSocket.accept();      // 阻塞，直到有连接
    new Thread(() -> handle(socket)).start();   // 一连接一线程
}

问题很直接：线程是稀缺资源。每个线程默认占用约 1MB 栈空间，且线程上下文切换有成本。1000 个连接就要 1000 个线程，1 万个就是 C10K 问题——线程创建/切换直接压垮系统。

四、NIO 三件套之一：Buffer（缓冲区）

NIO（java.nio）与流最大的区别是面向缓冲区：数据不再逐字节流动，而是先读进 Buffer 再处理。

Buffer 通过四个指针控制读写：

读模式与写模式切换靠 flip()，这是最容易踩坑的地方：

1
2
3
4
5
6
7

ByteBuffer buf = ByteBuffer.allocate(1024);
buf.put("hello".getBytes());   // 写模式：position=5, limit=1024
buf.flip();                    // 切换到读模式：limit=5, position=0
while (buf.hasRemaining()) {
    System.out.print((char) buf.get());
}
buf.clear();                   // 清空，回到写模式：position=0, limit=capacity

三个高频方法的区别：

• flip()：limit = position; position = 0，写→读。
• clear()：position = 0; limit = capacity，丢弃全部数据。
• compact()：把未读完的数据挪到头部，再切回写模式（部分消费场景用）。

五、NIO 三件套之二：Channel（通道）

Channel 与流的根本区别：

• 双向：一个 Channel 既可读也可写（流是单向的）。
• 面向缓冲区：读写必须通过 Buffer。
• 可非阻塞：可注册到 Selector 实现多路复用。

常用实现：

1
2
3
4
5
6
7
8
9

try (FileChannel in = FileChannel.open(Paths.get("a.dat"), StandardOpenOption.READ);
     FileChannel out = FileChannel.open(Paths.get("b.dat"),
             StandardOpenOption.CREATE, StandardOpenOption.WRITE)) {
    long size = in.size();
    long pos = 0;
    while (pos < size) {
        pos += in.transferTo(pos, size - pos, out);   // 零拷贝搬运
    }
}

六、NIO 三件套之三：Selector（多路复用器）

Selector 是 NIO 的灵魂：一个线程通过一个 Selector 监听多个 Channel 的就绪事件，从而用极少的线程支撑海量连接。

SelectionKey 的四种事件：

一个可运行的 NIO Echo 服务端骨架：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

ServerSocketChannel ssc = ServerSocketChannel.open();
ssc.bind(new InetSocketAddress(8080));
ssc.configureBlocking(false);                 // 必须非阻塞才能注册
Selector selector = Selector.open();
ssc.register(selector, SelectionKey.OP_ACCEPT);

ByteBuffer buf = ByteBuffer.allocate(1024);
while (true) {
    selector.select();                        // 阻塞，直到有通道就绪
    Iterator<SelectionKey> it = selector.selectedKeys().iterator();
    while (it.hasNext()) {
        SelectionKey key = it.next();
        it.remove();                          // 必须手动移除，否则重复处理
        if (key.isAcceptable()) {
            SocketChannel sc = ssc.accept();
            sc.configureBlocking(false);
            sc.register(selector, SelectionKey.OP_READ);
        } else if (key.isReadable()) {
            SocketChannel sc = (SocketChannel) key.channel();
            buf.clear();
            int n = sc.read(buf);
            if (n == -1) { sc.close(); continue; }
            buf.flip();
            sc.write(buf);                    // Echo 回去
        }
    }
}

七、AIO：真正的异步 I/O

AIO（NIO.2，JDK 7 引入）才是真正的异步：发起读写后立即返回，内核完成数据拷贝后回调通知。

两种使用风格：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// 风格一：Future —— 主动轮询结果
AsynchronousSocketChannel ch = AsynchronousSocketChannel.open();
Future<Integer> f = ch.read(ByteBuffer.allocate(1024));
int n = f.get();   // 阻塞在这里取结果

// 风格二：CompletionHandler —— 回调，真正的异步
ch.read(buffer, null, new CompletionHandler<Integer, Void>() {
    @Override
    public void completed(Integer result, Void attachment) {
        buffer.flip();
        // 处理数据……
    }
    @Override
    public void failed(Throwable exc, Void attachment) {
        exc.printStackTrace();
    }
});

八、零拷贝：把上下文切换砍到最低

“零拷贝”（Zero-Copy）不是真的不拷贝，而是消除 CPU 参与的数据拷贝与不必要的上下文切换。以经典的”把文件从磁盘发给网卡”为例。

传统 read + write：4 次上下文切换 + 4 次拷贝

1
2

磁盘 →[DMA]→ 内核缓冲区 →[CPU]→ 用户缓冲区 →[CPU]→ Socket缓冲区 →[DMA]→ 网卡
      读(切换)                        读(切换)       写(切换)      写(切换)

mmap + write：3 次拷贝，用户与内核共享缓冲区。

sendfile / transferTo：2 次拷贝，数据不经过用户空间。

1
2

// FileChannel.transferTo 底层即 sendfile（Linux 上还可用 sendfile + DMA gather 进一步优化）
in.transferTo(position, count, out);

三种方式对比：

九、BIO / NIO / AIO 选型对比

实际生产建议：高并发网络编程直接上 Netty（NIO + Reactor 模型），不必纠结原生 NIO 的繁琐 API。

十、生产避坑清单

1. 文本读写用字符流，并显式指定 StandardCharsets.UTF_8，不要依赖平台默认编码。
2. try-with-resources 关闭资源，流/通道不关是句柄泄漏的头号来源。
3. Buffer 别忘了 flip()：”写完直接读”是新手第一个 bug，读到的永远是 0 字节。
4. selectedKeys() 处理完要 remove()，否则事件被重复消费。
5. 注册 Selector 前必须 configureBlocking(false)。
6. 堆外内存要节制：allocateDirect 不受 GC 管理，用 Cleaner/显式释放，警惕 OutOfMemoryError: Direct buffer memory。
7. 零拷贝注意单次 2GB 上限，大文件循环 transferTo；需加密/改写时不能用 sendfile。
8. 不要自己手写 NIO 服务端上生产，Reactor 模型、半包粘包、空轮询、写缓冲区水位等问题坑极深，用 Netty。

集合是 Java 面试和日常开发出场率最高的知识点，没有之一。本文不聊并发容器（ConcurrentHashMap、CopyOnWriteArrayList 的细节已在《Java 并发编程核心》一文中拆解过），而是聚焦单线程场景下的集合骨架：ArrayList 为什么扩容是 1.5 倍？HashMap 为什么容量必须是 2 的幂？链表为什么树化阈值是 8？LinkedHashMap 如何三行代码实现 LRU？把这些问题一次讲透。

一、集合框架全景图

Java 集合框架以两个顶层接口为根：Collection（单元素）和 Map（键值对）。

1
2
3
4
5
6
7
8
9

Iterable
 └── Collection
      ├── List（有序、可重复）：ArrayList / LinkedList / Vector
      ├── Set（不可重复）：HashSet / LinkedHashSet / TreeSet
      └── Queue（队列）：ArrayDeque / PriorityQueue / LinkedList
Map（独立体系）
 ├── HashMap → LinkedHashMap（有序）
 ├── TreeMap（排序）
 └── Hashtable（遗留，勿用）

二、ArrayList：动态数组的扩容艺术

2.1 底层结构与关键字段

1
2
3
4
5
6
7

public class ArrayList<E> extends AbstractList<E>
        implements List<E>, RandomAccess, Cloneable, java.io.Serializable {

    private static final int DEFAULT_CAPACITY = 10;  // 默认容量
    transient Object[] elementData;                  // 真正存数据的数组
    private int size;                                // 实际元素个数（≠ 数组长度）
}

注意 size 和 elementData.length 是两回事：size 是逻辑长度，数组长度是物理容量。无参构造时数组初始是空数组，第一次 add 才真正分配容量 10——这是懒加载设计。

2.2 扩容机制：为什么是 1.5 倍

1
2
3
4
5
6
7
8
9

private void grow(int minCapacity) {
    int oldCapacity = elementData.length;
    int newCapacity = oldCapacity + (oldCapacity >> 1);  // 1.5 倍
    if (newCapacity - minCapacity < 0)
        newCapacity = minCapacity;
    if (newCapacity - MAX_ARRAY_SIZE > 0)
        newCapacity = hugeCapacity(minCapacity);
    elementData = Arrays.copyOf(elementData, newCapacity);
}

扩容流程：add → 判断容量够不够 → 不够则 grow → 新容量 = 旧容量 × 1.5 → Arrays.copyOf 整体拷贝到新数组。

1.5 倍是空间与拷贝次数的折中：扩太慢（如 1.1 倍）拷贝频繁，扩太快（如 2 倍）浪费内存。oldCapacity >> 1 用位移代替乘法，也是源码的小巧思。

2.3 modCount 与 fail-fast

ArrayList 内部维护一个 modCount（继承自 AbstractList），任何结构化修改（add/remove）都会自增。迭代器创建时会保存 expectedModCount，每次 next() 前校验：

1
2
3
4

final void checkForComodification() {
    if (modCount != expectedModCount)
        throw new ConcurrentModificationException();
}

三、LinkedList：双向链表的真实定位

1
2
3
4
5

private static class Node<E> {
    E item;
    Node<E> next;
    Node<E> prev;
}

LinkedList 是双向链表，实现了 List 和 Deque 双接口。但一个经典误区是”随机插入用 LinkedList 更快”——实际上：

中间插入时 LinkedList 先要 node(i) 走链定位，同样是 O(n)，且 CPU 缓存对连续数组极不友好。绝大多数场景 ArrayList 都优于 LinkedList；需要双端队列时用 ArrayDeque 而不是 LinkedList。

四、HashMap：源码的重头戏

4.1 put 全流程

1
2
3
4
5
6
7
8
9

public V put(K key, V value) {
    return putVal(hash(key), key, value, false, true);
}

static final int hash(Object key) {
    int h;
    // 扰动：高 16 位异或低 16 位
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

put 一次的完整旅程：

1. 计算 hash(key)（扰动函数）；
2. 若数组为空，先 resize() 初始化；
3. (n - 1) & hash 定位桶下标——等价于 hash % n，但要求 n 是 2 的幂，位运算比取模快一个量级；
4. 桶为空 → 直接新建节点；
5. 桶非空 → 首节点 key 相同则覆盖；是 TreeNode 走红黑树插入；否则遍历链表尾插，长度达 8 且数组容量 ≥ 64 时树化；
6. ++size > threshold → resize() 扩容。

扰动函数的意义：直接用 hashCode 低位做下标，若 hashCode 只在高位有差异（如某些对象地址分布），桶会大量碰撞。h ^ (h >>> 16) 把高 16 位”混合”进低位，让散列更均匀——这是用一次异或换更低碰撞率的划算买卖。

4.2 为什么容量必须是 2 的幂

length - 1 的二进制形如 0000 1111，与 hash 相与后下标均匀落在 [0, n-1]。若长度不是 2 的幂，n-1 的二进制出现 0 位，某些下标永远取不到，散列性直接劣化。这也是为什么 tableSizeFor 会把任意初始容量向上取整到最近的 2 的幂：

1
2
3
4

static final int tableSizeFor(int cap) {
    int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1);
    return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}

指定 new HashMap<>(17)，实际容量会是 32。

4.3 树化：为什么阈值是 8 和 6

1
2
3

static final int TREEIFY_THRESHOLD = 8;     // 链表 → 红黑树
static final int UNTREEIFY_THRESHOLD = 6;   // 红黑树 → 链表
static final int MIN_TREEIFY_CAPACITY = 64; // 树化前提：数组容量达标

两个反直觉的点：

• 树化还需要数组容量 ≥ 64。容量小时碰撞多是因为”桶太少”而不是”散列差”，此时优先扩容而不是树化。
• 阈值 8 来源于泊松分布：在理想散列下，单桶链表长度达到 8 的概率约为千万分之六（0.00000006）。正常使用几乎触发不了树化，树化只是应对散列恶意攻击（哈希碰撞 DoS）的兜底。
• 退化阈值 6 而不是 7：留出缓冲带，防止节点数在 7、8 之间抖动导致链表/树反复转换。

4.4 扩容：JDK 8 的高低位拆分

扩容把数组翻倍，节点要么留在原下标 i，要么去 i + oldCap。判断依据只需看 hash 在 oldCap 对应位上是 0 还是 1：

1
2
3
4
5
6
7
8
9

if ((e.hash & oldCap) == 0) {
    // 低位链：留在原位置
    if (loTail == null) loHead = e; else loTail.next = e;
    loTail = e;
} else {
    // 高位链：移动到 原下标 + oldCap
    if (hiTail == null) hiHead = e; else hiTail.next = e;
    hiTail = e;
}

JDK 8 不需要重新计算每个元素的 hash，一次与运算完成分流，且链表保持原相对顺序——这是 JDK 8 相对 JDK 7 最大的性能改进之一。

4.5 JDK 7 vs JDK 8 关键差异

五、LinkedHashMap：三行代码的 LRU

LinkedHashMap 在 HashMap 的 Node 上加了 before/after 双指针，维护一条贯穿所有节点的双向链表：

1
2
3

static class Entry<K,V> extends HashMap.Node<K,V> {
    Entry<K,V> before, after;
}

• accessOrder = false（默认）：按插入顺序迭代；
• accessOrder = true：按访问顺序迭代，get 一次就把节点挪到链表尾。

配合 removeEldestEntry，一个 20 行的 LRU 缓存就出来了：

1
2
3
4
5
6
7
8
9
10
11
12
13

class LruCache<K, V> extends LinkedHashMap<K, V> {
    private final int maxEntries;

    LruCache(int maxEntries) {
        super(16, 0.75f, true);          // accessOrder = true 是灵魂
        this.maxEntries = maxEntries;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > maxEntries;      // 超容量淘汰最久未访问的队头
    }
}

六、HashSet 与 TreeMap 的底层真相

HashSet 就是包装了 HashMap：

1
2
3
4
5
6

public class HashSet<E> ... {
    private transient HashMap<E,Object> map;
    private static final Object PRESENT = new Object();  // 共享的 value 占位符

    public boolean add(E e) { return map.put(e, PRESENT) == null; }
}

所有元素作为 key 存入，value 用同一个哑对象填充。因此 LinkedHashSet = LinkedHashMap 的 key 视图，TreeSet = TreeMap 的 key 视图——一套代码三个容器。

TreeMap 底层是红黑树，按 key 排序，提供 firstKey/ceilingKey/floorKey/subMap 等范围 API。使用它要求 key 可排序：实现 Comparable 或构造时传入 Comparator，否则直接 ClassCastException。

七、集合选型速查表

八、高频避坑清单

参考阅读：并发容器（ConcurrentHashMap、CopyOnWriteArrayList、BlockingQueue）的原理与 JDK7/8 差异，见本站《Java 并发编程核心：volatile、synchronized、CAS 与 AQS 原理解析》；线程池的参数与执行流程见《Java 线程池详解》。

Vue 2 用 Object.defineProperty 做响应式，遇到”新增属性不更新””数组索引改了没反应”只能靠 $set 打补丁。Vue 3 把底层换成了 Proxy，从根上解决了这些坑。本文把响应式的”任督二脉”——依赖收集与派发更新——彻底拆开，再看 Composition API 怎么把逻辑组织得更干净。

一、为什么 Vue 2 的响应式不够用

Vue 2 在初始化时递归遍历 data，用 Object.defineProperty 给每个属性加 getter/setter。这带来三个绕不开的硬伤：

二、Vue 3 响应式核心：Proxy + Reflect

reactive() 的本质，是给目标对象包一层 Proxy，在 get 时收集依赖、在 set 时触发更新。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

function reactive(target) {
  return new Proxy(target, {
    get(obj, key, receiver) {
      // 依赖收集：谁在读这个属性，就记住谁
      track(obj, key)
      const result = Reflect.get(obj, key, receiver)
      // 嵌套对象懒代理，只有被访问才继续 reactive
      return typeof result === 'object' && result !== null
        ? reactive(result)
        : result
    },
    set(obj, key, value, receiver) {
      const oldVal = obj[key]
      const result = Reflect.set(obj, key, value, receiver)
      if (oldVal !== value) {
        // 派发更新：属性变了，通知所有依赖它的副作用重跑
        trigger(obj, key)
      }
      return result
    },
    deleteProperty(obj, key) {
      const had = key in obj
      const result = Reflect.deleteProperty(obj, key)
      if (had) trigger(obj, key) // 删除属性也能触发更新
      return result
    }
  })
}

Reflect 的作用有两个：一是保证 this 指向正确（配合 receiver 处理继承链上的 getter），二是返回 boolean 表示操作是否成功。

三、依赖收集：effect / track / trigger

Vue 3 用一个三级数据结构记录”谁依赖了谁”：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

let activeEffect = null // 当前正在执行的副作用

function effect(fn) {
  activeEffect = fn
  fn() // 执行时会触发 get → track 收集 activeEffect
  activeEffect = null
}

function track(target, key) {
  if (!activeEffect) return
  const depsMap = targetMap.get(target) ?? targetMap.set(target, new Map()).get(target)
  const dep = depsMap.get(key) ?? depsMap.set(key, new Set()).get(key)
  dep.add(activeEffect)
}

function trigger(target, key) {
  const dep = targetMap.get(target)?.get(key)
  dep?.forEach(eff => eff()) // 重新执行所有副作用
}

四、ref vs reactive：到底用哪个

reactive 只能代理对象，基本类型（number/string/boolean）没法直接 Proxy。于是 Vue 3 引入了 ref：用一个带 .value 的对象把基本类型包起来。

1
2
3
4
5
6
7
8

class RefImpl {
  constructor(value) {
    this.__v_isRef = true
    this._value = value
  }
  get value() { track(this, 'value'); return this._value }
  set value(newVal) { this._value = newVal; trigger(this, 'value') }
}

另外还有几个变体：

• shallowRef / shallowReactive：只做浅层响应式，深层变化不触发，适合大对象性能优化。
• readonly：深层只读代理，常用于把状态暴露给子组件或外部，防止被意外修改。

五、computed：带缓存的派生状态

computed 不是简单包一层 effect，它的核心是两个标志：lazy（默认不立即执行） 和 dirty（脏检查）。

1
2
3
4
5
6
7
8
9
10
11
12

function computed(getter) {
  let value, dirty = true
  const runner = effect(getter, { lazy: true })
  return {
    get value() {
      if (dirty) { value = runner(); dirty = false } // 依赖没变就返回缓存
      track(this, 'value')
      return value
    },
    set value(newVal) { /* 有 setter 时支持写回 */ }
  }
}

只有依赖的响应式数据变化、dirty 被 trigger 置回 true 时，下次读取才会重新计算。这避免了模板里重复调用带来的无谓开销。

六、watch 与 watchEffect 的差异

两者都基于 effect，但触发时机和写法不同：

七、Composition API 实战

Composition API 把”按逻辑关注点”组织代码变成可能，而不是 Options API 的”按选项类型分散”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import { ref, onMounted, computed } from 'vue'

export function useCounter(initial = 0) {
  const count = ref(initial)
  const double = computed(() => count.value * 2)
  const increment = () => count.value++
  onMounted(() => console.log('counter mounted:', count.value))
  return { count, double, increment }
}

// 组件中使用
export default {
  setup() {
    const { count, double, increment } = useCounter(10)
    return { count, double, increment } // 模板直接可用
  }
}

把状态、计算、方法、生命周期收敛进 useCounter 这样的组合函数（composable），多个组件之间可以零成本复用，逻辑内聚、可读性远胜 Options API 的 data/methods/computed/mounted 四分五裂。

八、编译期 + 运行时的双重性能优化

Vue 3 快，不只是因为 Proxy，更因为编译期帮你做了大量优化：

1
2
3
4

<!-- v-memo：列表项成本较高时，只有 id/selected 变才更新 -->
<div v-for="item in list" :key="item.id" v-memo="[item.id, item.selected]">
  {{ item.label }}
</div>

九、生产避坑清单

1. 大对象用 shallowRef：深层不常变、只在顶层替换时，避免深层递归代理带来的初始化开销。
2. 不要在 setup 顶层写同步重逻辑：耗时操作放进 onMounted 或 watch 回调。
3. reactive 不要整体重新赋值：需要替换请用 ref 包对象，或 Object.assign(state, newObj)。
4. 解构必用 toRefs：传给子组件的 props/state 解构后仍是响应式的。
5. computed 里不要有副作用：它可能被多次求值或缓存跳过，副作用应放在 watch。
6. watch 监听对象用深层 { deep: true }，但深层监听成本高，尽量监听具体路径 () => state.a.b。
7. v-for 务必带稳定 key，且避免用 index 当 key 造成错位复用。

很多系统一开始用”直接调接口”把服务串起来，随着流量和依赖变多，耦合、峰值、故障扩散会接踵而至。Kafka 不是单纯的”消息中间件”，它更像一套分布式的提交日志系统。本文从原理到实战，把 Kafka 最容易被问、最容易踩坑的部分一次讲透。

一、为什么需要 Kafka：消息队列解决了什么

在一个典型后端系统里，订单服务可能要同时通知库存、积分、风控、物流。如果全部用同步 RPC 调用，任何一个下游抖动都会拖垮下单链路。消息队列的价值可以用一张表概括：

二、核心概念速览

理解 Kafka 的第一步是把名词对齐，否则后面全是黑话：

新版本（≥ 2.8 起陆续，3.x 默认）用 KRaft 取代了 ZooKeeper 来管元数据与选主，运维复杂度显著下降，但”分区 / 副本 / 消费组”这套模型完全不变。

三、分区：并行度与有序性的平衡点

一个 Topic 可以有多个 Partition，消息按规则分散到不同分区。 这是 Kafka 水平扩展的根本：

• 并行度上限 = 分区数。同一个 Consumer Group 里，一个分区同一时刻只被一个消费者实例持有，所以分区数决定了该 Group 的最大消费并发。
• 分区内有序，跨分区不保证有序。如果业务要求”同一订单的状态变更必须按发生顺序消费”，就必须用 订单ID 作为分区 Key，让同订单的消息落到同一分区。

1
2
3
4

// 指定 key，保证相同 key 始终进入同一分区（分区内严格有序）
ProducerRecord<String, String> record =
        new ProducerRecord<>("order_events", orderId, eventJson);
producer.send(record);

分区数怎么定？经验公式：

四、副本与高可用：ISR 机制

每个 Partition 有一个 Leader（负责读写）和若干 Follower（异步/同步拉取）。关键点在于 ISR（In-Sync Replicas，同步副本集合）：

• Follower 只要能在 replica.lag.time.max.ms 内追上 Leader，就留在 ISR 中；
• 只有 ISR 里的副本才有资格被选举为新 Leader；
• 生产者设置 acks=all 时，消息要被 ISR 中全部副本 写入才算成功。

1
2
3
4

# server.properties 关键副本配置
default.replication.factor=3        # 每个分区 3 副本
min.insync.replicas=2               # ISR 至少 2 个才算写入成功
unclean.leader.election.enable=false # 禁止非 ISR 副本"抢位"当 Leader

⚠️ unclean.leader.election.enable=true 看似提高了可用性，但会让一个落后很多的副本成为 Leader，造成已提交消息丢失。生产环境务必设为 false。

五、高吞吐的秘密：不是”快”，是”不绕路”

Kafka 能扛住百万级 QPS，靠的是几个工程取舍：

1. 顺序写磁盘：消息只追加（append-only）到分区日志尾部，避开了随机写寻道；磁盘顺序写的吞吐甚至高于随机内存写。
2. 零拷贝（Zero-Copy）：消费者读取时，数据从磁盘页缓存经 sendfile 直接拷贝到网卡，少了内核态→用户态的来回拷贝。
3. 页缓存（Page Cache）：Kafka 不强依赖堆内缓存，而是把读写都交给 OS 页缓存，重启后缓存依然热。
4. 批量 + 压缩：Producer 攒一批（linger.ms / batch.size）再发，并支持 snappy / gzip / lz4 / zstd 压缩，网络与磁盘开销大幅下降。

1
2

传统路径: 磁盘 → 内核缓冲 → 用户缓冲 → 内核 socket 缓冲 → 网卡   (多次拷贝)
零拷贝:   磁盘 → 内核页缓存 ───────────────→ 网卡                (sendfile)

六、生产者：可靠性与发送语义

要”不丢消息”，生产者侧三件套是 acks + retries + enable.idempotence：

1
2
3
4
5

# producer 可靠性配置
acks=all
retries=2147483647
enable.idempotence=true        # 开启幂等：PID + 序列号，broker 去重
max.in.flight.requests.per.connection=5

• 幂等生产者：为每个 Producer 分配 PID，每条消息带序列号，Broker 端对 <PID, 分区, 序列号> 去重，避免网络重试导致的重复写入。
• 事务：设置 transactional.id 后，可让”消费→处理→生产”在多个分区间原子提交，实现端到端不重复。

1
2
3
4
5
6
7
8

producer.initTransactions();
producer.beginTransaction();
try {
    producer.send(new ProducerRecord<>("topic_out", key, processed));
    producer.commitTransaction();   // 要么都成功，要么都回滚
} catch (Exception e) {
    producer.abortTransaction();
}

七、消费者：位移提交与再均衡

Kafka 是 Pull 模型：消费者主动从分区拉取，自己控制节奏和位移（offset）。位移提交方式直接决定”会不会丢 / 会不会重复”：

1
2
3
4
5
6
7

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
    for (ConsumerRecord<String, String> r : records) {
        process(r);                       // 先处理业务
    }
    consumer.commitSync();                // 处理完再同步提交，避免丢失
}

八、顺序性与精确一次语义（EOS）

消息系统的投递语义通常分三档：

Kafka 的 EOS（Exactly-Once Semantics） 由三层拼起来：

1. 分区内有序 —— 同一 Key 落到同一分区，天然有序；
2. 幂等生产者 —— 去重，避免重试产生重复；
3. 事务 + 事务性消费转换 —— 消费者用 isolation.level=read_committed 只读取已提交事务，处理后再事务性地写回，形成”读已提交→处理→写”的原子闭环。

在流处理场景（Kafka Streams / Flink 接 Kafka），这套机制能保障”端到端精确一次”，是实时数仓、计费对账等对准确性敏感业务的基础。

九、Kafka 与 RabbitMQ / RocketMQ 怎么选

一句话：要吞吐和流处理选 Kafka，要灵活路由和极低延迟选 RabbitMQ，要强事务与阿里生态选 RocketMQ。

十、生产避坑清单

总结

Kafka 的威力来自一套自洽的设计：分区提供并行与有序，ISR 副本兼顾高可用与不丢，顺序写+零拷贝+页缓存成就高吞吐，幂等与事务补齐精确一次语义。它既不是”最快的队列”，也不是”最易用的 MQ”，而是为”数据被多系统反复、可靠、有序地消费”而生的基础设施。掌握本文的分区、副本、生产与消费语义、EOS 四条主线，足以应对绝大多数后端场景下的 Kafka 设计与排障。

下一篇可以沿着”Kafka 集群部署与监控（KRaft + Cruise Control + Kafka Eagle）”或”Flink 接 Kafka 实现端到端 Exactly-Once”继续深入——把消息系统的”存”和流计算的”算”打通，才算真正用好它。

线程池解决了”怎么管理线程”的问题，但线程池本身并不保证线程安全——它只是把任务交给线程执行。真正保证多线程正确协作的，是 volatile、synchronized、CAS 和 AQS 这套并发原语。本文从 JMM 内存模型讲起，把 Java 并发的”内功心法”彻底拆开。

一、JMM 内存模型：并发问题的根源

Java 多线程程序中出现的各种诡异 Bug——值没变、结果不对、指令乱序——归根结底都源于 JMM（Java Memory Model）。JMM 不是真实存在的硬件结构，而是一组规范，定义了线程如何通过主内存交互。

1.1 三大特性：可见性、原子性、有序性

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 经典的可见性问题示例
public class VisibilityDemo {
    private static boolean flag = false;  // 没有 volatile！

    public static void main(String[] args) throws Exception {
        new Thread(() -> {
            while (!flag) { }  // 可能永远看不到 flag 变为 true
            System.out.println("Thread B sees flag = true");
        }).start();

        Thread.sleep(100);
        flag = true;  // 主线程修改了，但子线程可能永远看不到
        System.out.println("Main set flag = true");
    }
}

上述代码在 -server 模式下极大概率会死循环——因为 JIT 编译器可能将 while(!flag) 优化为无限循环，不再从主内存重新读取 flag。

1.2 happens-before 规则

JMM 通过 happens-before 原则来界定操作之间的可见性顺序。如果 A happens-before B，那么 A 的结果对 B 可见：

1.3 指令重排序与内存屏障

编译器和 CPU 为了提升性能，会对指令进行重排序，分为三种：

1
2
3
4

int a = 1;   // ①
int b = 2;   // ②
int c = a + b; // ③
// ①和②可以互换顺序，但③必须在①②之后 —— 这就是重排序的边界

内存屏障（Memory Barrier） 是阻止重排序的”硬指令”，JVM 插入四种屏障：

二、volatile 关键字深度解析

2.1 volatile 能保证什么（不能保证什么）

1
2
3
4
5
6
7
8
9
10
11
12

// volatile 不保证原子性的经典反例
private static volatile int count = 0;

public static void main(String[] args) throws Exception {
    for (int i = 0; i < 10; i++) {
        new Thread(() -> {
            for (int j = 0; j < 10000; j++) count++;
        }).start();
    }
    Thread.sleep(1000);
    System.out.println("count = " + count);  // 几乎一定 < 100000
}

即使加了 volatile，count++ 仍然是 读-改-写 三步操作，多线程交叉执行就会丢数据。要保证原子性必须用 synchronized 或 Atomic 类。

2.2 volatile 实现原理

volatile 的底层依赖两套机制协同工作：

（1）内存语义层面 —— 内存屏障

1
2
3

volatile boolean v;
v = true;   // 写操作：插入 StoreStore + StoreLoad 屏障
boolean b = v; // 读操作：插入 LoadLoad + LoadStore 屏障

（2）硬件层面 —— MESI 缓存一致性协议

现代 CPU 使用 MESI 协议维护缓存行状态：

当 CPU 修改一个 volatile 变量时，会触发 Bus Locking 或 MESI Invalidate，使其他 CPU 中对应的缓存行失效，从而保证可见性。

2.3 volatile 典型使用场景

场景一：状态标志位

1
2
3
4
5
6
7
8
9
10

// 最经典的 volatile 用法 —— 停止标志
private volatile boolean running = true;

public void shutdown() { running = false; }

public void doWork() {
    while (running) {
        // 处理业务逻辑...
    }
}

场景二：DCL 双重检查锁定（单例模式）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class Singleton {
    private static volatile Singleton instance;  // 必须加 volatile！

    public static Singleton getInstance() {
        if (instance == null) {                    // 第一次检查（无锁）
            synchronized (Singleton.class) {
                if (instance == null) {            // 第二次检查（有锁）
                    instance = new Singleton();    // ⚠️ 这里不是原子操作！
                }
            }
        }
        return instance;
    }
}

场景三：volatile 数组/引用的局限性

1
2
3

private volatile int[] arr = new int[10];
arr[0] = 1;  // ❌ 这不是 volatile 写！只保证了 arr 引用的可见性
              //    arr[0] 的修改对其他线程不一定可见

volatile 只保证引用本身的可见性，不保证数组元素或对象内部字段的可见性。需要细粒度控制时请用 Atomic*Array 或加锁。

三、synchronized 锁机制与锁升级

3.1 synchronized 的三种用法

1
2
3
4
5
6
7
8

// 1. 修饰实例方法 —— 锁的是当前实例对象（this）
public synchronized void method() { ... }

// 2. 修饰静态方法 —— 锁的是当前类的 Class 对象
public static synchronized void staticMethod() { ... }

// 3. 修饰代码块 —— 锁的是指定对象
synchronized (lockObject) { ... }

3.2 对象头与 Mark Word

synchronized 的锁信息存储在对象头（Object Header）的 Mark Word 中。在 64 位 JVM 中，Mark Word 的结构如下：

3.3 锁升级过程

JDK 6 之后，synchronized 引入了偏向锁和轻量级锁，大多数情况下不需要直接进入重量级锁（操作系统层面的互斥锁）。升级路径如下：

1
2
3
4

无锁 ──(第一次获取)──▶ 偏向锁 ──(竞争出现)──▶ 轻量级锁 ──(自旋失败)──▶ 重量级锁
  │                      │                     │                       │
  │  CAS 设置 ThreadID   │  CAS 替换 Mark Word  │  自旋+CAS             │  OS mutex
  │  无竞争时零开销      │  少量竞争           │  短时间竞争           │  上下文切换

偏向锁（Biased Locking）

当一个线程反复进入同一个同步块时，JVM 认为这个锁”偏向”该线程：

• 通过 CAS 将 Mark Word 中的 ThreadID 设为当前线程 ID
• 后续该线程进入/退出同步块无需任何 CAS 操作
• 只有当其他线程尝试获取这把锁时，才撤销偏向锁

生产建议：如果锁竞争确实激烈（如 Web 服务器的请求处理），偏向锁反而增加撤销开销。JDK 15 默认关闭偏向锁（-XX:-UseBiasedLocking），JDK 18 正式移除。

轻量级锁（Lightweight Locking）

偏向锁撤销后，或两个线程交替获取锁时，升级为轻量级锁：

• 在当前线程的栈帧中创建 Lock Record（锁记录）
• 将对象的 Mark Word CAS 替换为指向 Lock Record 的指针
• 解锁时再将 Lock Record 中的旧 Mark Word CAS 回去
• 如果 CAS 失败（说明有竞争），自旋重试若干次

重量级锁（Heavyweight Locking）

自旋超过阈值（默认 10 次，可通过 -XX:PreBlockSpin 调整）后，升级为重量级锁：

• 向操作系统申请互斥量（mutex）
• 未获取到锁的线程阻塞（BLOCKED 状态），涉及用户态/内核态切换
• 被唤醒的线程需要重新竞争锁（非公平）

3.4 锁消除与锁粗化（JIT 编译器优化）

JIT 编译器在运行时还会对 synchronized 做两种智能优化：

1
2
3
4
5
6
7
8
9
10

// 锁消除：锁的对象是局部变量，不可能被外部线程访问
public void lockElimination() {
    StringBuffer sb = new StringBuffer();  // StringBuffer 方法都是 synchronized 的
    sb.append("a").append("b");            // JIT 发现 sb 是局部的 → 直接去掉所有锁
}

// 锁粗化：循环体内频繁加锁解锁 → 合并为一次
for (int i = 0; i < 1000; i++) {
    synchronized (lock) { ... }  // JIT 可能合并为 synchronized(lock) { for(...) {...} }
}

3.5 synchronized vs volatile 对比

四、CAS 与原子操作

4.1 什么是 CAS（Compare And Swap）

CAS 是一条 CPU 原子指令，其语义等价于以下伪代码：

1
2
3
4
5
6
7
8
9

// CAS(V, Expected, NewValue)
// 如果内存值 V == 期望值 Expected，则将 V 更新为 NewValue，否则什么都不做
boolean CAS(V, Expected, NewValue) {
    if (V == Expected) {
        V = NewValue;
        return true;   // 成功
    }
    return false;      // 失败，V 已被其他线程修改
}

CAS 是乐观锁的核心思想：不先加锁，而是假设没有冲突，更新时再检验。冲突了就重试。

4.2 CAS 底层实现

Java 中 CAS 通过 sun.misc.Unsafe 类调用本地方法，最终映射为 x86 的 cmpxchg 指令：

1
2
3
4
5

// AtomicInteger.getAndIncrement() 的核心调用：
// unsafe.compareAndSwapInt(this, valueOffset, expect, update)
//
// 最终汇编：
// lock cmpxchg [addr], reg   ← lock 前缀保证多核原子性

4.3 ABA 问题及解决方案

CAS 检查的是”值有没有变”，但如果值从 A → B → A 变回来，CAS 会误以为没变过：

1
2
3
4

线程1 读取值 A（准备 CAS 为 C）
线程2 把 A 改成 B
线程3 又把 B 改回 A
线程1 执行 CAS(A, C) → 成功！但实际上中间已经变了两次

解决方案：加版本号

1
2
3
4
5
6
7
8
9
10
11
12

// AtomicStampedReference —— 带版本号的引用
AtomicStampedReference<String> asr = new AtomicStampedReference<>("A", 0);

// CAS 时同时比较值和版本号
int[] stampHolder = new int[1];
String ref = asr.get(stampHolder);       // ref="A", stamp=0
boolean ok = asr.compareAndSet(ref, "C", stampHolder[0], stampHolder[0] + 1);
//                              期望引用  新引用  期望版本  新版本

// AtomicMarkableReference —— 带布尔标记的引用（简化版，只关心"变没变过"）
AtomicMarkableReference<String> amr = new AtomicMarkableReference<>("A", false);
amr.compareAndSet("A", "B", false, true);  // 同时比较引用和标记

4.4 CAS 自旋与性能问题

CAS 失败后会自旋重试，在高竞争下可能导致：

1
2
3
4

// LongAdder —— 高并发下的计数器替代方案（JDK 8+）
LongAdder counter = new LongAdder();
counter.increment();  // 内部分散到多个 Cell，减少 CAS 竞争
long sum = counter.sum();  // 汇总所有 Cell

五、Atomic 原子类体系

JUC 提供了一套基于 CAS 实现的原子类，位于 java.util.concurrent.atomic 包下。

5.1 体系总览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

java.util.concurrent.atomic
├── 基本类型
│   ├── AtomicInteger
│   ├── AtomicLong
│   └── AtomicBoolean
├── 数组类型
│   ├── AtomicIntegerArray
│   ├── AtomicLongArray
│   └── AtomicReferenceArray<E>
├── 引用类型
│   ├── AtomicReference<V>
│   ├── AtomicStampedReference<V>
│   └── AtomicMarkableReference<V>
├── 字段更新器
│   ├── AtomicIntegerFieldUpdater<T>
│   ├── AtomicLongFieldUpdater<T>
│   └── AtomicReferenceFieldUpdater<T,V>
└── 累加器（JDK 8+）
    ├── LongAdder
    ├── DoubleAdder
    ├── LongAccumulator
    └── DoubleAccumulator

5.2 AtomicInteger 核心源码解析

以最常用的 getAndIncrement() （即 i++ 的原子版）为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public final int getAndIncrement() {
    return getAndAdd(1);
}

public final int getAndAdd(int delta) {
    // U = sun.misc.Unsafe 实例
    // valueOffset = 字段 value 在对象内存中的偏移量
    return U.getAndAddInt(this, VALUE, delta);
}

// Unsafe.getAndAddInt —— CAS 自旋循环
public final int getAndAddInt(Object o, long offset, int delta) {
    int prev;
    int next;
    do {
        prev = getIntVolatile(o, offset);  // 读取当前值（volatile 读）
        next = prev + delta;               // 计算新值
    } while (!compareAndSwapInt(o, offset, prev, next));  // CAS 更新，失败则重试
    return prev;  // 返回旧值
}

这个 do-while 循环就是自旋锁的本质——不断尝试直到成功。在低竞争时几乎无开销；高竞争时会浪费 CPU 周期。

5.3 字段更新器：给现有类”打补丁”

1
2
3
4
5
6
7
8
9
10
11
12

// 场景：想对一个第三方类的某个 volatile 字段做原子操作，
// 但不能修改它的源码
class Student {
    volatile int score;
}

AtomicIntegerFieldUpdater<Student> updater =
    AtomicIntegerFieldUpdater.newUpdater(Student.class, "score");

Student s = new Student();
updater.set(s, 80);          // 相当于 s.score = 80（原子写）
int old = updater.getAndIncrement(s);  // 原子的 s.score++

六、AQS（AbstractQueuedSynchronizer）框架

6.1 AQS 设计思想

AQS 是 JUC 并发包的基石——ReentrantLock、CountDownLatch、Semaphore、ReentrantReadWriteLock 全部基于 AQS 构建。

Doug Lea（JUC 作者）的设计哲学：将同步状态的管理与线程的排队机制分离。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

AQS 核心架构：
┌─────────────────────────────────────┐
│         AbstractQueuedSynchronizer   │
│                                      │
│  ┌──────────┐    ┌───────────────┐  │
│  │  state   │    │  CLH 队列      │  │
│  │ (int,    │    │  (FIFO 双向链表)│  │
│  │  volatile)│    │  Node:thread  │  │
│  └──────────┘    │  + waitStatus │  │
│                   └───────────────┘  │
│                                      │
│  tryAcquire() / tryRelease()  ← 子类实现  │
│  tryAcquireShared() / tryReleaseShared() │
└─────────────────────────────────────┘

6.2 核心数据结构

state —— 同步状态

1
2
3
4
5
6
7
8
9

// AQS 内部就是一个 volatile int
private volatile int state;

// 提供三个方法操作（都是 CAS 原子操作）
protected final int getState() { return state; }
protected final void setState(int newState) { state = newNode; }
protected final boolean compareAndSetState(int expect, int update) {
    // 底层调用 Unsafe.compareAndSwapInt
}

不同同步器对 state 的含义不同：

CLH 队列 —— 等待线程队列

AQS 内部维护一个 FIFO 双向链表（CLH 变体），每个节点是一个 Node：

1
2
3
4
5
6
7
8
9
10
11
12

static final class Node {
    volatile Node prev;       // 前驱节点
    volatile Node next;       // 后继节点
    volatile Thread thread;   // 等待的线程
    int waitStatus;           // 等待状态
    // waitStatus 取值：
    //   0: 初始状态
    //   SIGNAL(-1): 后继节点需要被唤醒
    //   CANCELLED(1): 节点已取消
    //   CONDITION(-2): 节点在 Condition 队列中
    //   PROPAGATE(-3): 共享模式下传播释放信号
}

6.3 独占模式 vs 共享模式

AQS 支持两种资源获取模式：

6.4 AQS 获取锁的完整流程（独占模式）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

acquire(arg)
  │
  ├─ tryAcquire(arg) ──成功──▶ 直接返回（无需入队）
  │                  ──失败──▶ addWaiter(Node.EXCLUSIVE)  // 尾插法加入队列
  │                               │
  │                               ▼
  │                        acquireQueued(node, arg)
  │                          │
  │                          ├─ 前驱是 head → 再 tryAcquire 一次（抢锁机会）
  │                          │     └─ 成功 → 设置自己为 head，返回
  │                          │     └─ 失败 → shouldParkAfterFailedAcquire()
  │                          │              └─ 检查前驱 waitStatus
  │                          │                 └─ SIGNAL → park（挂起，等待 unpark）
  │                          │                 ── CANCELLED → 跳过前驱，重试
  │                          │
  │                          └─ 被唤醒后 → 再次循环 tryAcquire
  │
  └─ 如果中断 → selfInterrupt() 补上中断标记

6.5 ReentrantLock 如何基于 AQS 实现

ReentrantLock 内部有两个 AQS 子类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

// NonfairSync —— 非公平锁
static final class NonfairSync extends Sync {
    final void lock() {
        if (compareAndSetState(0, 1))  // 先直接 CAS 抢锁！
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);  // 抢不到再走 AQS 流程
    }

    protected final boolean tryAcquire(int acquires) {
        // 非公平：不管队列里有没有等待的线程，直接抢
        ...
    }
}

// FairSync —— 公平锁
static final class FairSync extends Sync {
    protected final boolean tryAcquire(int acquires) {
        // 公平：检查是否有前驱节点，有则放弃抢锁
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            if (!hasQueuedPredecessors() &&   // ★ 关键：看队列里有没有人
                compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        ...
    }
}

可重入实现

ReentrantLock 的”可重入”体现在 tryAcquire 中判断当前线程是否已经是锁的持有者：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 简化的可重入逻辑
final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        if (compareAndSetState(0, acquires)) { ... return true; }
    }
    else if (current == getExclusiveOwnerThread()) {  // 已经是持有者 → 重入
        int nextc = c + acquires;
        if (nextc < 0) throw new Error("Maximum lock count exceeded");
        setState(nextc);  // 直接设置 state，无需 CAS（因为只有持有者才能到这里）
        return true;
    }
    return false;
}

6.6 AQS Condition（条件变量）

Condition 是 AQS 提供的条件等待/通知机制，替代了 Object.wait()/notify()：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

ReentrantLock lock = new ReentrantLock();
Condition notFull = lock.newCondition();   // 队列不满条件
Condition notEmpty = lock.newCondition();  // 队列不空条件

// 生产者
lock.lock();
try {
    while (count == bufferSize) notFull.await();  // 队列满 → 等待
    enqueue(item);
    notEmpty.signal();                            // 通知消费者
} finally { lock.unlock(); }

// 消费者
lock.lock();
try {
    while (count == 0) notEmpty.await();  // 队列空 → 等待
    item = dequeue();
    notFull.signal();                        // 通知生产者
} finally { lock.unlock(); }

Condition 的优势：一个 Lock 可以创建多个 Condition，实现精准唤醒（只唤醒某一类等待线程），而 Object.notify() 是随机唤醒一个。

七、JUC 并发工具类

7.1 CountDownLatch —— 倒计时门闩

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 场景：主线程等待 N 个子线程全部完成后汇总
CountDownLatch latch = new CountDownLatch(3);  // 初始计数 = 3

for (int i = 0; i < 3; i++) {
    new Thread(() -> {
        try {
            // 执行任务...
        } finally {
            latch.countDown();  // 计数 -1
        }
    }).start();
}

latch.await();  // 阻塞等待，直到计数归零
System.out.println("所有任务完成！");

原理：内部基于 AQS 共享模式，countDown() 就是 releaseShared(1)（state - 1），await() 就是 acquireSharedInterruptibly(1)（state != 0 则阻塞）。

7.2 Semaphore —— 信号量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 场景：限流 —— 控制同时访问某资源的线程数不超过 N
Semaphore semaphore = new Semaphore(5);  // 5 个许可

for (int i = 0; i < 20; i++) {
    new Thread(() -> {
        try {
            semaphore.acquire();   // 获取许可（阻塞式）
            // 访问受限资源...
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            semaphore.release();  // 归还许可
        }
    }).start();
}

原理：同样基于 AQS 共享模式，state 表示剩余许可数。acquire() 就是 tryAcquireShared（state > 0 则 CAS 减 1），release() 就是 releaseShared（state + 1 并唤醒等待线程）。

7.3 CyclicBarrier —— 循环栅栏

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// 场景：N 个线程互相等待，全部到达后一起继续（可重复使用）
CyclicBarrier barrier = new CyclicBarrier(3, () -> {
    System.out.println("所有选手到达终点，开始颁奖！");
});

for (int i = 0; i < 3; i++) {
    final int no = i + 1;
    new Thread(() -> {
        System.out.println("选手 " + no + " 出发...");
        try {
            Thread.sleep((long)(Math.random() * 3000));
            System.out.println("选手 " + no + " 到达终点");
            barrier.await();  // 等待其他线程
            System.out.println("选手 " + no + " 继续下一轮比赛");
        } catch (Exception e) { e.printStackTrace(); }
    }).start();
}

与 CountDownLatch 的关键区别：CyclicBarrier 可以复用（reset() 后重新计数），且支持 barrierAction（所有线程到达后执行的回调）。底层用的是 ReentrantLock + Condition，不是 AQS。

7.4 三大工具类对比

八、并发容器

8.1 ConcurrentHashMap（JDK 7 vs JDK 8）

这是面试最高频的并发容器，JDK 7 和 JDK 8 的实现完全不同：

JDK 8 ConcurrentHashMap 核心源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// put 操作简化流程
final V putVal(K key, V value, boolean onlyIfAbsent) {
    // ... hash 计算 ...

    for (Node<K,V>[] tab = table;;) {
        Node<K,V> f; int n, i, fh;
        if (tab == null || (n = tab.length) == 0)
            tab = initTable();                    // ① 表空 → 初始化
        else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
            if (casTabAt(tab, i, null, new Node(...)))  // ② 桶空 → CAS 插入
                break;                                   //    无锁成功
        }
        else if ((fh = f.hash) == MOVED)
            tab = helpTransfer(tab, f);              // ③ 正在扩容 → 协助迁移
        else {
            synchronized (f) {                       // ④ 桶非空 → 加锁（锁住头节点）
                // 链表遍历 or 红黑树操作...
            }
        }
    }
    // ... addCount() → 可能触发扩容 ...
}

JDK 8 的设计非常精妙：大部分情况用无锁 CAS，只在哈希冲突时才降级为 synchronized 锁住单个桶。而且 synchronized 锁的是桶的头节点（Node 对象），不是整个 Segment，粒度比 JDK 7 更细。

8.2 CopyOnWriteArrayList

1
2
3
4
5
6
7
8

// 写时复制列表 —— 读完全无锁，写时复制整个底层数组
CopyOnWriteArrayList<String> list = new CopyOnWriteArrayList<>();

// 读操作：直接读数组，无锁（适合读多写少）
String s = list.get(0);

// 写操作：复制新数组，修改后替换引用
list.add("hello");  // 内部：Arrays.copyOf() → 新数组添加 → 替换

8.3 BlockingQueue 家族

1
2
3
4
5
6
7
8

// 生产者-消费者经典模式
BlockingQueue<Task> queue = new ArrayBlockingQueue<>(128);

// 生产者
queue.put(task);     // 队列满时阻塞

// 消费者
Task task = queue.take();  // 队列空时阻塞

8.4 并发容器选择指南

1
2
3
4
5
6
7
8
9
10
11
12
13
14

需要 Map？
  ├── 读多写少 → ConcurrentHashMap（首选）
  ├── 要求强一致 → Collections.synchronizedMap()（性能差但简单）
  └── 需要排序 → ConcurrentSkipListMap（跳表，有序）

需要 List？
  ├── 读多写少 → CopyOnWriteArrayList
  └── 读写均衡 → Collections.synchronizedList() 或手动加锁

需要 Queue？
  ├── 有界队列 → ArrayBlockingQueue
  ├── 无界队列 → LinkedBlockingQueue
  ├── 直接传递 → SynchronousQueue
  └── 延迟任务 → DelayQueue

九、实战避坑清单

总结

本文从 JMM 内存模型出发，梳理了 Java 并发编程的完整知识链路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

JMM（可见性/原子性/有序性）
  ↓
volatile（内存屏障 + MESI）←→ synchronized（锁升级：偏向→轻量→重量）
  ↓
CAS（CPU 原子指令）+ ABA 问题
  ↓
Atomic 原子类（基于 CAS + 自旋）
  ↓
AQS 框架（state + CLH 队列 + 独占/共享模式）
  ↓
  ├── ReentrantLock（可重入 + 公平/非公平 + Condition）
  ├── CountDownLatch（一次性倒计时）
  ├── Semaphore（信号量限流）
  └── CyclicBarrier（循环栅栏）
  ↓
并发容器（ConcurrentHashMap / CopyOnWriteArrayList / BlockingQueue）

掌握这套体系，你就拥有了分析和解决绝大多数 Java 并发问题的能力。下一步建议结合 JConsole / VisualVM / Arthas 观察线程状态，在实践中加深理解。

索引、事务、复制、分库、备份解决的是“能不能跑、跑得快不快、丢不丢数据”的问题；而安全解决的是“谁能进来、进来能干什么、干了什么能不能被追溯”的问题。MySQL 的安全事故，80% 不是被黑客攻破，而是账号权限过大、密码太弱、连接不加密、操作没审计导致的。本文聚焦权限、加密与审计这三根支柱。

一、安全设计的三个原则

在动手改权限之前，先统一认识：

1. 最小权限原则：一个账号只拥有完成工作所需的最小权限集合，能只读就不给写，能只访问一个库就不给所有库。
2. 纵深防御原则：安全不能只靠某一层，权限 + 密码 + 网络 + 应用层 + 审计要同时生效。
3. 可追溯原则：关键操作必须留痕，知道谁在什么时间做了什么，出了问题能回溯。

这三条会贯穿后面的所有配置。

二、MySQL 账号与权限模型

2.1 user@host 的含义

MySQL 的账号不是单纯的用户名，而是 用户名 + 允许登录的主机 的组合。

1
2
3
4

-- 三个完全不同的账号
'app_user'@'10.0.0.%'
'app_user'@'app-server-01'
'app_user'@'%'

2.2 账号创建与基础授权

1
2
3
4
5
6
7
8

-- 创建只允许从 10.0.0.% 登录的只读账号
CREATE USER 'app_read'@'10.0.0.%'
  IDENTIFIED BY 'ComplexP@ssw0rd!2026';

-- 授予对 order 库的 SELECT 权限
GRANT SELECT ON order.* TO 'app_read'@'10.0.0.%';

FLUSH PRIVILEGES;

常用授权粒度：

2.3 权限回收

1
2
3
4
5

-- 回收某个权限
REVOKE DELETE ON order.* FROM 'app_read'@'10.0.0.%';

-- 删除账号（连同权限）
DROP USER 'app_read'@'10.0.0.%';

三、生产常用账号模板

一个典型的生产环境，至少应该把账号拆开。

3.1 应用只读账号

1
2
3

CREATE USER 'order_app_ro'@'10.0.10.%'
  IDENTIFIED BY 'ro-密码';
GRANT SELECT ON order.* TO 'order_app_ro'@'10.0.10.%';

只读账号不能写，也不能访问其他业务库，即使应用被 SQL 注入，也能把损失控制在只读范围内。

3.2 应用读写账号

1
2
3
4

CREATE USER 'order_app_rw'@'10.0.10.%'
  IDENTIFIED BY 'rw-密码';
GRANT SELECT, INSERT, UPDATE, DELETE ON order.*
  TO 'order_app_rw'@'10.0.10.%';

不授予 DROP、ALTER、CREATE 等 DDL 权限，应用不应该在线上做结构变更。

3.3 备份专用账号

1
2
3
4

CREATE USER 'backup_user'@'10.0.20.%'
  IDENTIFIED BY 'backup-密码';
GRANT SELECT, RELOAD, LOCK TABLES, REPLICATION CLIENT, SHOW VIEW
  ON *.* TO 'backup_user'@'10.0.20.%';

权限说明：

3.4 监控与审计账号

1
2
3
4
5

CREATE USER 'monitor'@'10.0.30.%'
  IDENTIFIED BY 'monitor-密码';
GRANT SELECT ON performance_schema.* TO 'monitor'@'10.0.30.%';
GRANT SELECT ON sys.* TO 'monitor'@'10.0.30.%';
GRANT REPLICATION CLIENT ON *.* TO 'monitor'@'10.0.30.%';

监控账号不需要写权限，也不需要访问业务数据表。

3.5 DBA 管理账号

1
2
3
4

CREATE USER 'dba_admin'@'10.0.0.10'
  IDENTIFIED BY 'dba-强密码';
GRANT ALL PRIVILEGES ON *.* TO 'dba_admin'@'10.0.0.10'
  WITH GRANT OPTION;

四、MySQL 8.0 角色（Role）

角色让权限管理从“每人一份权限清单”变成“按岗位分组授权”。

4.1 创建并激活角色

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

-- 创建角色
CREATE ROLE 'app_read_role', 'app_write_role', 'backup_role';

-- 给角色授权
GRANT SELECT ON order.* TO 'app_read_role';
GRANT SELECT, INSERT, UPDATE, DELETE ON order.* TO 'app_write_role';
GRANT SELECT, RELOAD, LOCK TABLES ON *.* TO 'backup_role';

-- 把角色授予用户
GRANT 'app_read_role' TO 'order_app_ro'@'10.0.10.%';
GRANT 'app_write_role' TO 'order_app_rw'@'10.0.10.%';

-- 设置用户默认激活角色（登录时自动生效）
SET DEFAULT ROLE 'app_read_role' TO 'order_app_ro'@'10.0.10.%';
SET DEFAULT ROLE 'app_write_role' TO 'order_app_rw'@'10.0.10.%';

4.2 激活角色与查看

1
2
3
4
5
6
7
8
9

-- 当前会话激活所有已授权角色
SET ROLE ALL;

-- 查看当前用户的角色和权限
SHOW GRANTS;
SHOW GRANTS FOR CURRENT_USER USING 'app_read_role';

-- 查看角色成员
SELECT * FROM mysql.role_edges;

五、密码策略

弱密码是数据库被入侵最常见的原因之一。MySQL 提供 validate_password 插件强制密码复杂度。

5.1 查看与启用

1
2
3
4
5
6
7
8
9
10
11
12

-- MySQL 8.0 默认已安装
SHOW VARIABLES LIKE 'validate_password%';

-- 关键参数
| Variable_name                          | Value  |
|----------------------------------------|--------|
| validate_password.check_user_name      | ON     |
| validate_password.length                 | 8      |
| validate_password.mixed_case_count       | 1      |
| validate_password.number_count           | 1      |
| validate_password.special_char_count     | 1      |
| validate_password.policy                 | MEDIUM |

5.2 调整策略

1
2
3
4
5

SET GLOBAL validate_password.policy = STRONG;
SET GLOBAL validate_password.length = 16;
SET GLOBAL validate_password.mixed_case_count = 1;
SET GLOBAL validate_password.number_count = 1;
SET GLOBAL validate_password.special_char_count = 1;

要永久生效，写入 my.cnf：

1
2
3
4
5
6
7

[mysqld]
plugin-load-add = validate_password.so
validate_password.policy = STRONG
validate_password.length = 16
validate_password.mixed_case_count = 1
validate_password.number_count = 1
validate_password.special_char_count = 1

5.3 密码过期与历史

1
2
3
4
5
6
7

-- 创建账号时设置 90 天必须改密码
CREATE USER 'app_user'@'10.0.10.%'
  IDENTIFIED BY 'TmpPass!2026'
  PASSWORD EXPIRE INTERVAL 90 DAY;

-- 保留最近 6 次密码，禁止复用
ALTER USER 'app_user'@'10.0.10.%' PASSWORD HISTORY 6;