1. 文本文件
2. 二进制文件

文本文件是指，文件中的数据按照某种字符编码（UTF-8、GBK）存储，本质上是一系列字符。当然，字面意思就是，文件里保存的是人可以直接阅读的文字。

二进制文件是指，文件中的数据以二进制形式直接保存，不按照字符编码解析。

Java 标准库中提供了一系列的类操作文件

• 文件系统操作（创建文件、删除文件、重命名、创建目录）
• 文件内容操作（针对一个文件的内容进行读和写）

Java 中通过java.io.File类对一个文件（包括目录）进行抽象的描述。注意，有 File 对象，并不代表真实存在该文件。

1.File 概述

属性

构造方法

String 类型的参数是文件的路径，使用绝对/相对路径均可~

方法

2. 文件内容的读写--数据流

Java 中提供了几十个这样的流，在此我只讲解其中 8 个就足够了~

针对上述几十个流，分成两个大类别：

1. 字节流 读写文件，以字节为单位。是针对二进制文件使用的
   1. InputStream 输入
   2. OutputStream 输出
2. 字符流 读写文件，以字符为单位。是针对文本文件使用的
   1. Reader 输入
   2. Writer 输出

关于判断输入输出的方法：

屁股坐在 CPU 上，迎面而来是输入，离你而去是输出。

InputStream 概述

方法

注意：

InputStream 只是一个抽象类，要使用还需要具体的实现类。关于 InputStream 的实现类有很多，基本可以认为不同的输入设备都可以对应一个 InputStream 类，现在只关心从文件中读取，所以使用 FileInputStream（InputStream 的子类）

FileInputStream 概述

构造方法

InputStream inputStream = new FileInputStream("路径")当此处创建对象操作一旦成功，就相当于“打开文件”，同样还有关闭文件的方法，inputStream.close()

虽然在 Java 中只需要申请内存资源即可，释放交给 GC 自动完成。但是，文件资源不等同于内存资源，虽然 GC 能够自动管理内存，但是不能自动管理文件，需要我们手动释放。若不手动释放，就会引起“文件资源泄露”，也就是俗话说的“占着茅坑不拉屎”

因为 进程 -> PCB -> 文件描述符表

每次程序打开一个文件，就会在文件描述符表（固定长度的顺序表）中申请一个表项（占个坑），然后如果光打开不关闭，就会使这里的文件描述符表的表项耗尽。后续再次打开就会失败~

至于为什么文件描述符表不能自动扩容，因为如果这么做的话，会更推进一步去加大内存操作中的不可控的因素~

注意：

另外，再补充一处，关于 InputStream 创建对象的时候一般使用 try-with-resource（Java1.5 引入的语法，我在 JDBC 也已经讲过） 去包裹。以保证最终走出 try 代码块的时候能够自动关闭并释放。（可以不只实现一个对象~）

强调：能使用此方法创建的类必须实现 Closable 接口

使用例子如下：

public static void main(String[] args) throws IOException {
    try (InputStream inputStream 
         = new FileInputStream("./test.txt")) {
        while (true) {
            int data = inputStream.read();
            if(data == -1) {
                // 文件读完
                break;
            }
            System.out.printf("0x%x\n",data);
        }
    }
}

IntputStream 中的三个 read 方法

对于无参数的 read 方法，如果没读完就会返回读到的字节值，读完了就返回-1

注意：剩下两个有参数的 read 返回的是读取到的字节数。仔细想想会比较特殊，它使用的是 参数作为方法的返回值~ 在 Java 中比较少见，这种称之为“输出型参数”。一般来说，把方法想象成工厂，返回值就是产品；

public static void main(String[] args) throws IOException {
    try (InputStream inputStream 
         = new FileInputStream("./test.txt")) {
        while (true) {
            byte[] data = new byte[1024];
            int n = inputStream.read(data);
            if (n == -1) {
                // 文件读完
                break;
            }
            for (int i = 0; i < n; i++) {
                System.out.printf("0x%x\n",data[i]);
            }
        }
    }
}

Java 中，如果参数是引用类型，方法内部修改对象的时候，能影响到方法外部~ 即：

当方法参数是引用类型时，方法拿到的是“对象引用的副本”。虽然引用本身是复制的，但这个副本和方法外面的引用仍然指向同一个对象，所以通过它修改对象内部的数据，外面能看到变化。

对于第三个 read 方法：read(byte[] b, int off, int len)

其中 off 是指 offset 偏移量（数组下标），放置 len 数量个~

OutpuStream 概述

方法

说明一下：OutputStream 同样只是一个抽象类，要使用还需要具体的实现类。我们现在还是只关心写入文件中，所以使用 FileOutputStream

此处的 writer 方法与前面的 read 方法类似，分为单个字节写入，多个字节写入以及多个字节拼接写入~

另外，对于OutputStream 来说，默认情况下会默认创建该文件。并且是以覆盖形式去写入。如果想要避免此情况，就需要使用追加写，即使用该构造方法FileOutputStream(File file, boolean append)

FileOutputStream 概述

构造方法：

public static void main(String[] args) {
        try (OutputStream outputStream = new FileOutputStream("./output.txt")){
            byte[] bytes = {97,98,99};
            outputStream.write(bytes);

        } catch (IOException e) {
            // 此处是需要处理两个异常. 由于此处并没有针对这两个异常提供不同的处理, 就直接合并了.
            throw new RuntimeException(e);
        }
    }

Reader 概述

构造方法：

因为他们是protected，而且Reader是抽象类,所以通常不直接使用这两个构造方法。

方法：

以上的 read 方法与前面的还是类似。

无参数版本的 read 一次读一个字符。返回的相当于是一个 char，两个字节。

char[] 数组版本是读字符数组，尽可能把字符数组给填满，返回实际读到的字符个数。

第三个版本的 read 中的 CharBuffer，其实就相当于 char[] 进行了封装。

public static void main(String[] args) {
        try (Reader reader = new FileReader("./test.txt")) {
            while (true) {
                int c = reader.read();
                if(c == -1) {
                    break;
                }
                System.out.println((char) c);
            }
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

假设./test.txt 文件中，是“你好”两个字

但如果我不是强转为 char 类型，那么得到的结果就是20320 和 22909。那么之前还说过 utf8 中汉字占 3 个字节，为什么这里得到的是两组数字？

字节流读到的是文件中的原始数据，在硬盘上保存文件的时候，就是 6 个字节，utf8 编码。

字符流在读取的时候，就会根据文件的内容编码格式进行解析。read()一次，就会读到 3 个字节（按照 utf8 解析）。返回的时候，针对 3 个字节进行转码了，拿着 3 个字节查了一下 utf8 的码表“你”。read 就又把你这个汉字在 unicode 这个码表中再次查询一次，得到 unicode 的编码值。最终把 unicode 的编码值返回到 char 变量中（两个字节了）

以上就是自动进行转码了~

Writer 概述

构造方法

因为Writer是抽象类，所以一般不会直接创建Writer对象。

方法

上面看似是五个版本的 write 方法，其实也还是三个。

当前 IO 流对象，read 和 write 就属于直接读写文件了。要想提高效率：

1. 写代码的时候，手动床见缓冲区（byte[]），手动减少 read write 次数
2. 使用标准库提供的“缓冲区流”BufferStream 把 InputStream 之类的对象套上一层

示例一

扫描指定目录，并找到名称中包含指定字符的所有普通文件（不包含目录），并且后续询问用户是否要删除该文件

package file;

import java.io.File;
import java.util.Scanner;

public class mySearchAndDelete {
    public void searchAndDelete () {
        Scanner scanner = new Scanner(System.in);
        System.out.println("请输入要搜索的目录：");
        String rootDir = scanner.next();
        File rootfile = new File(rootDir);
        if (!rootfile.isDirectory()) {
            System.out.println("输入的不是目录！");
            return;
        }
        System.out.println("请输入要删除的关键字：");
        String keyWord = scanner.next();
        int count = scanDir(rootfile, keyWord, scanner);
        if (count == 0) {
            System.out.println("没有发现带有关键字的文件");
        } else {
            System.out.println("搜索完成，共发现 " + count + " 个匹配文件。");
        }
    }

    public int scanDir(File rootfile, String keyWord, Scanner scanner) {
        // 1. 列出当前目录中包含的内容
        File[] files = rootfile.listFiles();
        if (files == null) {
            return 0;
        }
        int count = 0;
        // 2. 遍历当前目录中的内容
        for (File file : files) {
            // 3. 判断当前文件是目录 or 文件
            if (!file.isFile()) {
                // 4. 如果是目录，继续遍历
                count += scanDir(file, keyWord, scanner);
            } else {
                // 5. 如果是文件，则查找关键字
                if (deleteFile(file, keyWord, scanner)) {
                    count++;
                }
            }
        }
        return count;
    }

    private boolean deleteFile(File file, String keyWord, Scanner scanner) {
        if (!file.getName().contains(keyWord)) {
            return false;
        }
        System.out.println(
                "发现文件: "
                        + file.getAbsolutePath()
                        + "，包含关键字！是否删除？(y/n)"
        );
        String input = scanner.next();

        if (input.equalsIgnoreCase("y")) {
            boolean success = file.delete();
            if (success)
                System.out.println("文件已删除！");
            else
                System.out.println("文件删除失败！");
        }
        return true;
    }
}

示例二

进行普通文件的复制

package file;

import java.io.*;
import java.util.Scanner;

public class myCopyFile {
    public void copyFile () {
        Scanner scanner = new Scanner(System.in);
        System.out.println("请输入源文件路径：");
        String srcPath = scanner.next();
        System.out.println("请输入目标文件路径：");
        String destPath = scanner.next();
        File srcFile = new File(srcPath);

        // 1. 先判断源文件是否存在
        if (!srcFile.isFile()) {
            System.out.println("源文件不存在或不是文件");
            return;
        }
        File destFile = new File(destPath);
        // 如果目标路径是一个已经存在的文件夹
        if (destFile.isDirectory()) {
            destFile = new File(destFile, srcFile.getName());
        }
        // 2. 判断目标文件是路径 or 文件（destPath不一定存在）
        File parentFile = destFile.getParentFile();
        if (parentFile != null && !parentFile.isDirectory()) {
            System.out.println("目标文件所在目录不存在");
            return;
        }
        // 3. 此处进行读写操作
        try (InputStream inputStream = new FileInputStream(srcFile);
             OutputStream outputStream = new FileOutputStream(destFile)) {
            while (true) {
                byte[] buf = new byte[1024];
                int num = inputStream.read(buf);
                if (num == -1) {
                    break;
                }
                outputStream.write(buf, 0, num);
            }
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
}

示例三

扫描指定目录，并找到名称或者内容中包含指定字符的所有普通文件（不包含目录）

注意：当前现在的方案性能较差，所以尽量不要在太复杂的目录下或者大文件下实验

package file;

import java.io.*;
import java.util.Scanner;

public class myFileSearcher {
    public void searchFile () {
        Scanner scanner = new Scanner(System.in);
        System.out.println("请输入要搜索的目录：");
        String rootDir = scanner.next();
        File rootFile = new File(rootDir);
        if (!rootFile.isDirectory()) {
            System.out.println("输入的不是目录！");
            return;
        }
        System.out.println("请输入要搜索的关键字：");
        String keyWord = scanner.next();
        scanDir(rootFile, keyWord, scanner);
    }

    public static void scanDir (File rootFile, String keyWord, Scanner scanner) {
        // 1. 列出当前目录下所有内容
        File[] files = rootFile.listFiles();
        if (files == null) {
            return;
        }
        // 2. 遍历当前目录下的所有文件
        for (File file : files) {
            // 如果是文件
            if (file.isFile()) {
                dealFile(file, keyWord, scanner);
            } else {
                // 如果是目录
                scanDir(file, keyWord, scanner);
            }
        }
    }

    public static void dealFile(File file, String keyWord, Scanner scanner) {
        // 1. 判断文件名是否包含关键字
        if (file.getName().contains(keyWord)) {
            System.out.println("文件名包含关键字:" + file.getAbsolutePath());
        }
        // 2. 判断文件内容是否包含关键字。由于keyWord是字符串，就按照字符流读取
        StringBuilder stringBuilder = new StringBuilder();
        try (Reader reader = new FileReader(file)) {
            while (true) {
                char[] chars = new char[1024];
                int n = reader.read(chars);
                if (n == -1) {
                    break;
                }
                stringBuilder.append(chars, 0, n);
            }
        } catch (IOException e) {
            System.out.println("文件读取失败：" + file.getAbsolutePath());
            return;
        }
        // 3. 判定stringBuilder 是否包含关键字
        if (stringBuilder.indexOf(keyWord) >= 0) {
            System.out.println("文件内容包含关键字: " + file.getAbsolutePath());
        }
        return;
    }
}

网络编程，指通过编写程序，利用计算机网络实现不用设备或进程之间的数据通信。

可以理解为，网络编程就是让两台或多台计算机上的程序能够通过网络交换数据~

就比如像是：

• 微信聊天：用户发送消息，服务器将消息转发给接收方。
• 浏览网页：浏览器向服务器发送 HTTP 请求，服务器返回网页内容。

1.1 基本模型

网络编程中最常见的就是客户端/服务端模型，也就是 Client/Server 简称 C/S

但首先需要先了解发送端和接收端：

发送端：数据的发送方进程，称为发送端。发送端主机即网络通信中的源主机

接收端：数据的接收方进程，称为接收端。接收端主机即网络通信中的目的主机

收发端：发送端和接收端两端，也称为收发端

注意：发送端和接收端只是相对的，只是一次网络数据传输产生数据流向的概念

接下来就到了服务端和客户端~

服务端：在常见的网络数据传输场景下，提供服务的一方进程，称为服务端，可以提供对外服务。

客户端：获取服务的一方进程，称为客户端。

模型就像下图中：

以浏览器访问网站为例：

1. 客户端发送请求：浏览器向服务器发送 HTTP 请求。
2. 服务器接收请求：服务器接收请求并执行相应的业务逻辑。
3. 服务器返回响应：服务器将处理结果通过网络发送给客户端。
4. 客户端接收响应：浏览器接收数据，并将网页内容显示给用户。

2.Socket

接下来才是正题~

浅浅了解计算机网络相关知识就可以知道，程序完成的事情就是把请求发过去，再把响应包收回来。

但关键是 Java 程序或者说代码自身不能自己从头控制网卡、组织所有协议头、处理整个网络通信过程。但操作系统已经提供了这些网络能力~

程序通过一组接口，就能够调用刚刚所说的部分功能。而 Socket 套接字就是操作系统提供的网络通信机制中的通信端点~

可以这样理解：创建和使用 Socket，就是让程序获得了一个用于收发网络数据的端点。

Socket api 这就是传输层给应用层提供的。

而 Java 又把这些能力封装成了类，所以在 Java 中就可以通过创建对象、调用方法来完成通信。

而传输层本身就有两个很重要的协议~

分别是 TCP 和 UDP。这两个协议规定了传输层的通信方式。而 Socket 让程序能够使用这些通行能力。

另外 TCP 和 UDP 差别也非常大，编写代码的时候风格也是不同的~

• TCP 是有连接，可靠传输，面向字节流，全双工的
• UDP 是无连接，不可靠传输，面向数据报，全双工的

下面分别介绍一下这两个特点，当然 也是再温习一遍计算机网络啦

2.1 TCP 协议特点

1. 首先是有连接，TCP 在正式传输数据之前，需要现在通信双方之间建立逻辑连接。通过三次握手来建立连接；然后是在建立好的连接基础上交换数据；再然后就是断开连接，通常是通过四次握手完成也可能通过 RST 等方式终止连接 这里的连接不是物理线路，而是双方维护的通信状态，就比如序列号、缓冲区和窗口大小等~

2. 可靠传输。TCP 能够保证，只要连接正常工作并且数据成功交付，接收方就能按照正确顺序获得完整、不重复的字节数据。TCP 主要就是通过这些机制来实现可靠传输：序列号、确认应答（ACK）、超时重传、校验和、接收端去重和重排序、流量控制、拥塞控制。就比如：发送方一次发送 A、B、C 三段数据，其中 B 在网络中丢失。 TCP 会检测到数据缺失，并通过重传等机制尝试恢复数据。另外需要注意的是：可靠传输不代表数据绝对不会丢失，也不代表一定传输成功。如果网络持续中断，TCP 最终可能超时或连接失败。它的可靠性主要体现在不会把缺失、乱序的数据当作完整、有序的数据流正常交付。

3. 首先知道 TCP 是面向字节流的，TCP 将应用程序发送的数据看作一串连续的字节，而不是一条条独立的消息。假设我向对方先后发送两段内容，分别是hello、world。发送方执行了两次 write()，但接收方不一定恰好执行两次 read() 才能读完，意思就是他的一次读取不一定刚好对应发送方的一次发送。但最后接收方看到的还会是按顺序排列的字节helloworld。 这也就是为什么 TCP 通信中可能出现应用层所说的粘包、半包问题。本质原因就是 TCP 不保留应用程序每次写入时的消息边界。

4. 最后就是全双工通信。通信双方可以在同一时间发送和接收数据。 例如在聊天程序中，客户端可以向服务器发送消息，同时服务器也可以向客户端发送消息，不必等待对方发送完毕。

2.2 UDP 协议

UDP 同样具有四个特点，无连接、不可靠传输、面向数据报、全双工通信。

1. 无连接，UDP 在发送数据之前，不需要像 TCP 一样通过三次握手建立连接。发送方只需要知道接收方的 IP 地址和端口号，就可以尝试发送数据报。

DatagramSocket socket = new DatagramSocket();

byte[] data = "Hello".getBytes();

DatagramPacket packet = new DatagramPacket(
        data,
        data.length,
        InetAddress.getByName("127.0.0.1"),
        8080
);

socket.send(packet);

这里创建 UDP 套接字后，直接调用 send() 发送数据报，无须先建立 TCP 那样的连接。注意了，不需要建立连接，并不意味着接收方一定能收到数据。

1. 不可靠传输。UDP 不提供 TCP 那样的可靠传输保证。在传输过程中可能会出现丢失、乱序、重复、损坏或被丢弃。UDP 本身不提供确认应答、超时重传、按序交付等机制 UDP 并不是一定会丢包，而是协议本身不保证数据一定到达。

2. 面向数据报。UDP 将应用程序每次发送的数据视为一个独立的数据报，保留各个数据报之间的边界。就比如，发送方连续发送：第一个数据报 Hello、第二个数据报 World。接收方不会像 TCP 一样把两个数据报当成一个连续的字节流交付。

至于全双工就可 TCP 一样了。

2.3 UDP 数据包套接字编程

2.3.1 API 介绍

我们都知道，计算机中的“文件”通常都会是一个“广义的概念”。文件还能代指一些硬件设备（操作系统管理硬件设备，也是抽象成文件进行统一管理的）

那么网卡 —> socket 文件

在操作网卡的时候，流程就和操作普通文件差不多，也需要打开 -> 读写 -> 关闭

打开的时候也会在文件描述符表中分配一个表项

DatagramSocket

首先是 DatagramSocket类，它是 UDP Socket，用于发送和接收 UDP 数据报。

其构造方法如下：

主要注意他的参数。

另外要补充，客户端通常不用手动指定的原因是，服务器通常需要一个实现约定的端口，客户端通常使用系统分配的端口。

我这样举个例子更好理解些：

假如我在学校一食堂 18 号窗口开了一家餐饮。那么我向同学们发传单告诉了他们我的餐饮地址，于是同学就知道我的餐饮位置在哪就会来到我的餐饮店前。这就像是客户端需要知道服务端的 IP 地址以及端口号一样。

但是同学来到我窗口点了餐回到座位上时，通常座位会是随机性的，因为你不能保证你去的时候不一定没有人坐吧~所以就像是客户端一样，你也不能保证你指定的端口号是不是被其他的进程给占用了

DatagramSocket的常用方法：

此处所说的阻塞等待是，假设服务器执行到了socket.receive(packet);但还没有收到数据。于是执行这个方法的线程就会等待，后面的代码暂时就不会执行。

DatagramPacket

第二个类就是DatagramPacket了。DatagramPacket 用于封装 UDP 通信中发送或接收的数据报包。

它共有 6 个构造方法，可以分为接收数据和发送数据两类。

DatagramPacket用于接收的构造方法：

使用范例：

byte[] buffer = new byte[4096];

DatagramPacket packet =
        new DatagramPacket(buffer, buffer.length);

此处就相当于准备好一个容器，“收到数据后，请把数据放进这个数组，本次最多接收这么多字节”

真正接收要调用：

socket.receive(packet);

接收完成后，packet 中不仅有数据，还有发送方的 IP 和端口。

receive 与之前的 read 方法一样，这也是一个把参数作为“输出结果”的一个输出型参数

DatagramPacket用于发送的构造方法：

涉及到的一些参数说明：

DatagramPacket常用方法：

2.3.2 回显服务器示例

UDP Echo Server

将服务器分为两部分，

• start()：负责接收请求、处理请求、返回响应
• process()：负责具体业务

import java.io.IOException;
import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.SocketException;

public class UdpEchoServer {
    public DatagramSocket socket = null;

    public UdpEchoServer(int port) throws SocketException {
        socket = new DatagramSocket(port);
    }

    public void start() throws IOException {
        System.out.println("服务器启动...");

        while (true) {
            // 1. 读取请求并解析
            // DatagramPacket 表示一个UDP数据包，此处传入的字节数组，就保存UDP的载荷部分
            DatagramPacket requestPacket = new DatagramPacket(new byte[4096], 4096);
            socket.receive(requestPacket);
            // 把读取到的二进制数据，转成字符串，只是构造有效的部分
            String request = new String(requestPacket.getData(),
                    0,
                    requestPacket.getLength());

            // 2.根据请求，计算响应（服务器中关键的逻辑）
            // 但此处目前只打算写回显服务器，该环节相当于省略
            String response = process(request);

            // 3.把响应返回给客户端
            // 根据response构造DatagramPacket，发送给客户端
            // 注意：此处不能使用response.length()
            DatagramPacket responsePacket = new DatagramPacket(response.getBytes(),
                    response.getBytes().length,
                    requestPacket.getSocketAddress());
            // 此处还不能直接发送，UDP协议滋生没有保存对方的信息（不知道发给谁）
            // 需要指定目的IP 和 目的端口
            socket.send(responsePacket);

            // 4. 打印一个日志
            System.out.printf("[%s:%d] req: %s, resp: %s\n", responsePacket.getAddress().toString(),
                    requestPacket.getPort(), request, response);
        }
    }

    private String process(String request) {
        return request;
    }

    public static void main(String[] args) throws IOException {
        UdpEchoServer server = new UdpEchoServer(9090);
        server.start();
    }
}

UDP Echo Client

UDP 回显客户端，需要完成的如下：

• 从键盘读取文字；
• 把文字发送给服务器；
• 接收服务器返回的文字；
• 显示结果；

import java.io.IOException;
import java.net.*;
import java.util.Scanner;

public class UdpEchoClient {
    private DatagramSocket socket = null;
    private String serverIp;
    private int serverPort;

    public UdpEchoClient (String serverIp, int serverPort) throws SocketException {
        this.serverIp = serverIp;
        this.serverPort = serverPort;
        socket = new DatagramSocket();
    }

    public void start () throws IOException {
        Scanner scanner = new Scanner(System.in);
        try {
            while (true) {
                // 1. 从控制台读取用户输入的内容
                System.out.println("请输入要发送的内容：");
                if (!scanner.hasNext()) {
                    break;
                }
                String request = scanner.next();
                // 2. 把请求发送给服务器，需要构造 DatagramPacket 对象
                // 构造过程中，不光要构造载荷，还要设置服务器的IP和端口号
                DatagramPacket requestPacket = new DatagramPacket(request.getBytes(),
                        request.getBytes().length,
                        InetAddress.getByName(serverIp),
                        serverPort);
                // 3. 发送数据报
                socket.send(requestPacket);
                // 4. 接收服务器的响应
                DatagramPacket responsePacket = new DatagramPacket(new byte[4096], 4096);
                socket.receive(responsePacket);
                // 5. 从服务器读取的数据进行解析，并打印
                String response = new String(responsePacket.getData(), 0, responsePacket.getLength());
                System.out.println(response);
            }
        } finally {
            socket.close();
        }
    }

    public static void main(String[] args) throws IOException {
        UdpEchoClient client = new UdpEchoClient("127.0.0.1", 9090);
        client.start();
    }
}

就可以得到这样一个运行效果~

当然，如果有云服务器的话，可以自己打一个 jar 包放到云服务器上，并启动该程序：

java -jar jar包名

此时该程序就在服务器上运行起来了，只要能访问该服务器的都可以直接进行回显打印~

2.4 TCP 流套接字编程

2.4.1 API 介绍

ServerSocket

ServerSocket是 TCP 服务端用的核心类，作用是在服务器端监听某个端口，并等待客户端建立 TCP 连接。也就是说是专门给服务器用的

常用构造方法：

通常都会直接先指定好端口：

ServerSocket serverSocket = new ServerSocket(9090);

常用方法：

其中，注意accept()方法是一个阻塞方法，它会开始监听指定端口，有客户端连接后，返回一个服务端 Socket 对象，并基于该 Socket 建立与客户端的连接，否则阻塞等待~

就比如：

System.out.println("等待客户端连接...");
Socket clientSocket = serverSocket.accept();
System.out.println("客户端已连接");

当执行到accept()的时候，如果暂时没有客户端连接，当前线程就会停在这里~

注意，TCP 这里就没有 send/receive 这样的操作...

Socket

这个类是客户端和服务端都能用。Socket是客户端或服务端中接收到服务端建立连接（accept）的请求后，返回的服务端 Socket。不管是客户端还是服务端，都是双方建立连接后，用来保存对端信息以及与对方收发数据的~

常用构造方法：

常用方法：

到这里我再讲上面一起解释了：

在 TCP 中，常会这样去接收客户端发来的连接，你可以理解为这样去接电话~

private ServerSocket serverSocket = null;
Socket clientSocket = serverSocket.accept();

其实就是ServerSocket负责等客户端来连接，Socket负责连接成功之后真正和某个客户端通信

我给个比喻：

private ServerSocket serverSocket = null：理解为小哥在马路牙子上揽客 [ 外场 ]~

Socket clientSocket = serverSocket.accept()：理解为小姐姐给客人提供点单服务 [ 内场 ]~

2.4.2 回显服务器示例

TCP Echo Server

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.PrintWriter;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.Scanner;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class TcpEchoServer {
    private ServerSocket serverSocket = null;

    // 此处和UDP服务器类似，也是在构造对象的时候，绑定端口号
    public TcpEchoServer (int port) throws IOException {
        serverSocket = new ServerSocket(port);
    }

    public void start () throws IOException {
        System.out.println("服務器启动");
        // 此处为提供多个客户端服务，需要使用多线程来解决
        // 否则只能服务于一个客户端
        // 此处用线程池来解决，通常不会使用fixThreadPool
        ExecutorService executorService = Executors.newCachedThreadPool();
        while (true) {
            // 对TCP来说，需要先处理客户端发来的连接
            // 通过读写clientSocket，和客户端进行通信
            // 若无客户端发起连接，此时accept就会阻塞
            // 此处主线程负责进行accpet，每次accept到一个客户端，就创建一个线程
            Socket clientSocket = serverSocket.accept();

            executorService.submit(() -> {
                processConnection(clientSocket);
            });
        }
    }

    // 该方法处理一个客户端的连接，但被线程池调用
    private void processConnection(Socket clientSocket) {
        System.out.printf("[%s,%d]客户端上线!\n",
                          clientSocket.getInetAddress(),
                          clientSocket.getPort());
        try (InputStream inputStream = clientSocket.getInputStream();
             OutputStream outputStream = clientSocket.getOutputStream()) {
            // 针对 InputStream 套了一层
            Scanner scanner = new Scanner(inputStream);
            // 针对 OutputStream 套了一层
            PrintWriter writer = new PrintWriter(outputStream);
            // 分成三个步骤
            while (true) {
                // 1. 读取请求并解析，可以直接read，也可以借助Scanner来辅助完成
                if (!scanner.hasNext()) {
                    // 连接断开
                    System.out.printf("[%s,%d] 客户端下线!\n",clientSocket.getInetAddress(),
                                      clientSocket.getPort());
                    break;
                }
                String request = scanner.next();
                // 2. 根据请求计算响应
                String response = process(request);
                // 3. 返回响应到客户端
                writer.println(response);
                writer.flush();
                // 打印日志
                System.out.printf("[%s:%d] req: %s, resp: %s\n",
                                clientSocket.getInetAddress(),
                                clientSocket.getPort(),
                                request,
                                response);
            }
        } catch (IOException e) {
            throw new RuntimeException(e);
        } finally {
            try {
                clientSocket.close();
            } catch (IOException e) {
                throw new RuntimeException(e);
            }
        }
    }

    private String process(String request) {
        return request;
    }

    public static void main(String[] args) throws IOException {
        TcpEchoServer server = new TcpEchoServer(1234);
        server.start();
    }
}

TCP Echo Client

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.PrintWriter;
import java.net.Socket;
import java.util.Scanner;

public class TcpEchoClient {
    private Socket socket = null;

    public TcpEchoClient(String serverIp, int serverPort) throws IOException {
        // 直接把字符串的IP地址设置进来
        socket = new Socket(serverIp, serverPort);
    }

    public void start() {
        Scanner scanner = new Scanner(System.in);
        try (InputStream inputStream = socket.getInputStream();
             OutputStream outputStream = socket.getOutputStream()) {
            Scanner scannerNet = new Scanner(inputStream);
            PrintWriter writer = new PrintWriter(outputStream);

            // 从控制台读取请求，发送给服务器
            while (true) {
                // 1. 从控制台读取用户输入
                String request = scanner.next();
                // 2. 发送给服务器
                writer.println(request);
                // 加上刷新缓冲区操作，才是真正发送数据
                writer.flush();
                // 3. 读取服务器返回的响应
                String response = scannerNet.next();
                // 4. 打印到控制台
                System.out.println(response);
            }
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

    public static void main(String[] args) throws IOException {
        TcpEchoClient client = new TcpEchoClient("127.0.0.1", 1234);
        client.start();
    }
}

具体解释~

1. Socket 问题

两部分代码整体的运行逻辑主要就是：

以上是客户端和服务端接收和发送的核心部分，主要就是需要处理清楚请求包和响应包之间的处理关系即可~

另外，客户端里的 socket 和 服务端接收客户端请求的 socket 不一样~

这俩 socket 对象不是同一个对象（分别是在不同进程中，甚至在不同主机上）

从更严谨的话来说就是：

这两个 Socket 是两个不同的 Java 对象，分别位于客户端和服务端程序中，但它们代表同一条 TCP 连接的两个端点。

结构就像是上面图中一样~

当然，用电话比喻也是没问题的。就像是 A 和 B 在进行一次通信，但 A 和 B 绝对不是同一个对象！！！

1. 运行问题

如果是 UDP 和 TCP 一起运行同一个端口，实际上并不会受影响，主要是因为协议不同才不会冲突~

然后，客户端注意，需要进行配置修改才能多客户端运行：

这样就能成功运行多个实例了~

1. IO 流问题

try (InputStream inputStream = socket.getInputStream();
    OutputStream outputStream = socket.getOutputStream()) {
        Scanner scannerNet = new Scanner(inputStream);
        PrintWriter writer = new PrintWriter(outputStream);
    ...
}

此处不是“又拿了一次 IO 流”，而是在原始字节流外面套了一层更方便使用的高级工具。

首先我们知道，InputStream是字节输入流，也就是从网络接收到的数据本质上就是：01001000...类似这种~也就是一个个字节。

如果是直接使用InputStream，通常还需要自己写：

byte[] buffer = new byte[1024];
int n = inputStream.read(buffer);
String str = new String(buffer, 0, n);

所以才在这里套一层Scanner，它会将字节流处理为字符串，因此也就不需要自己处理 byte[]。

OutputStream也是一样的道理。如果直接用它的话，就还需要：

String request = "hello";
outputStream.write(request.getBytes());

但是我们现在发送的是文本，所以套一个PrintWriter之后就可以很自然的用 println 写入缓冲区，最后再 flush 即可。

总结上面就是，Socket 提供底层网络 IO 通道，InputStream/OutputStream 负责字节传输，而 Scanner/PrintWriter 是为了更方便地以文本形式使用这些字节流。

1. flush()必须出现

代码中的部分：

writer.println(request);
writer.flush();

需要特别理解一下，PrintWriter为了提高 IO 效率，会涉及缓冲。

当执行writer.println(request)这部分操作的时候，可以先理解为“把准备发送的数据交给PrintWriter”。而flush则是表示：“把还没有真正向下输出的数据立即刷到 OutputStream”

所以此处的两行代码基本就是属于固定搭配~

1. println()和 hasNext 的玄机

注意客户端和服务端里的两部分代码：

// 客户端
writer.println(request);
writer.flush();

// 服务端
if (!scanner.hasNext()) {
    ......
}
String request = scanner.next();

这之间形成了一套基于空白字符分隔消息的简单应用层协议~

首先要知道不能直接把 println(request) 改成 print(request)。如果只是改成 print(request) 再 flush()，很可能服务器会一直阻塞在 hasNext()，因为它不知道这一条请求到底什么时候结束。

因为当我们使用println的时候，println会在后面追加换行符，类似相当于追加一个\n；更准确地说，println() 添加的是当前平台的行结束符。

Linux:
hello\n

Windows:
hello\r\n

而服务端的玄机又在：

服务端的Scanner是Scanner scanner = new Scanner(inputStream)。而Scanner默认采用的分隔符是空白字符（空格、\t、\n、\r 等）

我让 GPT 给出了服务器大概解析的样子~

也就是说 scanner 的 hasNext 和 next 方法都是以分隔符作为判断隔断标准，以解析一段token/数据项

3.IO 多路复用（了解一下~）

如果客户端进一步增加，此时多线程/线程池，就会产生大量的线程~

IO 多路复用，就是让操作系统统一等待多个连接的 IO 事件，告诉程序哪些连接已经就绪，线程再去处理这些链接。

在我们前面写的 TCP 回显服务器一开始是没有使用线程池来完成的，于是就导致了第二个第三个线程...一直在等待第一个线程完成直至断开连接，这样也才到第二个线程（当然也还是要竞争~）

于是乎就想出了使用线程池来让多个客户端一同完成服务~但是！这样就变成了每一个连接安排一个线程，各自等待自己的客户端。但如果连接很多，且大部分时间都没有消息，就会有很多线程在等待~

那么 IO 多路复用就是为了让一个线程照看多个连接，谁有数据，就先处理谁。

拿一个餐厅比例：

原来的方式就像是：

每桌安排一个服务员，顾客还没决定吃什么，服务员一直站在这桌等

多路复用的方式就像是：

多个餐桌共用一个服务员，餐厅的呼叫系统告诉他哪桌需要服务，他再过去处理

如果 B 桌和 C 桌都按了铃，这个服务员可以先处理 B，再处理 C。

围绕这里，就需要我们先了解四个概念：

• IP 地址
• 端口号
• 协议
• 五元组

它们之间有联系，我们把它们放到同一个场景里理解。

1. 网络通信基础

我们平常会说，我的电脑正在和服务器通信，但再往里面看，真正需要交换数据的是：两边正在运行的程序，也就是进程。

就比如：

之前学习 JDBC 的时候就写过相关代码：

DriverManager.getConnection(
    "jdbc:mysql://127.0.0.1:3306/java113",
    user,
    password
);

此处正是设计网络通信了，Java 程序通过 JDBC 驱动，与 MySQL 服务程序建立连接、交换数据。所以会说，网络通信更具体的说，是进程之间基于网络传输数据。

至于接收数据的程序在哪台设备上以及找到设备以后把数据交给哪个程序这就需要 IP 和端口号了。

1.1 IP 地址

IP 地址可以理解为，用于定位主机的网络地址

就像是寄快递填写的，某个城市、某条街道、某栋楼

同样，发送网络数据时，也需要有目标地址，类似192.168.1.20

更严谨地说，IP 地址配置在网络接口上，一台设备可以有多个 IP 地址，并不是每台电脑永远只有一个地址。

此处我们讨论的是 IPv4：

IPv4 地址占 32 位，也就是 4 个字节，是一个 32 位的二进制数，通常分成四个 8 位部分。

使用的是点分十进制表示法

而常用的 127.0.0.1，则是一个回环地址，通常用于访问本地的网络服务~

而 localhost，则是主机名，但常被解析为127.0.0.1，当然也有可能解析为 IPv6 的 ::1

对于当前很多 AI 小白利用 AI 做项目的时候，就常有将访问本地资源的localhost分享给他人而搞出段子~

你可以这样记住区别：

localhost 是主机名，127.0.0.1 是 IPv4 回环地址。localhost 通常会解析到 127.0.0.1，但也可能解析到 IPv6 的 ::1，所以两者不能认为绝对完全相同。

1.2 端口号

端口号就是负责，数据发送到目标主机时，将数据送到哪一个进程的。

用快递类比就是：

• IP 地址类似收货地址。
• 端口号类似这个地址下的收件入口。

通常，一台设备可以有：

那么192.168.1.20:3306和192.168.1.20:8080，虽然目标设备相同，但目标服务入口不同。

而端口号的范围也就是 TCP、UDP 等传输协议使用 16 位端口号，所以数值范围是 0~65535。因为 2¹⁶=65536

而端口号和进程编号 PID 不是一回事~

PID 只是用于操作系统用来标识进程的，而一个进程可以拥有多个端口号~

实际接收数据时，操作系统会根据地址、传输协议、端口等信息，找到对应的套接字，再交给应用程序处理。后面学习 Java Socket 时，会具体使用它。

1.3 协议

协议的作用就相当于双方提前约定“数据怎样组织、怎样解释，以及通信过程中怎样行动”

就比如会这样约定：

这里是在举自定义协议规则的例子，具体协议会有自己的设计。

所以，协议不仅规定数据格式，也会规定通信行为。

TCP、UDP、HTTP、MySQL 协议等，都在不同层次解决通信中的问题。

你写 JDBC 时，不需要自己把 SQL 拼成 MySQL 协议的数据包，是因为：

JDBC 驱动已经帮你实现了与 MySQL 服务通信的协议处理。

1.4 五元组

对于常见的 TCP、UDP 通信，这五项是：

此处的“源”和“目的”，是相对于当前的数据传输方向来说的~

我这里继续拿 Java 访问 MySQL 举例：

假设

• Java 程序所在设备的 IP 是 192.168.1.10
• MySQL 所在设备的 IP 是 192.168.1.20
• Java 这次连接使用本地端口 50000
• MySQL 服务监听 3306
• 使用 TCP 通信

Java 向 MySQL 发送数据时：

MySQL 回复时，源和目的会交换：

所以显然，客户端并不永远是“源”，服务器也不永远是“目的”。谁正在发送，谁就是这个方向上的源。

假设很多客户端都在连接同一个 MySQL 服务。

它们的目的地址和目的端口可能都是192.168.1.20:3306

服务器还需要区分：

这份数据来自哪一条连接？回复应该发给谁？

这就需要结合客户端的地址和端口。

因此，同一个服务端口可以接待很多连接，不是“一条连接就独占整个服务端口”。

在 Windows 中，可以通过：

netstat -ano

三个选项分别表示：

如果需要过滤（一般是通过端口号或进程 PID 过滤），可以使用 netstat -ano | findstr 过滤字符串

2. 协议分层

当前的问题是，刚刚上面的所有工作该如何分工。

解决方法是，把网络通信的工作划分为不同层次，各层负责自己的任务，并通过约定好的接口协作。

2.1 同层之间遵守协议，相邻层之间使用服务

先来看上图中的例子：

把打电话分成两层：

语言层 负责双方用什么语言交流，怎样理解对方说的话

通信设备层 负责怎样通过设备传递声音

这里其实有两套规则：

语言层规则

双方需要理解汉语，才能明白：

“你明天几点到？”

通信设备层规则

电话系统需要按照相应规则，把声音传递给对方。

它负责让对方听到声音。

其实也就是，第一层封装，第二层解耦

1. 上层协议不需要了解下层协议的细节~打电话的人会说话就行，不需要理解电话机原理
2. 分层后，灵活的替换其中的某一层，对于整体的工作过程影响很小

关于下方的两个改变，主要改变的是：上层怎样组织和理解表达内容

底下的电话系统仍然可传递声音。

所以分层的价值就是，在接口和服务约定保持兼容的情况下，一层的变化可以尽量减少对其他层的影响。

当然，实际网络通信比这个例子要复杂，一层的变化可以尽量减少对其他层的影响。

其实分层是比较类似“面向接口编程”

就类似调用方使用接口，提供方通过接口提供服务。

网络分层也有类似的思想：

• 上层使用下层提供的服务
• 下层通过接口提供能力，隐藏自己的实现细节

同层之间遵守协议，相邻层之间使用服务

此处要分清两个方向：

同一设备内部，上层通过接口，使用下层的服务

通信双方之间，双方对应层需要遵守相应的协议

2.2 OSI 七层模型

OSI（Open System Interconnection）开放系统互联

但 OSI 七层网络模型复杂也不实用，所以 OSI 七层模型都没有落地实现

实际组建网络时，只是以 OSI 七层模型设计中的部分分层，也就是以下 TCP/IP 五层（或四层）模型来实现

2.3 TCP/IP 五层（或四层）模型

五层或四层只是视角不同罢了~

TCP/IP 是一组协议的代名词，其中包含 TCP、UDP、IP 以及许多应用层协议

1. 首先是应用层。它关注的是应用程序之间，应该交换什么消息，又该如何理解这些信息。就比如 HTTP(网页等资源的请求与响应)、SMTP(电子邮件传输)、FTP(文件传输)等。在编写 Java 网络程序，主要就是在这一层组织业务消息，并通过 Socket 等接口使用下层的传输服务。当然，这一层你也可以理解为买家在拿到包裹后如何使用~
2. 传输层关注的是通信两端的应用怎样交换数据（如 TCP 传输控制协议）。之前了解到的端口号就在此处发挥作用。字面意思就是，两个任意设备之间的通信，不考虑中间过程，只考虑起点和终点。就像是卖家在寄件时，只负责填发货地址和到货地址即可。
3. 网络层，处理地址与跨网络转发，也就是负责地址管理和路由选择。两台主机之间可能隔着很多网络和路由器（就像是《无敌破坏王》中那样到网络中心一样），这一层就关心数据下一步该往哪里转发，对应的就是前面的 IP 地址。路由器会根据目的 IP 地址和路由表等信息，选择下一跳。并不要求发送方提前固定好整条完整路径。
4. 数据链路层，则是负责设备之间的数据帧的传送和识别。这一层通常会处理数据帧的组织、链路上的寻址（如以太网中的 MAC 地址）、介质访问、差错检测等。主要就是关注当前链路上怎样把数据送到下一站。
5. 物理层，真正传递信号。数据帧最终还需要通过实际介质传出去。而物理层就负责光/电信号的传递方式。这一层设计信号编号、传输介质、接口等问题。所以应用层所表达的业务消息，最终需要借助这些物理能力完成传递。

就相当于，我在淘宝上买了床刷子

我则关心床刷子买到之后，我要如何使用 ->应用层

卖家只要关心收件人信息 ->传输层

物流公司则关心包裹以怎样路径传输的 ->网络层

快递小哥/货车司机考虑的是相邻节点 ->数据链路层

国家在铺桥修路 ->物理层

写代码主要就是工作在应用层了~

而像主机、路由器、交换机就分别对应下方：

主机 -> 工作过程涉及到 从物理层->应用层（通过应用程序满足网络通信的需求）

路由器-> 工作过程涉及到 从物理层->网络层（组建局域网，进行网络）

交换机-> 工作过程涉及到 从物理层->数据链路层（对路由器的接口的扩展，不需要考虑组网的问题）

此处说的是传统意义上的交换机和路由器，也称为二层交换机（工作在 TCP/IP 五层模型的下两层）、三层路由器（工作在 TCP/IP 五层模型的下三层）

上面的工作区间也是一个经典的面试题

2.4 一则信息的全过程

2.4.1 数据发送

假设我通过 QQ，发送 Hello 给好友：

1. 应用程序会先获取到用户输入，构造一个应用层的数据包。这个应用层数据包就会遵循应用层的协议（这部分往往是开发者自己定义的）。假设此处的协议格式是：

发送者的 qq 号，接收者的 qq，消息的时间，消息正文。（类似下图这种）

就以此为例：1234567,7654321,2026-10-04，12:00:00，Hello（当然实际是会加密的）

注：上述所说的数据包往往是“结构化数据”。发送数据的时候，把结构化数据 -> 字符串/二进制 bit 流（序列化）；接收数据的时候，字符串/bit 流 -> 结构化数据（反序列化）

1. 应用程序调用传输层提供的接口（API 也就是 socket api），把数据交给传输层。传输层拿到数据之后，构造出“传输层数据包”。传输层的协议主要就是两个：TCP、UDP。得到数据包形式：TCP 数据包 = TCP 报头（header） + TCP 载荷（payload）。TCP 载荷就是应用层数据包。

1. 传输层构造好数据之后，继续调用网络层的 api，把传输层的数据包交给网络层。网络层继续进行处理。网络层最主要的协议就是 IP 协议。IP 协议会继续对上述数据包进行加工 -> 拼上 IP 报头~。得到的 IP 数据包形式就是： IP 数据包 = IP 报头 + IP 载荷（整个传输层的数据包）。其中 IP 报头包含的信息也有很多的，就比如源 IP 或 目的 IP。

注：IP 报头还会记录传输层使用的是哪个协议。同样的，传输层报头中也会记录应用层使用的是哪个协议（准确的说是数据交给哪个应用程序）......

1. IP 协议继续调用数据链路层的 api ，把 IP 数据包交给数据链路层。数据链路层中的核心协议就是“以太网”这个协议。以太网也会在网络层数据包的基础上进一步加工~

到目前为止，数据还在当前主机上转悠，还没出门~

1. 以太网继续把这样的数据交给硬件设备（网卡）。网卡会按上述二进制数据最终以光信号/电信号/电磁波信号 传播出去~此时数据才算出门了~

封装顺序就是 应用数据 -> TCP 报文段 -> IP 数据包 -> 以太网帧 -> 信号

从上到下，数据都要进一步加工

解释一下：网络数据包/帧/报/段

段（segment） TCP 用段

报（Datagram） UDP用报

包（packet） IP 用包

帧（frame） 数据链路层 以太网数据帧

但其实日常工作中，确实也不会明确区分这些概念~

2.4.2 数据接收

刚才是数据发送所进行的全过程，接下来是数据接收回来一步一步解封装

1. 数据到达接收方的网卡。网卡就会把光信号还原成二进制，随后把二进制数据交给上层数据链路层。

补充一下：不同的网络连接方式，数据链路层使用的协议和帧格式也可能不同

网线/光线来的数据， 数据链路层 -> 以太网

WiFi 来的数据，数据链路层 -> IEEE 802.11 协议

1. 数据链路层按照以太网协议进行解析。把报头和报尾取出来，剩下的载荷往上传递给网络层。以太网的帧头中就有专门的属性，描述了网络层使用哪个协议

1. 网络层拿到这个数据之后，按照 IP 协议的格式解析：再把载荷数据交给传输层。IP 报头中也有专门的属性，描述了传输层使用哪个协议

1. 传输层拿到数据之后，也是类似，按照 TCP 协议来解析。取出载荷，交给应用层。传输层的报头中，通过目的端口号，告知我们数据交给哪个应用程序

QQ 应用程序解析应用层数据，拿到关键信息，展示到界面上，给出提示~不同的应用程序，自然使用不同的应用层协议来解析~

传输的中间过程中，也是涉及到封装分用的。

交换机 只需要封装分用到数据链路层即可

交换机是工作在数据链路层（二层转发）

主机的数据 -> 交换机。交换机收到之后，物理层解析，然后数据链路层解析（没有网络层）~ 重新构造出新的以太网数据帧发送给下一个设备。

数据链路层中，得到以太网数据帧的帧头，信息就足以支持交换机进行下一步工作

路由器是工作在网络层（三层转发）

主机的数据 -> 路由器。物理层，数据链路层，网络层解析（没有传输层），重新构造出新的网络数据包。构造出以太网数据帧，构造出二进制数据，再进行转发

1.1 多线程下使用 ArrayList

前面我们对 count++这样的共享变量使用 synchronized 来保护，如果面对的是这样：

List<String> names = new ArrayList<>();

显然如果是在多线程，就不能直接调用 add()了。毕竟本身ArrayList也不负责同步。在多个线程同时访问下，并且至少有一个线程修改集合结构时，还需要另外的同步措施。否则就会出现结果不正确，遍历的时候也可能遇到并发修改问题。

下面是介绍三种在多线程下使用 ArrayList 方法

自己使用同步机制（synchronized 或者 ReentrantLock）

所有访问都遵守同一规则

List<String> names = new ArrayList<>();
Object lock = new Object();

synchronized (lock) {
    names.add("张三");
}

synchronized (lock) {
    for (String name : names) {
        System.out.println(name);
    }
}

之所以读的时候也要用同一把锁，是因为如果一个线程正在遍历，另一个线程却同时修改，遍历过程就可能受到干扰。

所以此处的关键就是“同一个集合、同一把锁”。如果添加时锁lockA，遍历时锁 lockB，两个线程仍然可能同时操作集合；这两把锁不会替彼此协调。

自己加锁能用，但项目里每个访问位置都要守规矩，漏掉一处，前面的保护就可能失效~

Collections.synchronizedList()包装

给原集合套一层同步包装

List<String> names =
        Collections.synchronizedList(new ArrayList<>());

names.add("张三");
names.add("李四");

可以理解为，原来的ArrayList外面加了一层“门卫”。调用包装后的name.add()等方法时，由包装对象去负责同步。

创建时就包装的原因，是因为后续代码应该统一返回的names访问集合。如果有人绕过包装对象，直接去操作原始ArrayList，这层同步就管不到他了。

注意：遍历仍需要自己在包装对象上加锁

synchronized (names) {
    for (String name : names) {
        System.out.println(name);
    }
}

但问题是，都说是线程安全的包装了，为什么遍历还要加锁？在学到这里的时候我也很困惑

主要是因为，遍历不是一次调用，耳熟“取得迭代器、检查有没有下一个，读取下一个......”的一连串动作。包装类能同步单次方法调用，却不能自动保证整个遍历期间没有其他线程插入修改。所以在官方文档中明确要求了并发遍历时，在返回的集合对象上手动同步~

这部分我就不再详细解释了，可以复制这部分问 AI 给出详细答案~

CopyOnWriteArrayList写入时复制

这个方法叫写时复制

List<String> names = new CopyOnWriteArrayList<>();

names.add("张三");
names.add("李四");

举个例子：

假设大家都在阅读一份名单，此时有人要修改名单：

• synchronized的思路更像，修改和阅读要协调使用同一份名单。
• CopyOnWriteArrayList的思路则是，写入时制作一份新的底层数组，在新数组上完成修改，再让后续读取使用新版本；已经开始的遍历继续看它原来的版本。

这样的目的是为了让读者遍历时不必因写入而打断当前遍历。代价则是每次写入都要复制底层数组，集合大、写入频繁时成本会高，官方文档也把它定位在遍历远多于修改的场景。

// 用代码观察“旧遍历看到的旧版本”：
CopyOnWriteArrayList<String> names = new CopyOnWriteArrayList<>();
names.add("张三");

Iterator<String> iterator = names.iterator();
names.add("李四");
while (iterator.hasNext()) {
    System.out.println(iterator.next());
}
System.out.println(names);

这段代码里，iterator是添加“李四”之前创建的，所以它遍历的是当时的快照，只打印“张三”；最后直接打印当前names，则能看到“张三”和“李四”。

注意“新写的数据不能第一时间读取到”，是已经创建的旧的迭代器不会看到后续修改；并不是说以后重新读取集合，也一直看不到新数据。

再补充一个例子：

假设当前底层数组是，[1, 2, 3, 4]

此时一个线程正在读取这个数组，而另一个线程准备修改数据，例如把 1 修改成 100。

CopyOnWriteArrayList 并不会直接在原来的数组上修改，而是先复制出一份新的数组，再在新数组上完成修改

也就是，复制和修改新数组的这段时间里，旧数组并不会发生变化。因此此时其他正在读取的线程仍然可以继续读取旧版本的数据，并不会因为写线程正在复制、修改而被阻塞。

等新的数组复制、修改完成之后，CopyOnWriteArrayList才会把自己内部保存的数组引用切换到新数组。

实际实现中，CopyOnWriteArrayList保存底层数组的引用具有相应的内存可见性保证，因此新数组准备完成以后再发布出去。这样读线程看到的要么是完整的旧版本，要么是完整的新版本，而不是一个“修改了一半”的中间状态。

不过，这里要区分一下两种“读取”：

• 普通读取在新数组发布以后，后续就可以读取到新数据
• 但是已经创建好的迭代器比较特殊，他会一直持有创建那一刻的数组快照~

很明显，上面的方案也有缺点：

1. 数组特别大时，非常低效
2. 如果多个线程同时修改，也容易出问题

只能适用于特定场景，比如服务器进行重新加载配置的时候......

我导出了一份对比：

综上，集合的“线程安全”，看add()会不会冲突，还要看遍历、复合操作，以及读写同时发生时应当看到哪个版本。

1.2 多线程下使用队列

（该小节利用 AI 进行整理）

现在把共享资源换成队列

举个例子：

假设一家奶茶店，前台负责接单，后厨负责制作。前台接到订单以后，会先把订单放到等待区，后厨再从等待区取出订单进行处理。

这里的等待区，就可以理解为一个队列：

• 生产者：负责往队列里放入任务，比如前台提交订单。
• 消费者：负责从队列里取出任务，比如后厨取走订单。

但问题是，如果没有订单，后厨怎么办？如果等待区已经满了，前台还能继续放吗？

这就需要用到阻塞队列，Java 中对应的接口是：

BlockingQueue<E>

不仅负责线程安全地存取元素，还提供了条件不满足时等待的操作：

queue.put(task);    // 放入元素，没有空位时等待
Task task = queue.take(); // 取出元素，没有元素时等待

注意，阻塞的是调用方法的那个线程。比如消费者在等订单，生产者仍然可以提交订单；有了订单以后，消费者才有机会继续执行。

不过，阻塞队列也不是所有方法都会等待，这里可以先做一个区分：

所以具体是等待还是直接返回，要看调用的方法，而不能只看它是不是“阻塞队列”~

下面介绍三种队列。

ArrayBlockingQueue

这个名字可以拆开理解：

Array：底层使用数组。

BlockingQueue：支持阻塞操作的队列。

BlockingQueue<String> orders =
        new ArrayBlockingQueue<>(2);

这里的 2 表示，队列里最多存放两个元素。

它属于有界队列，创建时必须指定容量，而且创建以后容量就固定了，不会像 ArrayList 一样自动扩容。元素按照先进先出的顺序取出。

举个例子：

假设奶茶店的等待区只能放两张订单：

orders.put("订单1");
orders.put("订单2");

boolean success = orders.offer("订单3");
System.out.println(success); // false

前两次 put() 可以成功，因为队列还有空位。

但第三张订单放不进去，所以这里的 offer() 返回 false。之所以使用 offer()，是为了观察“队列满了”的结果，同时让当前线程还能继续往下执行。

如果改成：

orders.put("订单3");

当前线程就会等待，直到其他线程取走一个元素，腾出空位。

再补充一个例子：

接着前面的队列，先取走一张订单，再放入第三张：

String firstOrder = orders.take();
System.out.println(firstOrder); // 订单1

orders.put("订单3");

System.out.println(orders.take()); // 订单2
System.out.println(orders.take()); // 订单3

之所以先取出“订单1”，是因为它最早进入队列。取出以后，队列空出一个位置，“订单3”才能放进去。

不过，这里要区分一下：

队列容量限制的是队列中等待的元素数量，不是线程数量，也不是所有未完成任务的数量。

比如后厨取走“订单1”以后，虽然还没制作完成，但这张订单已经离开队列了，因此队列可以接收新的订单。

另外，上面的 put()、take() 需要处理或者声明 InterruptedException。练习时可以把代码放在声明了该异常的 main() 中：

public static void main(String[] args)
        throws InterruptedException {
    // 示例代码
}

因为等待期间可能被中断，所以这两个方法要求我们考虑这种情况。

LinkedBlockingQueue

和前面的数组队列相比，LinkedBlockingQueue 底层使用的是链表节点，同样按照先进先出的顺序取出元素。

它也可以指定容量：

BlockingQueue<String> orders =
        new LinkedBlockingQueue<>(100);

这里表示，队列最多存放一百张订单。达到容量以后，再调用 put()，生产者就需要等待。

不过，它还可以这样创建：

BlockingQueue<String> orders =
        new LinkedBlockingQueue<>();

没有传入容量，那是不是就能无限存放元素了？

显然不是。不指定容量时，默认容量是 Integer.MAX_VALUE，也就是 2147483647。

所以不能简单理解为“链表可以不断增加节点，队列就永远不会满”。

举个例子：

假设前台每秒接一百张订单，但后厨每秒只能完成十张。如果一直按照这个速度运行，等待区中的订单就会越积越多。

没有设置合适的容量上限时，程序可能持续接收任务，直到积压的数据占用大量内存。

因此，创建时指定容量的意义，不只是决定能放多少元素，也是为了让生产者在积压达到上限时先等待，给消费者处理任务的时间。

它的基本使用方式和前面一样：

BlockingQueue<String> orders =
        new LinkedBlockingQueue<>(2);

orders.put("订单1");
orders.put("订单2");

System.out.println(orders.take()); // 订单1
System.out.println(orders.take()); // 订单2

可以发现，换成链表实现以后，生产者和消费者仍然通过 put()、take() 配合，不需要重新写一套等待与通知逻辑~

PriorityBlockingQueue

按优先级取出的阻塞队列

前面两种队列都是先进先出，但有些场景并不适合只按进入顺序处理。

举个例子：

医院接诊时，普通患者虽然来得早，但后来送来的急救患者，可能需要优先处理。

这时就需要：

PriorityBlockingQueue

它会根据元素的自然顺序或者我们提供的比较器，决定下一次取出哪个元素。

先用整数观察：

BlockingQueue<Integer> queue =
        new PriorityBlockingQueue<>();

queue.put(30);
queue.put(10);
queue.put(20);

System.out.println(queue.take()); // 10
System.out.println(queue.take()); // 20
System.out.println(queue.take()); // 30

明明 30 先放进去，为什么却先取出 10？

因为对于 Integer，默认的自然顺序是从小到大。因此这里先取出最小的元素，而不是最早进入队列的元素。

所以，“优先级高”并不一定表示数字大，具体含义要由排序规则决定。

如果希望数字越大越先取出，可以提供一个比较器：

BlockingQueue<Integer> queue =
        new PriorityBlockingQueue<>(
                10,
                new Comparator<Integer>() {
                    @Override
                    public int compare(Integer a, Integer b) {
                        return Integer.compare(b, a);
                    }
                }
        );

这里把比较顺序反过来，因此放入 30、10、20 后，取出顺序就是 30、20、10。

不过，构造方法中的 10 要特别注意：

它表示初始容量，不是最多只能存放十个元素。

PriorityBlockingQueue 是逻辑上的无界队列，可以扩容。放入元素时，不会因为达到某个固定容量上限而等待，但仍然受到实际内存的限制；队列为空时，调用 take() 则会等待。

再补充一个容易混淆的地方：

假设消费者已经取走一个普通任务，正在执行。此时又放入了一个紧急任务，队列并不会把正在执行的任务强行中断。

优先级影响的是下一次从队列中取出哪个任务，并不代表可以抢占已经开始执行的任务。

另外，观察优先顺序时，应该看连续调用 take() 或 poll() 的结果。直接使用 for-each 遍历，不保证按照优先级顺序输出；相同优先级的元素，也不保证按照进入顺序取出。

我整理了一份对比：

1.3 多线程下使用哈希表

首先需要知道 HashMap 本身不是线程安全的

而在多线程环境下使用哈希表可以使用：

• Hashtable
• ConcurrentHashMap

我们已经讨论过多线程下使用数组、队列，那么现在就轮到哈希表了。

首先，我给一个使用环境，比如我们想统计每篇博客的访问次数：

map.put("Java多线程", 100);
map.put("MySQL事务", 200);

如果是只有一个线程操作，问题不大。但如果是在服务器里，多个用户同时访问，就有可能多个线程同时操作这张哈希表。

这部分我打算主要介绍这两个类：Hashtable和ConcurrentHashMap

HashMap 不负责线程同步

先来回忆一下哈希表，往 HashMap 里放一个键值对，不只是简单地给变量赋值，就像这样map.put("张三", 90)

内部还需要有这几步：

1. 根据 key 的哈希值，确定放在哪个桶
2. 查看桶里有没有已有的元素
3. 判断是新增键值对，还是替换已有值
4. 必要时调整结构、更新数量，甚至扩容

如果是两个线程同时修改这些内部数据，而且还没有同步措施，就可能相互干扰~

所以必须先强调：HashMap 本身不是线程安全的。

多个线程共享它，并且存在并发修改时，需要额外的同步措施，Java 文档也明确了这一点。

最直接的办法是，像前面提到的ArrayList一样

Map<String, Integer> scores = new HashMap<>();
Object locker = new Object();

synchronized (locker) {
    scores.put("张三", 90);
}

synchronized (locker) {
    Integer score = scores.get("张三");
}

注意，需要协调的访问，都遵循同一把锁的规则。由于每次操作都需要自己写同步代码，所以 Java 就提供了接下来要说到的现成的同步实现。

Hashtable把关键方法加锁

使用的方式还是比较熟悉的

Map<String, Integer> scores = new Hashtable<>();
scores.put("张三", 90);
scores.put("李四", 85);
System.out.println(scores.get("张三"));

其基本思路可以理解为，给get()、put()、remove()等关键方法加上synchronized.

这些实例方法加锁，锁的是当前 Hashtable 对象。

所以多线程调用同一个对象的这些方法，竞争的是同一把锁。Hashtable 是一个提供同步的 Map 实现。

当你点入标准库中的 Hashtable 你会发现，它的大部分方法就是在前面加上了synchronized，没错就是硬上锁。所以它的结构就如同下面这样：

一个Hashtable只有一把锁，两个线程访问Hashtable中的任意数据都会出现锁竞争。

另外，一旦触发扩容，该线程就会完成整个扩容过程，这个过程涉及到大量的元素拷贝，效率会非常低。

所以就引出了ConcurrentHashMap

ConcurrentHashMap缩小需要互斥的范围

使用方法还是类似：

ConcurrentHashMap<String, Integer> scores =
        new ConcurrentHashMap<>();

scores.put("张三", 90);
scores.put("李四", 85);
System.out.println(scores.get("张三"));

它在设计时就考虑了多线程并发访问。

由于上面的Hashtable采用的是整体置锁，因此ConcurrentHashMap采用另外的方式进行置锁以保证减少锁竞争问题，达到效率的提高。

我们知道，在哈希表中，底层那个数组中，每一个位置都可以视为桶，也就是说一个哈希表有许多桶组成（如果忘记这点 可以看看 JavaSE 篇中的内容）

ConcurrentHashMap要解决的就是，在我们操作哈希表时，减少其中的锁竞争。

我们知道，针对不一样的 key 可能会落入不同的哈希桶中，当然也有可能落入同一个桶中。

假设现在：

• A 修改桶 0 中的数据。
• B 修改桶 1 中的数据。

既然它们修改的主要结构互不相同，就可以尽量允许它们并发执行。

• C 修改桶 2 中的王五。
• D 修改桶 2 中的赵六。

虽然 key 不同，但它们操作的是同一个桶，就可能需要互斥。

于是乎，在 Java5~Java7 阶段ConcurrentHashMap使用了分段锁的思想，缩小了锁保护的范围，降低了不同操作争抢同一把锁的概率。

它主要协调的是不同的桶之间的关系，你不能记成 key 不同，就一定不会产生锁竞争；更准确的是，落在不同的桶里的修改，通常更有机会并发执行。

再说明一下分段锁：

也就是说在 Java5~Java7 阶段，一开始是多个桶放一把锁。用官方的描述是“多个桶被划分到一个 Segment 中，一个 Segment 对应一把锁。”

这还是比较好理解的，就比如锁 1 被分配在桶 1,2,3,4,5,6 ，然后锁 2 被分配在桶 7,8,9,10,11......以此类推

OpenJDK 7 的源码注释直接写明，哈希表被划分为多个 Segment，每个 Segment 自己又是一个哈希表。（具体参考论述可以追踪到OpenJDK7）

但上述问题是，锁粒度还是有些大，就比如桶 1 与桶 2 之间还会有可能存在锁竞争。

于是在 Java8ConcurrentHashMap 做了一次非常大的重构，直接取消了 Segment 作为主要并发结构。而变成Node<K,V>[] table，结构更像普通的HashMap。也就是将锁粒度缩小到桶级别，并将桶的头节点作为synchronized的锁对象。

在 Java8 中是能不用锁尽量不用锁。

源码中还专门提及过“向空桶插入第一个节点时直接通过 CAS 完成。”

对了，读操作get()没有加锁，配合volatile保证了可见性。

另外再强调一个地方，就是关于扩容部分的优化：

对于 ConcurrentHashMap，可以这样理解，把迁移工作拆成若干段，允许多个线程领取不同的部分，协作完成迁移。

扩容过程中，新旧数组会暂时同时存在。

但并不是每次查询都把两张表完整查一遍。

关键在于，某个旧桶迁移完成以后，会留下一个转发节点，告诉后续操作去新表找。

关于迁移要注意这几个点

• 并不是每个访问线程都会参与搬迁。 例如，get() 可以根据转发节点去新表查找，不负责帮助迁移。
• 并不是每个线程只搬固定几个元素就结束。 迁移按桶区间分配，参与线程可能完成多批工作。
• 扩容期间，插入也不是一律只操作新表。 尚未迁移的桶仍可能在旧表处理；遇到已迁移的桶，才转向新表。

全部迁移完成以后，当前表切换为新表。旧数组在不再被引用后，由垃圾回收处理。

（重点）ConcurrentHashMap对HashMap的核心优化点：

1. 把锁整个表 -> 锁桶，以及读操作不加锁
2. 充分利用 CAS 特性，针对 size 属性通过 CAS 更新，避免出现重量级锁
3. 优化扩容方式以及化整为零（把 锁整个表 → 锁桶 就是锁粒度的化整为零）

CAS 前面其实在说synchronized就已经就接触到这个词了。

但那会只是简单的解释了一下：

线程可以通过 CAS 去尝试修改锁状态，如果成功就说明拿到锁；失败就说明有人竞争，再继续自旋；

这里我再具体说明一下：CAS 全称 Compare and swap，字面意思“比较并交换”。

CAS 操作可以拆成三个值，有如下：

V：内存中的原始值

A：线程认为它是旧值，也叫预期值

B：线程想写入的新值

而 CAS 要做的事情就是，只有 V 任然等于 A，才把 V 改成 B；否则不修改，并告诉线程这次失败了。

这段写的代码不是原子的，真实的 CAS 是一个原子的硬件指令完成的，这个伪代码只是辅助理解 CAS 的工作流程

boolean CAS(address, expectValue, swapValue) {
    if (&address == expectValue) {
        &address = swapValue;
        return true;
    }
    return false;
}

比如共享变量最初是 10。线程想执行 CAS(原始值 10, 预期值 10, 新值 11)：

• 如果执行 CAS 时变量仍是 10，修改成功，变量变成 11。
• 如果另一个线程已经把预期值改成 11，预期值对不上，修改失败，变量保持原值。

还可以这么理解，你正在修改在线文档，你开始编辑时看到的是第 10 版，提交时系统先确认他是否仍为第 10 版；如果别人已经提交了第 11 版，就不能直接用你的旧内容覆盖它。

实际代码中的 if 不具备原子性，上面的已经说过只是伪代码辅助理解 CAS，实际的 if 会可能存在之前说的内存可见性问题，这里我就不再展开解释了~

CAS 其实和前面的乐观策略是有一定联系：

CAS 会先按照刚才读到的值长尝试修改，如果期间没人改它，那么就会成功；如果有人先改了，它再重新取，重新计算。

也就是失败的 CAS 不会接着完成，而是会在失败后再重试；

1.1 CAS 实现原子类

前面的典型操作，count++线程不安全，就需要加锁来解决问题。但是又认为，加锁效率比较低，于是就可以通过 CAS 来实现 count++，这样能确保性能，又同时保证线程安全~

标准库中提供了java.util.concurrent.atomic包，里面的类都是基于这种方式来实现的。典型的就是AtomicInteger类，其中的getAndIncrement相当于 i++操作；

实际只想给计数器加 1 时，直接使用原子类即可：

AtomicInteger count = new AtomicInteger(0);
// 相当于 i++
int oldValue = count.getAndIncrement();

伪代码实现：

// 原理伪代码，不是可直接运行的 AtomicInteger 源码
class AtomicInteger {
    private int value;

    public int getAndIncrement() {
        int oldValue = value;

        while (CAS(value, oldValue, oldValue + 1) != true) {
            oldValue = value;
        }

        return oldValue;
    }
}

假设 value 一开始是 0，我们按顺序看：

1. oldValue = value：先记下当前值 0。因为稍后要根据它计算新值，还要把这个旧值返回给调用者。
2. CAS(value, oldValue, oldValue + 1)：尝试确认共享值是否仍为 oldValue。如果仍是 0，就原子地改成 1，本次操作成功。
3. 如果 CAS 失败，就执行 oldValue = value，重新读取共享值。因为其他线程可能已经把它改了，原来的 oldValue + 1 也就不再是这次应该写入的结果。
4. 循环直到 CAS 成功，最后 return oldValue。返回的是这次成功加一之前的值，不是加一后的值。
   比如 A、B 都读到 0，A 先通过 CAS 把值改成 1。B 再拿“预期是 0”去尝试，就会失败。B 重新读到 1，下一轮尝试把 1 改成 2。如果成功，B 返回 1；最终共享值是 2。

注意：代码里的 CAS(value, …) 是为了说明原理。普通 Java 方法接收一个 int 参数，不能仅靠这个参数原子地修改外部字段；这段也不能当作 JDK AtomicInteger 的实际源码来运行。写程序时直接使用标准库的 AtomicInteger.getAndIncrement() 即可。

1.2 用 CAS 实现自旋锁

前面学习过的自旋锁是指，线程暂时拿不到锁，就先不进入等待状态，而是在原地反复尝试。

但问题是：两个线程都看见“锁没人持有”，又怎能保证只有一个线程拿到

假设用 owner 记录锁的持有者：

• owner == null：目前没人持有
• owner == 当前线程：当前线程拿到了锁

线程 A 和 B 同时来时，都想把owner从null改成自己。这里不然能用普通的“先判断，再赋值”，因为两人可能都判断为null。于是用 CAS：

owner.compareAndSet(null, 当前线程)

意思是，只有owner此刻仍然是null，才原子地把它改成当前线程。

假设 A 先成功，owner 就变成 A；B 再尝试时，发现它已经不是 null，因此失败。B 可以继续循环，等待 A 释放后再试。这就是 CAS 实现自旋锁的核心。Java 的 AtomicReference.compareAndSet() 正好提供对对象引用的这种操作。

下面是一段伪代码：

public class SpinLock {
    private Thread owner = null;

    public void lock(){
        // 通过 CAS 看当前锁是否被某个线程持有。
        // 如果这个锁已经被别的线程持有，那么就自旋等待。
        // 如果这个锁没有被别的线程持有，那么就把 owner 设置为当前尝试加锁的线程。
        while(!CAS(this.owner, null, Thread.currentThread())){

        }
    }

    public void unlock (){
        this.owner = null;
    }
}

加锁操作中，就需要判定，锁是否被人占用；如果未被人占用，就把当前线程的引用设置到 owner 中；如果已经被人占用，就自旋等待。

由于循环体是空着的，整个循环速度非常快（忙等），但是一旦其他线程释放了锁，此时此刻线程就能第一时间拿到这里的锁。

1.3 CAS 的 ABA 问题

刚刚一直在判断，“当前值和我先前读到的值，是否相等”

但是“相等”并不能证明“中间从未被别人修改过”

这就像是你去买手机买电脑可能买到“翻新机、二手机”一样，经过翻新之后，机器外观看起来就和新机完全一样，实际上里面早就是不一样了~

CAS 中的 ABA 问题其实大部分情况下，即使出现了 ABA，最终的程序其实一般问题也不大。只有一些极端场景，ABA 问题才会产生一些严重 BUG

就比如取银行取钱：

假设账户里原本有 100 元，线程 1 和线程 2 都读取到了这个值，并且都准备把余额从 100 修改成 50。正常情况下，线程 1 先执行成功，把余额改成 50；等线程 2 再执行时，发现当前值已经不是自己之前读取的 100 了，所以 CAS 失败，这是我们期望的结果。

但是如果在线程 2 执行之前，又有其他操作把账户余额从 50 重新改回了 100，那么线程 2 再进行 CAS 时，会发现：

之前读取的值：100

当前的值：100

从数值上看没有发生变化，于是 CAS 会认为这个数据没有被修改过，并继续执行扣款。

但实际上余额已经经历了：

100 → 50 → 100

ABA 问题解决

ABA 问题产生的原因，是 CAS 只会比较“当前值”和“之前读取到的值”是否相同，却无法判断这个值在中间有没有被修改过。

所以要解决 ABA 问题的常见思路，就是在原来的数据之外，再额外增加一个版本号。每次读取数据时，不仅要读取当前值，还要记录他对应的版本号；真正执行 CAS 时，也要同时比较数据和版本号。

比如账户余额一开始是 100 元，版本号是 1。线程 1 和线程 2 都读取到了“余额 100，版本号 1”。

随后线程 1 先执行扣款，把余额从 100 修改成 50，同时版本号从 1 增加到 2。之后又有人向这个账户转入 50 元，余额重新变回 100，但版本号会继续增加到 3。

这时候线程 2 再执行 CAS。虽然它之前读取到的余额是 100，而现在的余额也正好是 100，看起来数据没有发生变化，但线程 2 保存的版本号还是 1，而当前版本号已经变成了 3

因此版本号比较失败，这次 CAS 也就不会成功。

这样的话，即使数据经历了“100 → 50 → 100”，最终又回到了原来的值，我们仍然可以通过版本号发现，这个数据中间其实已经被修改过了。

所以，解决 ABA 问题的核心可以简单理解为：

普通 CAS 只比较值，而解决 ABA 问题后，需要同时比较“值 + 版本号”。

Java 中提供了AtomicStampedReference<E>来实现这种思路，其中保存的数据可以理解为实际值，而stamp就相当于这个值对应的版本号。每次成功修改数据时，同时更新版本号，这样就可以判断数据在这期间是否发生过变化~

对应出现的相关面试题可能就会这样出：

1. 讲解一下你自己理解的 CAS 机制

全称 Compare and Swap，即“比较并交换”。相当于通过一个原子的操作，同时完成“读取内存，比较是否相等，修改内存”这三个步骤，本质上需要 CPU 指令的支撑

1. ABA 问题如何解决

给要修改的数据引入版本号。在 CAS 比较数据当前值和旧值的同时，也要比较版本号是否符合预期。如果发现当前版本号和之前读到的版本号一致，就真正执行修改操作，并让版本号自增；如果发现当前版本号比之前读到的版本号大，就认为操作失败

2.JUC 的常见类

JUC 是指java.util.concurrent及其相关包。其实前面用过的AtomiciInteger就属于 JUC；我就从里面两个主要的类讲一讲~

2.1 Callable 接口

在前面创建线程的时候，经常是将 Runnable 实例出一个 task 交给线程去执行。

Runnable task = new Runnable() {
    @Override
    public void run() {
        // 执行任务
    }
};

Thread t = new Thread(task);
t.start();

如果任务只是打印一句话，Runnable就很合适。但问题是，如果子线程负责计算 1 到 1000 的和，主线程只能通过创建成员变量最后赋值才能拿到。

public class Demo {
    public static int total = 0;
    public static void main(String[] args) throws InterruptedException {
        Runnable task = () -> {
            int sum = 0;
            for (int i = 0; i <= 1000; i++) {
                sum += i;
            }
            total = sum;
        };
        Thread t = new Thread(task);
        t.start();
        t.join();
        System.out.println("total = " + total);
    }
}

但如果子线程有很多的话，还得自己管理结果存放、等待条件和线程通知，代码会很繁琐。

所以 JUC 就提供了 Callable<V> 这样一个更贴合这类任务的接口；

Callable 是一个 interface。Callable<V>描述“执行完后会产生一个 V类型结果”的任务，相当于把线程封装了一个“返回值”。方便给程序猿借助多线程的方式计算结果。

用Callable去完成上面一个计数代码是实现如下：

public class Demo {
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        Callable<Integer> callable = new Callable<Integer>() {
            @Override
            public Integer call() throws Exception {
                int result = 0;
                for (int i = 0; i <= 1000; i++) {
                    result += i;
                }
                return result;
            }
        };
        FutureTask<Integer> futureTask = new FutureTask<>(callable);
        Thread t = new Thread(futureTask);
        t.start();
        System.out.println(futureTask.get());
    }
}

Callable 接口和 Runnable 接口是并列关系；Callable<V> 是要重写一个 V call()方法，而Runnable是要重写一个void run()方法。

使用Callable要注意，上面的代码有三个重要角色，

Callable<Integer>描述要做的计算，以及返回什么结果、

FutureTask<Integer>包装任务，记录它是否完成，并保存结果、

Thread真正安排新线程执行任务。

Thread 本身不提供获取结果的方法，所以就需要凭 FutureTask 对象来拿到结果。至于为什么 Thread 不能直接接收 Callable 对象，则是因为需要解耦合。

Thread 就是线程，要和任务这个概念能剥离开。线程不需要关心任务是啥样的任务（是否有返回值）。

再补充一下上述关于futureTask.get()部分：

拿买麻辣烫举例。

• Callable：交给后厨的制作任务。
• 工作线程：做餐的厨师。
• FutureTask：你拿到的取餐票。
• get()：拿着票取餐。

你拿到取餐票时，麻辣烫可能还没做好。因此调用 get() 时：

• 任务已经完成：直接取到结果。
• 任务还没完成：当前调用 get() 的线程等待，直到有结果。

这里等待的是调用 get() 的主线程；负责计算的子线程仍在工作。get() 也只是等待并取结果，不会替你启动任务。所以如果忘了 thread.start()，却直接调用 get()，主线程就可能一直等下去。

还有一种情况：子线程在 call() 中计算失败、抛出异常。主线程调用 get() 时不会得到正常结果，而会收到 ExecutionException；如果主线程在等待期间被中断，则会收到 InterruptedException。

同时，上面也补充了一个之前没学习到的线程创建方法，通过传入Callable对象。这里再总结一下：

1. 继承 Thread（定义单独的类/匿名内部类）
2. 实现 Runnable（定义单独的类/匿名内部类）
3. lambda
4. 实现 Callable（定义单独的类/匿名内部类）
5. 线程池，ThreadFactory

2.2 ReentrantLock

ReentrantLock 即可重入互斥锁，是更经典风格的锁，与 synchronized 是并列关系。都是用来实现互斥效果，保证线程安全。

ReentrantLock 提供了三个方法：

• lock()：加锁，如果获取不到锁就死等。
• unlock()：解锁。
• unlock(超时时间)：加锁，如果获取不到锁，等待一定的时间之后就放弃加锁。

它的基本加锁和解锁使用方式就像这样

import java.util.concurrent.locks.ReentrantLock;

class Counter {
    private final ReentrantLock lock = new ReentrantLock();
    private int count = 0;

    public void increment() {
        lock.lock();
        try {
            count++;
        } finally {
            lock.unlock();
        }
    }
}

• lock.lock()：尝试取得锁。如果被其他线程持有，就等待取得它。只有 lock() 成功返回，才应进入负责释放这把锁的代码。
• try：执行需要保护的 count++。
• finally：无论代码正常结束还是抛出异常，都调用 unlock()。

trylock()这个方法的话，就是抢不到就先不等。

他不会阻塞，加锁成功返回 true，加锁失败返回 false。调用者判定返回值，决定接下来需要做什么~

它还可以设置超时时间，等待时间达到超时时间再返回 true/false

import java.util.concurrent.TimeUnit;

if (lock.tryLock(1, TimeUnit.SECONDS)) {
    try {
        count++;
    } finally {
        lock.unlock();
    }
} else {
    System.out.println("等了最多一秒，仍没拿到锁");
}

你可以想下面这样理解：

使用一间会议室

• lock()：会议室有人，就等到空出来。
• tryLock()：看一眼，有人就马上离开。
• 限时 tryLock()：等一会儿，过了约定时间就改变安排。

但现在 synchronized 优化做的越来越好，优先还是使用 synchronized

这里的重点是 synchronized 和 ReentrantLock 之间区别：

1. synchronized 是关键字（内部是 JVM 通过 C++实现的），ReentrantLock 则是标准库的类（完全由 Java 编写的）
2. synchronized 通过代码块控制加锁解锁，ReentrantLock 需要 lock/unlock 方法，需要注意 unlock 不被调用的问题
3. ReentrantLock 除了提供 lock，unlock 之外还提供了一个方法 tryLock()
4. ReentrantLock 提供了公平锁的实现（默认是非公平的）
5. ReentrantLock 搭配的等待通知机制，是 Condition 类，相比 wait notify 来说功能更强大一些

2.3 信号量 Semaphore

前面了解到synchronized和ReentrantLock通常是在描述：同一时刻只允许一个线程进入。

而信号量就是为了同一时刻，管理多份资源的工具。

信号量，用来表示“可用资源的个数”，本质上就是一个计数器，你可以这样理解；

Semaphore parking = new Semaphore(4);

这里的 4 表示的是一开始有 4 个表示可用许可，也可以理解为停车位：

我称其为“许可”，是因为Semaphore只管理可用数量，并不真的创建停车位对象。Java 文档也是按“取得一个许可，归还一个许可”来描述它的。

可以参考一下Oracle官方文档

2.3.1 acquire()申请资源

Semaphore提供的其中一个方法，acquire()就是会先申请许可，再使用资源。在车进入停车场前，会先调用

parking.acquire();

其含义就是，我要申请一个许可，拿到了，才能往下执行。

如果还有许可，可用数量减一，线程继续执行。如果许可已经用完，线程就等待，直到有其他线程归还许可；等待期间也可能因中断而抛出 InterruptedException。

所以说也可以称其为 P 操作。

信号量的一个特殊情况：初始值为 1 的信号量，取值要么是 1 要么是 0（二元信号量）。这就等价于“锁”

public class Demo {
    public static void main(String[] args) throws InterruptedException {
        // 指定可用资源的个数是 "4"
        Semaphore semaphore = new Semaphore(3);
        semaphore.acquire();
        System.out.println("进行一次 P 操作");
        semaphore.acquire();
        System.out.println("进行一次 P 操作");
        semaphore.acquire();
        System.out.println("进行一次 P 操作");
        semaphore.acquire();
        System.out.println("进行一次 P 操作");
    }
}

2.3.2 release()释放资源

在车离开停车场的时候就调用：

parking.release();

可用许可增加一个，正在等待的线程便有机会取得它。这一步也就是所谓的V 操作：归还一个许可，可用数量加一。

注意：Semaphore 不会像 ReentrantLock 那样检查“是不是持有锁的那个线程”，对它来说，调用一次 release()，就只是把当前许可数量加 1。多调用一次 release()，许可数量就可能增加。就比如，原本只打算容纳 4 辆车，但没有申请资源的前提下使用了release()就会变为容纳 5 辆车。

所以代码里必须保证，成功 acquire() 之后才 release()，并且用完一定归还。

示例代码：

public class Demo {
    public static void main(String[] args) {
        Semaphore parking = new Semaphore(4);

        Runnable car = new Runnable() {
            @Override
            public void run() {
                boolean acquired = false;

                try {
                    // 1. 先申请车位
                    parking.acquire();
                    acquired = true;

                    // 2. 拿到车位后，才能进入停车场
                    System.out.println(Thread.currentThread().getName() 
                            + " 进入停车场");

                    Thread.sleep(1000); // 模拟停车 1 秒
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();

                } finally {
                    // 3. 只有确实拿到车位，才归还车位
                    if (acquired) {
                        parking.release();
                        System.out.println(Thread.currentThread().getName() 
                                + " 离开停车场");
                    }
                }
            }
        };
        for (int i = 1; i <= 20; i++) {
            new Thread(car, "车辆" + i).start();
        }
    }
}

2.4 CountDownLatch

在上一节的Semaphore有一个计数器，用来表示，现在还允许多少个线程进入；

CountDownLatch也有计数器，但问题完全不同，它是还有多少件事没完成？等它们全部完成，我才能继续。

就拿跑步举例，还有多少件事没完成？等它们全部完成，我才能继续。

CountDownLatch latch = new CountDownLatch(10);

这里的 10 表示的是还需要收到 10 次完成通知。

每次有一名选手结束比赛就调用latch.countDown()，计数器减 1，然后负责统计的线程调用latch.await()。

如果计数器还不是 0，那么这个线程就的等待；计数器到 0 之后，它才会继续执行。countDown()的调用者不用等其他选手，通知完就可以结束自己的工作。

过程能记为：

此处的计数器表示剩余任务数，不是“还有多少个名额可供使用”。这就是它和Semaphore最根本的区别。

虽然说这 10 个线程也可以分别 join()，但CountDownLatch更直接的地表达需求，“我不关心逐个等待哪条线程；我要等待 10 项任务都发出完成通知”

和信号量哪里可以相反的理解，Semaphore 问的是“现在还能进几个”；CountDownLatch 问的是“还差几个没完成”。

public class Demo{
    public static void main(String[] args) throws InterruptedException {
        // 现在把整个任务拆成 10 个部分. 每个部分视为是一个 "子任务".
        // 可以把这 10 个子任务丢到线程池中, 让线程池执行.
        // 当然也可以安排 10 个独立的线程执行.

        CountDownLatch latch = new CountDownLatch(10);
        ExecutorService executor = Executors.newFixedThreadPool(4);
        for (int i = 0; i < 10; i++) {  // 此处创建任务数要与latch个数相同
            int id = i;
            executor.submit(() -> {
                System.out.println("子任务开始执行: " + id);
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                System.out.println("子任务结束执行: " + id);
                latch.countDown();
            });
        }
        // 这个方法阻塞等待所有的任务结束
        // 此处的 a => all
        latch.await();
        System.out.println("所有任务执行完毕");
        executor.shutdown();
}

对于这一部分可能会出的面试题：

1. 线程同步的方式有哪些？

synchronized、ReentrantLock、Semaphore、原子类等都可以用于线程同步。

1. 为什么有了synchronized还需要 JUC 下的 Lock？

以 JUC 的 ReentrantLock 为例：

• synchronized 使用时不需要手动释放锁；ReentrantLock 使用时需要手动释放锁，使用起来更加灵活。
• synchronized 在申请锁失败时，会一直等待；ReentrantLock 可以通过 tryLock() 的方式尝试获取锁，也可以等待一段时间后放弃。
• synchronized 不提供公平锁机制；ReentrantLock 默认是非公平锁，也可以通过构造方法传入 true 开启公平锁模式。
• synchronized 可以通过 Object 的 wait() / notify() 实现等待与唤醒；ReentrantLock 可以搭配 Condition 实现等待与唤醒，并且能够更加精确地控制不同等待队列中的线程。

1. AtomicInteger 的实现原理是什么？

基于 CAS 机制，伪代码如下：

class AtomicInteger {
    private int value;

    public int getAndIncrement() {
        int oldValue = value;

        while (!CAS(value, oldValue, oldValue + 1)) {
            oldValue = value;
        }

        return oldValue;
    }
}

1. 信号量是什么？一般应用在哪些场景？

信号量，用来表示“可用资源的个数”。本质上就是一个计数器

使用信号量可以实现“共享锁”。比如某个资源允许 3 个线程同时使用，那么就可以使用 P 操作作为加锁，V 操作作为解锁，前三个线程的 P 操作都能顺利返回，后续线程再进行 P 操作就会阻塞等待，直到前面的线程执行了 V 操作。

1. 解释一下 ThreadPoolExecutor 构造方法的参数的含义

参考另一篇“多线程：应用案例”

1.常见锁策略

1.1 乐观锁和悲观锁

不知道你第一次见是不是误以为：一个锁比较开心，另一个锁比较消极；

不过其实描述的主要是：对于“接下来会不会发生线程冲突”

悲观锁：

每次访问共享数据都先假设别人可能会修改，因此线上锁；其他线程如果也需要访问，就只能等待锁释放。

悲观锁的想法比较保守，加锁的时候，预测接下来的锁竞争的情况会非常激烈，就需要针对这样的激烈情况额外做一些工作。

还是继续拿公司举例子，假设财务办公室有一份账本。张三觉得“这个账本这么重要，李四王五说不定随时都会来改，我还是先把门锁上。”

乐观锁：

先假设并发冲突发生的概率不高，在真正提交更新时再检查是否发生冲突。

乐观锁的想法就相反，加锁的时候，预测接下来的锁竞争的情况不激烈，就不需要做额外的工作。

乐观锁和悲观锁的对比就像下面一样说的一样

比如：现在张三和李四想找老师问问题。

张三比较悲观：“老师平时这么忙，我直接过去估计也是白跑。”所以张三就先发消息“老师，你下午两点有空吗？”

老师确认“有空”后，张三才过去~

像上面这样就是悲观锁

李四就比较乐观“老师应该没这么忙吧，我直接过去”。于是李四直接跑办公室，如果老师正好有空，那最好直接把问题解决~

这样就根本没有提前预约产生额外流程。

如果老师正忙，“哦，那算了，我下次再来。”

虽然这次失败了，但他能够识别到“现在发生冲突了”然后重新尝试~

这就是乐观锁的类比

两种策略没有绝对优劣，关键看当前场景。

比如冲突非常频繁，你还一直乐观“失败 再试 失败 又试”，就像知老师每天都忙得要死，你还天天直接跑办公室碰碰运气。最后反而白跑很多次，一直浪费资源~这就比较适合悲观锁了~

反过来，假如有 1000 次操作，可能只有 1 次冲突。如果每一次都申请锁->等待->解锁，这就有点像：老师一年都闲的要死，你每次都为“1+1”等于几之前，还提前三天预约~这种冲突概率很低的场景，就更适合乐观锁策略。

那么乐观锁到底怎么知道“别人改没改”？

这个问题就先埋下来~

而悲观锁其实很好理解：真的把锁拿到手

那乐观锁既然不提前把别人挡住，那它凭什么知道别人有没有改过数据？

一个典型的方案就是版本号~

就比如：当前数据是余额 = 100，version = 1

线程 A 读到：100 / version 1

准备修改为：50

真正提交的时候再看 version 是否等于 1

如果还是version = 1就说明我读取之后没人改过；如果发现version != 1就说明我不在的时候有人动过这份数据~那么本次修改就失败

这其实就是为我后面要说的CAS 埋个伏笔

既然提到锁，就不得不提一下synchronized，synchronized 开始时会倾向使用更乐观、开销较低的策略；如果发现锁竞争逐渐频繁，则会逐步转向更悲观、开销更高的处理方式。

1.2 重量级锁和轻量级锁

从前面我们学习到了，锁的核心目的是保证原子性 / 互斥；

可以先暂时不用深入研究 JVM 和操作系统底层是如何实现锁的，就记住Java 的锁当然不是凭空出现的，它最终还是要依赖 CPU 提供的原子指令以及操作系统提供的线程调度能力。

那么重量级锁和轻量级锁是什么意思？

• 重量级锁

这里提到的重量级，不是说把锁本身“更大”，而是发生锁竞争时，为了实现线程之间的互斥，需要付出的系统开销比较大。

就比如，当一个线程获取不到锁时，可能需要让该线程进入阻塞状态。等到锁被释放以后，又需要将这个线程唤醒，让它重新参与 CPU 调度。

这其中可能涉及到：

1. 用户态与内核态之间的切换
2. 线程阻塞与唤醒
3. 线程上下文切换
4. 操作系统线程调度

这些操作相对于普通的用户态代码来说成本比较高，所以被称为重量级锁。

• 轻量级锁

轻量级锁的思路则是：如果锁竞争并不严重，就尽量不要马上让线程进入阻塞状态，而是在用户态先尝试解决竞争。

就比如：JVM 可以利用 CPU 提供的 CAS 原子指令，或者让线程进行短暂的自旋，尝试获取锁。

整个过程中线程可能并没有真正进入阻塞状态，因此也就避免了比较昂贵的线程阻塞、唤醒和上下文切换。这也就是所说的“轻量级”。

上面提及的用户态 / 内核态指的就是：

用户态：程序自己在用户空间里完成，不需要操作系统直接介入线程的阻塞和唤醒。

内核态：当锁竞争严重、线程需要被阻塞或唤醒时，需要操作系统内核参与线程调度，可能产生用户态与内核态切换以及线程上下文切换。

你可以这么理解用户态和内核态：

假设你去银行，在大厅外面，自己能完成的事情（填表、看号码、整理材料）这些事情自己就能做，这就可以类比为用户态。

但是 有些事情你没有权限自己完成，必须交给拥有更高权限的工作人员，所以只能去柜台，让银行工作人员处理，这就可以类似内核态。

对于上面所说的“重量级锁”和“轻量级锁”，主要区别并不是谁更安全，而是谁的实现成本更高。所以还是那句话：没有哪一种策略永远最好，关键看当前的竞争情况。

1.3 自旋锁和挂起等待锁

我们知道，线程在竞争锁时可能会遇到一种情况：线程 A 已经持有锁，线程 B 尝试获取锁但失败了。对于线程 B 通常会有两种不同的处理思路：

1. 继续占用 CPU，不断尝试获取锁 -> 自旋等待
2. 暂时放弃 CPU，进入阻塞等待状态 -> 挂起等待

这也就是我这一节要说的自旋锁和挂起等待锁~

自旋锁：

刚刚说到的第一种思路就是自旋锁（继续占用 CPU，不断尝试获取锁）

按照传统的处理方式，如果线程获取锁失败，可以直接进入阻塞状态，将 CPU 让给其他线程。这样做虽然不会一直浪费 CPU，但是线程阻塞、唤醒以及上下文切换本身也是有成本的。

于是就产生了一个问题：

假设线程 A 虽然正在持有锁，但是它马上就要释放了，如果这时候线程 B 马上进入阻塞，那么阻塞和唤醒线程的成本，可能反而比等待锁释放的时间还长~

所以换一种思路就是先不要马上阻塞线程，让线程继续运行一小段时间，不断尝试获取锁，这就是自旋的含义。

自旋你可以抽象理解为：

while (获取锁失败) {
    // 继续尝试获取锁
}

注意哈，这只是帮助理解的伪代码。

我让 AI 解释了下，实际 JVM 或并发组件中的实现会更加复杂，并不会简单地让线程无条件无限循环。

再补充一下，自旋锁其实是属于一种偏轻量级的等待策略。自旋线程仍然处于运行状态，因此仍然会占用 CPU~

挂起等待锁：

挂起等待锁其实就是另一种思路了：既然暂时获取不到，那我就先不抢了，把 CPU 让出来。

从过程上来看其实就是“我拿不到锁，我先休息，把 CPU 让出来，等锁释放后再唤醒我”

此处所说的“挂起”并不是说 Java 线程永远停止，而是线程暂时进入等待 / 阻塞状态，不再持续占用 CPU 执行。

这里说到的自旋锁和挂起等待锁你可以这样理解一下：

想象一下，去追求一个女神。当男生像女神表白后，女神说：你是个好人，但是我有男朋友了~~

挂起等待锁：陷入沉沦不能自拔......过了很久很久之后，突然女神发消息过来，“要不咱俩试试？”（注意，这个很长时间间隔里，女神可能已经换了好几个男票了）

自旋锁：死皮赖脸坚韧不拔，仍然每天坚持地和女神说早安晚安。一旦女神和上一任分手，那么就能立刻抓住机会上位。

我让 GPT 总结了上面的内容给出了对比表格：

所以上述两种方式没有绝对的好坏，而是适用的场景不同~

其实还是回到了锁竞争的激烈程度：

悲观锁 -> 重量级锁 -> 挂起等待锁

乐观锁 -> 轻量级锁 -> 自旋锁

1.4 公平锁和非公平锁

这一部分其实更好理解些，主要说的是：

如果很多线程都在等同一把锁，那么这把锁到底要不要讲“先来后到”？

假设现在有三个线程，分别是 A，B，C

A 先尝试获取锁，获取成功。然后 B 再尝试获取锁，获取失败，阻塞等待。然后 C 也尝试获取锁，C 也获取失败，也阻塞等待。

那么，当线程 A 释放锁的时候，会有两种情况：

公平锁：遵循“先来后到”，B 比 C 先来，所以当 A 释放锁的时候，B 会先于 C 获取到锁。

非公平锁：不遵循“先来后到”，B 和 C 都有可能获取到锁。

其实你可以认为，非公平锁也能定义为公平，因为锁默认情况下，就相当于“概率均等”，操作系统针对线程的调度是随机的~

操作系统线程调度本身可以看成带有随机性；如果没有额外机制限制，锁通常不会天然保证公平。如果要实现公平，就需要额外的数据结构记录线程到来的先后顺序。

下面这个例子希望更能加深对公平锁和非公平锁的印象~

再补充一句，synchronized 其实是非公平锁，在之前学习 synchronized 的时候就说到，当一个线程释放锁以后，其他等待的线程会重新竞争，并不一定严格按照先来后到。

1.5 可重入锁和不可重入锁

在之前的初阶已经稍微接触过，只是当时是为了说明synchronized不会让线程“自己把自己锁死”。

可重入的意思就是：

同一个线程已经拿到第一把锁以后，还可以再次获取同一把锁。

或者逼入一个递归函数里有加锁操作，递归过程中这个锁会阻塞自己吗？如果不会，那么这个锁就是可重入锁（因为这个原因可重入锁也被称为递归锁）。

就比如下面这样：

public class Demo {
    public synchronized void method1() {
        System.out.println("method1");
        method2();
    }
    public synchronized void method2() {
        System.out.println("method2");
    }
}

Demo demo = new Demo();
demo.method1();

比如我 new 了一个 Demo，调用了 method1，method1 内部又调用了method2，它们同样都是 synchronized；

如果是可重入锁，method2 允许再次进入。

但如果是不可重入锁，method2 就会被拒之门外，然后method1 又无法释放锁。此时就会发生死锁情况。

这样的锁就称为不可重入锁。

synchronized 是可重入锁

1.6 普通互斥锁和读写锁

在多线程环境下，对共享数据的访问通常可以分为两类：读取数据和修改数据

如果只是两个线程同时读取数据，两个线程都不会修改数据，因此一般不会破坏数据的一致性。

但如果一个线程读取数据，一个线程修改数据，这样就可能产生问题；同样，如果是两个线程都在修改数据也必须得保持互斥。

你可以这样认为：

普通互斥锁

普通互斥锁的问题主要是，即使多个线程之间只是读取操作，它们仍然不能同时执行。

就像是之前学习 synchronized 一样：

public synchronized int getData() {
    return data;
}

public synchronized void setData(int data) {
    this.data = data;
}

这样虽然能保证线程安全，但是假设三个线程都执行getData()只是读取数据。但又由于synchronized是互斥的。也就是说即使多个线程之间只是读取操作，他们仍然不能同时执行。

线程安全是保证了，但是并发能力下降了。

所以这时候就产生了一个新的思路：既然读操作不会修改数据，那就允许多个线程同时读取；

读写锁

这就是读写锁由来。

读写锁并不是只有“一把锁”，而是把锁拆为了读锁 （Read Lock） 和 写锁 （Write Lock） 分别对待读取操作和修改操作。

Java 标准库提供了 ReentrantReadWriteLock，它的内部提供了两种锁，分别是读锁类 ReentrantReadWriteLock.ReadLock 和写锁类 ReentrantReadWriteLock.WriteLock。

以上两个类都提供了 lock / unlock 方法分别进行加锁和释放锁。

读锁最大的特点就是：读锁之间可以共享，所以读锁也被称为共享锁

而写锁的话就必须保证互斥，所以读锁也能理解为独占锁，因为同一时间只能有一个线程持有写锁。

这样就实现了上面那种图片的效果了：

读锁 + 读锁：不互斥

写锁 + 写锁：互斥

读锁 + 写锁：互斥

也就是说，只要有线程持有写锁，其他线程既不能获取读锁，也不能获取写锁

反过来，只要还有线程持有读锁，写线程就不能获取写锁

使用实例如下：

ReentrantReadWriteLock readWriteLock =
        new ReentrantReadWriteLock();
ReentrantReadWriteLock readWriteLock =
        new ReentrantReadWriteLock();

Lock readLock = readWriteLock.readLock();
Lock writeLock = readWriteLock.writeLock();
// 读操作加锁
public int getData() {
    readLock.lock();

    try {
        return data;
    } finally {
        readLock.unlock();
    }
}
// 写操作加锁
public int getData() {
    readLock.lock();

    try {
        return data;
    } finally {
        readLock.unlock();
    }
}

再补充一句，synchronized不是读写锁~

对于以上锁的内容，一般面试考察的就是概念性的

然后对于读写锁来说还有一个要注意的地方：

在ReentrantReadWriteLock中，持有写锁的线程，可以继续获取读锁。

例如：

这种操作叫做：锁降级

也就是从写锁变成了读锁，权限从独占变成了共享读取~

2.synchronized 原理

synchronized 前面已经学过了，但结合上面说到的锁策略问题，你可以将 synchronized 先理解成：

1. 开始倾向乐策略竞争频繁后转向更悲观的处理
2. 开始使用轻量级实现竞争严重后可能转成重量级锁
3. 轻量级阶段可能使用自旋
4. 非公平锁
5. 可重入锁
6. 不是读写锁

JVM 将synchronized锁分为无锁、偏向锁、轻量级锁、重量级锁状态。

2.1 加锁过程

synchronized不是一上来就用最重的方案，你可以这么理解：

竞争不严重的时候，能简单处理就简单处理。

当竞争越来越严重，简单办法搞不定，再逐渐换成更重的办法。

先不急着背这几个词，可以把线程放进一个具体场景。

class Counter {
    private final Object lock = new Object();
    private int count = 0;

    public void add() {
        synchronized (lock) {
            count++;
        }
    }
}

假设线程 A、B 都调用同一个 Counter 对象的 add()。它们竞争的就是该对象中的同一个lock。

无锁：目前还没有人使用这把锁

lock刚创建出来的时候还没有线程进入这段同步代码~

这时候线程 A 来执行 add，他想做的事情就只是：

“我要进入synchronized(lock)，修改count”

JVM 需要保证 A 修改期间，如果 B 也来了，B 不能同时修改~

但现在只有 A，一个竞争者都没有。但如果每次都按“许多线程争锁”的方式处理，成本就白花了。

偏向锁：一直都是 A 在使用

我还是拿之前的例子来吧：

假设我是个妹子，我要谈男朋友，我又希望把男朋友换的快一些，那么就有下面两个步骤：

1. 和当前男朋友分手

我需要 zuo 一 zuo，打一打拳，逐渐消耗他的耐心~~

我再谈分手，一定得是哭的梨花带雨，让它认为都是他的名字~

1. 和下一个小哥哥培养感情

当我最开始谈这个男朋友的时候，我和他做各种情侣之间做的事情，但是从不和他确认关系（搞暧昧）这就让他能够更好的满足我对于男朋友的需求~

然后当有一天我对他厌烦了，这个时候就不必麻烦了，直接和他说，咱们不要再见面了~

但这样搞暧昧的手段也有一定副作用，万一有别的妹子也在接近我的小哥哥，我的小哥哥也可以瞬间把我给踹了，然后用同样的话“咱们只是普通朋友”应对我

所以我只要发现了有妹子试图接近我家哥哥，只要一有这样的苗头，我就立即和我家哥哥确认关系，并且朋友圈官宣~让其他妹子就可以 gun 远了~

ok，像上述这样的过程，就是偏向锁的过程~

进行synchronized刚一上来，不是真加锁，而是只是简单做一个标记（搞暧昧）

这个标记，非常轻量，相比于加锁解释来说，效率高很多~

如果没有其他线程来竞争这个锁，最终当前线程执行到解锁代码，也就只是简单清除上述标记即可（不涉及真加锁、真解锁），就像是搞暧昧，不真确立关系，后续分手就很快

如果有其他线程来竞争，就抢先一步，在另一个线程拿到锁之前，抢先拿到锁。也就是真加锁了， 偏向锁 ->轻量级锁。其他线程只能阻塞等待~

本质上也是懒汉模式思想的体现

偏向锁之所以省事，前提是基本没有别的线程来争；前提变了，策略也得变。

轻量级锁：有竞争，但也许很快就结束

假设 A 正在执行：

synchronized (lock) {
    count++;
}

此时 B 恰好也来了。B 发现自己暂时拿不到 lock。

如果同步代码只有一个 count++，A 很可能马上就执行完了。此时此刻让 B 挂起，等操作系统以后再唤醒它，可能比“稍等一下”还费事。

尝试取得锁：用 CAS 检查并尝试更新与锁有关的状态。（先把 CAS 理解成一个“确认状态仍符合预期，才尝试修改”的动作）
短暂自旋：如果这次没取得锁，B 可以短暂重试，看看 A 是否已经释放。

这就和上面提到的自旋锁策略接上了，“我先不去休息，在小试一小会，也许你马上就用完了”

但 如果 A 持续时间很长，B 一直原地重试。这时候 B 就会持续消耗 CPU，所以自旋不会毫无节制地一直进行。短暂等待仍拿不到锁，就需要考虑成本更合适的处理方式。

重量级锁：持续竞争，就让线程等待

假设 A 进入同步代码后久久不退出，B 试了多次还是拿不到锁；或者有更多线程都来争这把锁。

此时要是再试一下就不划算了~所以就需要才需更重的处理方式，也就是重量级锁：有 JVM 的监视器机制管理竞争，拿不到锁的线程可能进入等待，等锁释放后再被唤醒、重新争取。

对于上述的内容我是这样认为

无锁 --> 偏向锁：代码进入synchronized的代码块

偏向锁 --> 轻量级锁：拿到偏向锁的线程运行过程中，遇到了其他线程尝试竞争这个锁

轻量级锁 --> 重量级锁：JVM 发现，当前竞争锁的情况非常激烈

当前 JVM 中，只提供了“锁升级”不能“锁降级”。注意此处我说的锁降级与前面提到的 ReentrantReadWriteLock 的锁降级不是同一种。

ReentrantReadWriteLock 的“锁降级”，是并发锁 API 的读写权限转换；synchronized 所谓“锁升级”，是 JVM/HotSpot 对 Monitor 的底层实现形态变化。

2.2 其他的优化操作

锁消除

锁消除就是编译器和 JVM 判断某些锁实际上不会发生线程竞争，于是把没有必要的加锁、解锁操作直接去掉~

就比如，都知道 StringBuffer 很多方法本身就带同步。

StringBuffer sb = new StringBuffer();
sb.append("a");
sb.append("b");
sb.append("c");
sb.append("d");

但如果，sb 只是一个方法里的局部变量，而且整个过程只有当前线程能访问。那么就根本没有线程在跟你抢，那这时候还“加锁、append、解锁”就纯粹是白忙活~

所以 JVM 如果能分析出这个对象不会被其他线程访问，那么就可以把这些没有意义的同步操作消掉~

再注意一下，JVM 只有在能够判断这个锁不会发生真实竞争时，才能进行这种优化

锁粗化

再看另一种情况：

for (int i = 0; i < 1000; i++) {
    synchronized (lock) {
        count++;
    }
}

假设 JVM 按代码表面上的范围处理，每轮循环都要 取得锁 -> count++ -> 释放锁

如果是循环一千次，那么就重复一千次

但问题是如果这些操作紧挨着进行，反复去取得、释放同一把锁，本身也会有成本。

所以锁粗化就是在合适的情况下，JVM 可能把多次相邻的加锁范围合并，减少反复申请和释放锁的次数。

举个例子：假设你要向领导交代三个任务

• 方式一：打电话交代任务 1，挂断；再打电话交代任务 2，挂断；再打一次交代任务 3.
• 方式二：打一次电话，把三个任务交代完，再挂断。

你给领导打电话（对领导加锁），这个时候领导需要全心全意应付你，没法做别的事情，所以必然会对整体效率产生影响~

所以方法二就省掉了重复的成本，锁粗化成一把锁省的也是反复“取得、释放”的成本。所以上面的加锁可以优化成这样：

synchronized (lock) {
    for (int i = 0; i < 1000; i++) {
        count++;
    }
}

所以 synchronized 真正厉害的地方，不只是“能加锁”，而是 JVM 在背后替我们做了很多优化。

那么对于如果有类似下面的面试题回答就不算困难了~

1. 什么是偏向锁？

偏向锁不是真的加锁，而只是在锁的对象头中记录一个标记（记录该锁所属的线程）。如果没有其他线程参与竞争锁，那么就不会真正执行加锁操作，从而降低程序开销。一旦真的涉及到其他的线程竞争，再取消偏向锁状态，进入轻量级锁状态。

1. synchronized 实现原理是什么？

对于《初阶》这篇文章我们已经介绍了synchronized和volatile，初阶知识点很多是在单独解决某个线程安全。为了切实理解如何应用，我引入了单例模式这个典型例子来深度讲解一下：

单例模式首先是设计模式里的其中一个，那么什么是单例模式，什么又是设计模式？

我先回答设计模式：

设计模式：设计模式不是某一个 Java 语法，而是针对某类常见问题总结出来的一套代码设计思路。而单例模式就是其中非常经典的一种。

你可以这么理解，设计模式可以类比象棋中的“棋谱”，针对红方的一些走法，黑方应招的时候有一些固定的套路，那么按照套路来走局势就不会吃亏。

那么软件开发中当然也会有很多常见的“问题场景”，针对这些问题场景，大佬就总结出了一些固定的套路，按照这个套路来实现代码也不会吃亏。

设计模式和框架也不是一个概念，框架属于“硬性要求”，设计模式属于“软性要求”；

单例模式：

希望某一个类，在程序中只存在一份的实例。

单例模式，是强制要求一个类不能创建多个对象，

你可以先记成：一个类 -> 只希望存在一个对象 -> 其他地方需要使用时 -> 都按这一份对象

单例模式具体实现方法有很多，常见的就有“饿汉”和“懒汉”两种。

1.1 饿汉模式

先看最简单的一种：

class Singleton {
    private static Singleton instance = new Singleton();	// 记住这个地方，在类加载阶段触发的
    private Singleton() {
        //...
    }
    public static Singleton getInstance() {
        return instance;
    }
}

好了，我先来解释一下饿汉模式：类加载的时候，就直接把实例创建出来；

你可以理解为太饿了，等不及别人来要，我先把饭做好放在这里。结合上面的代码就是在Singleton类加载的时候直接 new 出一个instance实例，之后谁需要直接通过getInstance获取；

再解释一下上面的代码，有三个点需要看懂：

1. 对于该句private static Singleton instance = new Singleton()，之所以用static，就是让instance这个实例直接属于类本身，而不是属于某个具体对象；
2. private Singleton()这里的构造方法使用private的原因就是为了禁止外部随便创建 Singleton 对象。
3. 想要获取 instance就只有通过静态方法getInstance。这是统一向外提供的对象。

当然，对于如果需要有多个参数去构建 instance 时，就可以再对多参数的构造方法进行私有化就可以了。

1.2 懒汉模式

我们已经知道了“饿汉”就是：我先给你做好。

懒汉也很好理解：你真要用的时候，我再做。

对了，再补充一下“懒”，“懒”在计算机中其实是褒义词，经常能够节省计算机资源开销，我举个例子：

假如有一个很大的文件（千万字的小说），你用编译器打开一般会有两种情况~

1. 把所有的内容，都从文件加载到内存中，在显示
2. 只把一部分内容加载并显示

第一种情况会明显卡顿，而且就算加载再多你也看不过来；第二种情况就是后续如果用户翻页，随着翻页随时加载后续的数据。

懒汉模式对应的就是第二种情况。而且我用的 Okular PDF 阅读器很明显用的就是懒汉模式，因为当你快速滑动到后面的图片时，很明显会需要加载一下下。

来看一段单线程下的懒汉模式例子：

class SingletonLazy {
    private static SingletonLazy instance = null;
    private SingletonLazy() {

    }
    public static SingletonLazy getInstance() {
        if(instance == null) {
            instance = new SingletonLazy();
        }
        return instance;
    }
}

这段懒汉模式与饿汉模式最大的区别就是在创建实例的时候。懒汉模式下，创建实例的时机是在第一次使用的时候，而不是在程序启动的时候。

当然，上述这些内容都是引子，接下来才是正题。

上面两份代码（饿汉、懒汉）是否存在线程安全问题，如果不是，该怎么办？（这也是经典的面试题）

首先对于饿汉模式，很明显只存在读操作，没有进行任何数据写入。多个线程最多是进行<font style="background-color:rgba(0, 0, 0, 0.06);">Singleton.getInstance()</font>去获取<font style="background-color:rgba(0, 0, 0, 0.06);">instance</font>而已。所以显然不存在线程安全问题。它的特点就是：不管以后到底用不用，类加载的时候对象就已经创建了。

但是对于懒汉模式，if 条件判断的时候，多线程下假设：

一个线程在进入 if 判断但还没进入创建实例的时候，另一个线程也在 if 判断，此时另一个线程也会同样进入线程去创建，这样第一个线程创建的实例就会被另一个线程后创建的实例给覆盖掉。

这样第一个线程的instance就被覆盖了，而且随着第二个现成的覆盖操作，第一个线程 new 出来的对象也就会被 GC（grabage collection 垃圾回收） 改释放掉了。像这样的情况就属于是 BUG，所以懒汉模式这样的写法，getInstance 就是线程不安全的。

在生产环境下，new 一个对象所要加载的内存可能是很大了（会有上百 G），所以像这样的操作还是很危险的，可能程序启动就会花费很长时间。

因此引入synchronized，将“希望”、“条件”和“修改”打包成原子的操作。但我还是要提醒的是：不是每个不安全的地方写了synchronized就会变得安全的，具体问题具体分析。

修改后得到的是：

class SingletonLazy {
    private static SingletonLazy instance = null;
    private static Object locker = new Object();
    private SingletonLazy() {

    }
    public static SingletonLazy getInstance() {
        synchronized(locker) {
            if(instance == null) {
                instance = new SingletonLazy();
            }
            return instance;
        }
    }
}

引入加锁之后，后执行的线程就会在加锁的位置阻塞，阻塞到前一个线程解锁。当后一个线程进入条件的时候，前一个线程已经修改完毕。instance不再为null，就不会进行后续的new操作。

但是这样又会产生一个新的问题：

每次调用 getInstance 都要加锁……多线程情况下，这里的加锁就会相互阻塞，进一步影响程序的执行效率。

加锁、解锁存在额外开销，而懒汉模式真正危险的其实只是第一次实例创建阶段，所以后续没必要每一次获取实例都继续竞争锁。

所以继续优化~

通过再一次增加 if 判断条件，进而决定是否要加锁：

class SingletonLazy {
    private static SingletonLazy instance = null;
    private static Object locker = new Object();
    private SingletonLazy() {

    }
    public static SingletonLazy getInstance() {
        if(instance == null) {
            synchronized(locker) {
                if(instance == null) {
                    instance = new SingletonLazy();
                }
            }
        }
        return instance;
    }
}

但这个地方，说实话我第一次学习的时候也觉得奇怪，因为在单线程两个一样条件的 if 是无意义的。单线程中，执行流就只有一个，上一个 if 的判定结果和下一个 if 是一样的~

但是在多线程中，两次判定之间，可能存在其他线程，然后其中有线程把 if 中的instance变量给修改了。就导致这里的两次 if 结论可能不同~

所以这里的两次 if 条件相同，只是纯属巧合了...

但是呢，增加了 if 判断是否加锁还是可能存在一些问题，比如是否会存在“内存可见性”问题？

答案是可能存在的，编译器优化非常复杂，为了稳妥起见可以给instance直接加上一个volatile，从根本上杜绝了内存可见性问题。

此处内存可见性就可能存在这种情况：第一个线程读取instance的时候，第二个线程进行修改。第一个线程就没有能及时读取到第二个线程进行的修改。

但这里更关键的问题其实是指令重排序。指令重排序也是编译器优化的一种体现，编译器会在逻辑不变的前提下，调整你代码执行的先后顺序，以达到提升性能的效果。

涉及指令重排序的代码为创建实例的时候：

instance = new SingletonLazy();

这一步从概念上可以拆成三步：

1. 分配对象内存
2. 执行构造函数，对对象初始化
3. 把对象地址赋值给 instance

正常来说这三个步骤是按照 1、2、3 这样的顺序来执行的。但是在指令重排序下，可能成为 1、3、2 这样的顺序，单线程环境下，1、2、3 还是 1、3、2 其实无所谓~

但多线程中是 1、3、2 这样的顺序执行，多线程环境下可能会出现 BUG！！！

这样的问题不仅仅是指令重排序引起的，也和双重 if 有关，那么到底该如何解决？

其实透露一下，volatile这个关键字的功能有两个方面：

1. 确保每次读取操作都是读内存
2. 关于该变量的读取和修改操作，不会触发重排序

所以最终优化版本如下：

class SingletonLazy {
    private static volatile SingletonLazy instance = null;	// 第三处
    private static Object locker = new Object();
    private SingletonLazy() {

    }
    public static SingletonLazy getInstance() {
        if(instance == null) {	// 第二处
            synchronized(locker) {	// 第一处
                if(instance == null) {
                    instance = new SingletonLazy();
                }
            }
        }
        return instance;
    }
}

最后切记关于懒汉模式的三个关键点，然后关于面试中真的遇到了该如何应对：

1. 先写一个不带线程安全的单例模式
2. 思索片刻，线程不安全，把锁加上
3. 再次思索片刻，加上 if
4. 再次思索片刻，加上 volatile

如果是一次写出最终版本，在面试官眼里他会觉得这个问题你正好准备过，此时说明这个题目就考察不出来啥，这题不算，谈下一话题~

2. 阻塞队列

我们在 JavaSE 中学过普通队列，应该都知道先进先出。而所谓的阻塞队列BlockingQueue就是一种比较特殊的队列。但它首先还是队列，所以仍然遵守先进先出。可它又多了一个非常重要的一个特点：

1. 当队列满的时候，继续入队列就会阻塞，直到有其他线程从队列中取走元素；
2. 当队列空的时候，继续出队列也会阻塞，直到有其他线程往队列中插入元素；

阻塞队列的一个典型应用场景就是“生产者消费模型”

2.1 生产者消费者模型

···

生产者消费者模型其实就是：通过一个容器来解决生产者和消费者的强耦合问题。

生产者和消费者彼此之间不直接通讯，而是通过阻塞队列来进行通讯，所以伸长这生产完数据之后不用等待消费者处理，直接扔给阻塞队列，消费者不找生产者要数据，而是直接从阻塞队列里取。

生产者消费者模型这名字也很好理解，就比如过年包饺子：

负责擀饺子皮的这个人就是生产者

负责包饺子的人就是消费者

这样，擀饺子皮的不关心包饺子的人是谁，包饺子的人也不用关心擀饺子皮的人是谁，大家就各自做各自的就行。

这也就是简单的上下游关系。阻塞队列的目的就是避免生产者和消费者之间绑得很死，能够解耦合；

阻塞队列还相当于生产者和消费者之间的缓冲，平衡生产者和消费者的处理能力，也就是削峰填谷。

一般来说 A 这种上游的服务器，尤其是入口的服务器，干的活更简单，单个请求消耗的资源数少；像 B 这种下游的服务器，通常承担更重的任务量，复杂的计算/存储 工作，单个请求消耗的资源数更多。

引入下面 2 这样的阻塞队列后，就能够有效缓解一下 B 服务器；它会让来自 A 的请求先进入阻塞队列，随后消费者服务器慢慢取，暗号服务器能承受的速度处理；

比如：突然来了 10000 个请求，先存起来，然后每秒处理 100 个；也就是高峰先缓冲，慢慢消化。这也就是所说的“削峰”。

2.2 标准库中的阻塞队列

import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;

public class Demo {
    public static void main(String[] args) throws InterruptedException {
        BlockingQueue<String> queue = new LinkedBlockingQueue<>();

        for (int i = 0; i < 100; i++) {
            queue.put("aaa");
        }
        System.out.println("队列已经满了. ");

        queue.put("aaa");
        System.out.println("再次尝试 put 元素");
    }
}

Java 已经给我们准备好了BlockingQueue，这是一个接口，真正实现的类是LinkedBlockingQueue。

• 其中put方法用于阻塞式的入队列，take用于阻塞式的出队列。
• BlockingQueue也有offer、poll、peek等方法，但是这些方法不带有阻塞特性。

会发现，这里有数组、链表以及优先级队列实现的阻塞队列。说到这就想到，面试中常考的 Java 中 ArrayList 和 LinkedList 有什么区别，其实最主要的是他们的时间复杂度

• 顺序表：尾插尾删，O(1)；头插头删、中间位置插入 O(N)
• 链表：任意位置插入删除 O(1)

这里我让 ai 给了个阻塞队列的表格：

先来一个例子：

生产者消费者模型使用阻塞队列

public class Demo7 {
    
    public static void main(String[] args) {
        BlockingQueue<Integer> queue = new LinkedBlockingQueue<>();
        Thread producer = new Thread(() -> {
            int num = 0;
            while (true) {
                try {
                    queue.put(num);
                    System.out.println("生产元素" + num);
                    num++;
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
        },"producer");

        Thread consumer = new Thread(() -> {
            try {
                Integer num = queue.take();
                System.out.println("消费元素" + num);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });

        producer.start();
        consumer.start();
    }
}

关于此处要是不设参数的话，默认会是一个非常大的值...

用计算机计算就能知道是 21 亿多，

另外阻塞队列中，没有提供一个“阻塞的获取队首元素的操作”。

对于上述代码中，如果让其中一个 sleep 等待一下，让生产者速度比消费者速度快一下会如何？

其实只是生产者会很快填满阻塞队列，然后消费者会一个一个从中取出，就按他自己的节奏来。其实按照上述代码就算存满了，其实也占不了多大内存，我们已经知道该队列最大最多 21 亿个元素，每个元素就是一个 int 的 4 字节空间。总共就是 80 亿字节，转换为也就是 8G；

具体转换如下：

Thousand 千 => K

Million 百万 => M

Billin 十亿 => G

2.3 阻塞队列模拟实现

class MyBlockingQueue {
    // 此处不使用泛型
    private String[] data = null;
    // 队首
    private int head  = 0;
    // 队尾
    private int tail = 0;
    // 元素个数
    private int size = 0;
    public MyBlockingQueue(int capacity) {
        data = new String[capacity];
    }

    public void put(String elem) throws InterruptedException {
        // 当队列满，需要阻塞
        synchronized (this) {
            while (size >= data.length) {
                this.wait();
            }
            data[tail] = elem;
            tail++;
            // 再判断是否需要循环
            if(tail >= data.length) {
                tail = 0;
            }
            size++;
            // 针对队列空的话，需要唤醒阻塞
            this.notify();
        }
    }

    public String take() throws InterruptedException {
        // 当队列空，需要阻塞
        synchronized (this) {
            while (size == 0) {
                this.wait();
            }
            String ret = data[head];
            head++;
            if (head >= data.length) {
                head = 0;
            }
            size--;
            // 针对队列满的话，需要唤醒阻塞
            this.notify();
            return ret;
        }
    }
}

上述使用的阻塞队列是循环的队列：

由于队列满或者队列空的时候需要阻塞队列，然后又由于队列不空或者不满的时候需要被唤醒，所以put和take方法中分别都需要到wait和notify。

• 注意，上述代码中，使用synchronizd的目的是，解决多个线程同时修改队列导致的数据竞争，避免两个线程可能同时操作同一个位置导致队列混乱，保证 head、tail、size、data 的操作是线程安全的。另外，此处为避免混乱还需结合着wait和notify一起使用。

if (size >= data.length) {
    this.wait();
}

• 另外关于为什么使用的是while而不是if。问题在于被notify唤醒，并不代表你现在一定可以继续执行。假设：队列容量为 1，且当前队列已占满。现在有两个生产者 P1、P2 都想放元素。于是当前 P1、P2 都进入 wait等待。然后消费者取走占满的元素，唤醒了两个等待线程，假设是 P1 先拿到锁，现在队列就又满了。如果是if那么 P2 从wait后面继续执行，不会再次判断条件。于是就直接进行data[tail] = elem。但如果是while的话，P2 会再重新检查一遍是否真的被唤醒~

对于使用wait这个地方，其实标准库中就已经建议使用while来替换if~

java17中关于wait的相关解释

对了，上述所说的 wait，其实也不只是能被 notify 唤醒，还可以被Interrupt这样的方法给中断。如果用 if 作为 wait 的判断条件，此时也还是存在被提前唤醒的风险！

3 线程池

之前学习 String 已经初步了解了常量池相关知识，常量池主要就是为了复用常量数据，减少重复存储。它与线程池的共同点就是池化的思想：

把创建成本较高或可以重复利用的资源提前保存起来，后续重复使用。

那么线程池的意义就是，我还是举个例子吧：

一家餐厅每天都会不断有客人来。如果每来一桌客人，就临时招聘一个服务员，服务完再把他辞退，成本会非常高。
更合理的做法是提前准备固定数量的服务员，客人来了就分配给空闲服务员处理；忙不过来时，客人先排队等待。

所以线程池的最大好处就是提前创建并复用线程，避免频繁创建和销毁线程带来的开销。

对于频繁创建和销毁线程，目前已经有三种解决情况了：

1. 线程池，不反复创建，直接使用；
2. 协程：不再让每个任务都对应一个重量级线程；
3. 虚拟线程，Java21+之后开始的；

但目前使用最普遍还是线程池，剩下两个可以后面再了解~

关于为什么叫“池”，主要还是因为池化的这种思想。都是池子里会提前准备一些资源，需要的时候拿出用即可，用完不是销毁，而是放回池子里继续再使用。

3.1 标准库中的线程池

其实，线程池不需要我们每次自己实现。Java 的标准库已经提供好给我们了。

先讲 Java 供我们可以自定义的线程池：

首先先来区分一下这些名称

Executor → 接口

ExecutorService → 线程池常用接口

Executors → 工具类，帮我们创建线程池

ThreadPoolExecutor → 线程池核心实现类

ThreadPoolExecutor 自定义线程池

核心方法是 submit(Runnable)，不过这个方法你在ThreadPoolExecutor没看到很正常，因为ThreadPoolExecutor是继承了submit这个方法。

继承关系是：Executor <- ExecutorService <- AbstractExecutorService <- ThreadPoolExecutor

而 submit方法主要是在ExecutorService中定义的，在 AbstractExecutorService 中给出了实现，所以 ThreadPoolExecutor 直接继承了它。

然后通过 Runnable 描述一段要执行的任务，再通过submit任务放到线程池中，线程池就会执行这些任务；

但构造ThreadPoolExecutor线程池有些麻烦，需要了解一些相关参数：

有四个构造参数，一般面试会问这些参数都是什么意思（经典面试题）

面试官最想听的就是你对于第七个参数的理解~

这里我们直接了解最困难的最后一个

ThreadPoolExecutor(
        int corePoolSize,
        int maximumPoolSize,
        long keepAliveTime,
        TimeUnit unit,
        BlockingQueue<Runnable> workQueue,
        ThreadFactory threadFactory,
        RejectedExecutionHandler handler
)

• int corePoolSize：核心线程数，表示至少有多少个线程。线程池一旦创建，这些线程也要随之创建，知道整个线程池销毁，这些线程才会销毁。
• int maximumPoolSize：最大线程数，表示核心线程数+非核心线程数（不繁忙就销毁，繁忙就再创建），我们知道，线程不是越多越好的。
• long keepAliveTime：非核心线程允许空闲的最大时间。临时增加出来的线程，不可能永远留在那里。
• TimeUnit unit：时间单位，单看keepAliveTime = 10你不知道单位是秒？分钟？小时？这里是枚举类型
• BlockingQueue<Runnable> workQueue：任务队列，也就是我们前面学到的阻塞队列（线程池里的任务队列）。当然了此处的队列可以自己选择合适的根基（数组/链表、指定 capacity、指定是否要带有优先级/比较规则）。线程池本质上也是生产者消费者模型，调用submit就是在生产任务，线程池里的线程就是在消费任务。
• threadFactory：线程工厂，用来定义线程池创建工作线程的方式。线程池需要新线程时，会调用 ThreadFactory.newThread(Runnable) 创建线程。通过线程工厂可以统一设置线程名称、优先级、是否为守护线程以及异常处理方式等。它只负责“怎么创建线程”，不负责决定“什么时候创建线程”。

对于为什么使用线程工厂，我给到下面的解释：

假设我有一个 Point，他最终都要保存平面直角坐标，单床剪一个点时，可以有两种输入方式：

方法 1，使用直角坐标(x,y)；方法 2，使用极坐标(r,a)

但问题就在构造方法这里，我们会自然的写出两个构造方法：

class Point {
    public Point(double x, double y) {
        // 按照直角坐标创建
    }
    public Point(double r, double a) {
        // 按照极坐标创建
    }
}

但是 Java 不允许，原因就是 Java 的方法重载看的是方法名、参数个数、参数类型、参数顺序。所以对于 Java 来说这俩就完全一样。所以就用工厂方法来解决。就改为不直接让用户调用构造方法，而是提供不同名字的方法。就比如下面：

class PointFactory {
    public static Point makePointByXY(double x, double y) {
        Point p = new Point();
        p.x = x;
        p.y = y;
        return p;
    }

    public static Point makePointByRA(double r, double a) {
        Point p = new Point();
        p.x = r * Math.cos(a);
        p.y = r * Math.sin(a);
        return p;
    }
}

注意类型是 Point并且还是静态方法。工厂方法的核心就是通过静态方法把构造对象 new 的过程、各种属性初始化的过程封装起来，并且提供多组静态方法，实现不同情况的构造。此时调用就可以这样：

Point p1 = PointFactory.makePointByXY(3, 4);
Point p2 = PointFactory.makePointByRA(5, Math.PI / 2);

当然也可以直接在Point里面写静态工厂方法：

class Point {

    private double x;
    private double y;

    private Point(double x, double y) {
        this.x = x;
        this.y = y;
    }
    public static Point fromXY(double x, double y) {
        return new Point(x, y);
    }
    public static Point fromRA(double r, double a) {
        return new Point(
                r * Math.cos(a),
                r * Math.sin(a)
        );
    }
}

// 使用
Point p1 = Point.fromXY(3, 4);
Point p2 = Point.fromRA(5, Math.PI / 2);

以上两种方法分别是：

构造方法：负责真正构造对象

静态工厂方法：负责提供不同的创建方式

以上就是对工厂类的解释。

• RejectedExecutionHandler：拒绝策略，显然他的意思就是字面意思。submit会把任务添加到任务队列中，任务队列是阻塞队列，队列满了再添加，就会阻塞~对于线程池来说，发现入队列操作时，队列满了，不会真的触发“入队列操作”，不会真阻塞，而是执行拒绝策略相关代码。

为什么不使用生产者消费者模型是因为如果调用submit就阻塞，就会是这个线程就没法干别的事情，对于用户那里就会迟迟拿不到请求的响应，用户等了很久，直观上看到的现象就是“卡了”。所以，与其是“卡了”不如直接告诉我“失败”。

拒绝策略就是下面四个，我会再一步解释一下：

拿快递站举个例子，现在所有员工都忙，任务本也写满了，临时工也招到上限。

此时来了一个快件...

AbortPolicy：“接受不了了！”，直接报错；

CallerRunsPolicy：“谁把这个任务送过来的，谁自己干。”

DiscardOldestPolicy：“把任务本里最老的一项扔掉，给新任务腾位置。”

DiscardPolicy：“新来的直接不要。”

意思就是上面这么个意思

Executors封装好的常用线程池

如果按照上面的自定义线程池那样，每次使用线程池就得自己填写那么多参数还是太麻烦了。而且很多时候我们的需求其实也很普通：我就是想要一个固定 10 个线程的线程池。

所以 Java 就提供了一个封装好的 Executors 这样一个工具类。它就相当于帮我们把常见的ThreadPoolExecutor参数提前组合好了，并且提供了几种常见线程池创建方式。

下面都是Executors的方法：

我只大概了解其中几个：

• newFixedThreadPool：创建一个固定 n 个线程的线程池。

ExecutorService pool =
        Executors.newFixedThreadPool(10);
pool.submit(() -> {
    System.out.println("hello");
});

• newCachedThreadPool：创建线程数量可以动态变化的线程池。业务多的时候会增加线程；业务少的时候空闲线程逐渐回收。
• newScheduledThreadPool：可以完成延迟执行、定期执行；正好等到后面要说的定时器再展开。

综上也能看出来，其实 Executors 本质上就是 ThreadPoolExecutor 类的封装。

3.2 线程池的关闭

线程池使用完后，需要主动进行关闭。ThreadPoolExecutor中常用的两个就是：shutdown()和awaitTermination()。

其中shutdown()用于发起线程池关闭通知，而awaitTermination()用于等待线程池真正关闭完成。

shutdown()方法

executor.shutdown()，调用shutdown之后，线程池会进入关闭状态，会有以下的过程：

1. 不再接受新任务；
2. 已经提交并正在执行的任务会继续执行；
3. 已经进入任务队列的任务也会继续执行；
4. 当所有已提交任务执行完成后，线程池中的工作线程才会逐渐退出。

注意，shutdown不会阻塞调用它的线程~毕竟，谁会断了自己的路呀~

awaitTermination()方法

如果程序需要确认线程池中的任务已经执行结束，可以配合：

executor.awaitTermination(10, TimeUnit.SECONDS);

作用就是：让当前线程等待线程池结束，最多等待指定的时间。

通常需要先调用executor.shutdown()，再调用executor.awaitTermination(10, TimeUnit.SECONDS)

例如：

executor.shutdown();

try {
    boolean finished = executor.awaitTermination(10,TimeUnit.SECONDS);

    if (finished) {
        System.out.println("线程池已经完全关闭");
    } else {
        System.out.println("等待超时，线程池仍未关闭");
    }

} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
}

此处，awaitTermination(10,TimeUnit.SECONDS)表示当前线程最多等待线程池 10 秒。然后这个方法还会返回一个boolean值：true 表示在线程等待期间，线程池已经完全终止；false 表示等待时间已经到了，但线程仍然没有结束。

3.3 线程池模拟实现

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;

// 实现一个固定线程个数的线程池
public class MyThreadPool {
    private BlockingQueue<Runnable> queue = null;
    public MyThreadPool(int n) {
        // 初始化线程池，创建固定个数的线程
        // 此处使用ArrayBlockingQueue作为任务队列，容量为1000
        queue = new ArrayBlockingQueue<>(1000);

        // 创建线程
        for (int i = 0; i < n; i++) {
            Thread t = new Thread(() -> {
                try {
                    while (true) {
                        Runnable task = queue.take();
                        task.run();
                    }
                } catch(InterruptedException e){
                    throw new RuntimeException(e);
                }
            });
            // 启动线程
            t.start();
        }
    }

    // 提交任务
    public void submit(Runnable task) throws InterruptedException {
        queue.put(task);
    }

    public static void main(String[] args) throws InterruptedException {
        MyThreadPool pool = new MyThreadPool(10);
        for (int i = 0; i < 100; i++) {
            int id = i;
            pool.submit(() -> {
                System.out.println(Thread.currentThread().getName() + " id = " + id);
            });
        }
    }
}

理解线程池最直接的方法之一，就是自己实现一个简化版本，并且能不看模板自己实现一个，这样你才能明白到这段代码中很多细节以及整个运转流程，真的...

真正的 ThreadPoolExecutor 内部还包含核心线程数、最大线程数、拒绝策略、线程回收、线程池状态管理等大量机制，但如果只看最核心的思想，其实可以概括为两部分：

• 提前创建一批可以重复使用的工作线程
• 使用一个任务队列保存暂时还没有被执行的任务

上面那部分代码虽然很简单，但已经包含了线程池最基本的运行过程。我来解释一下部分含义：

1. 使用阻塞队列保存任务

我在线程池内部首先定义了一个BlockingQueue<Runnable>，创建了一个容量为 1000 的阻塞队列，队列中保存的不是线程，而是Runnable，也就是一个个等待执行的任务。当调用pool.submit(task)时，任务并不会立即由submit方法执行，而只是通过queue.put(task)被放入任务队列中。

整个过程就是

“提交任务 -> submit(task) -> queue.put(task) -> 等待工作线程处理”

使用阻塞队列还有一个重要的原因：它可以很好的协调“提交任务的线程”和“执行任务的线程”。

当队列暂时没有任务时，工作线程执行：queue.take()，会进入阻塞状态，而不是不断循环检查队列。这样的话线程在没有任务的时候就不会一直占用的 CPU。

1. 提前创建固定数量的工作线程

在线程池的构造方法中，已经提前创建好了 n 个线程MyThreadPool pool = new MyThreadPool(10)，这就意味着线程池创建时会直接启动 10 个工作线程。这些线程当然不是执行一次任务以后就结束，而是在 while 里不断循环去 take 任务：

while (true) {
    Runnable task = queue.take();
    task.run();
}

1. take() 负责取得任务，run() 负责执行任务

在工作线程中最核心的代码实际上只有两行：

Runnable task = queue.take(); 
task.run();

queue.take()负责从任务队列中获取一个Runnable任务，当其他线程通过queue.put(task)提交新任务以后，线程池中的一个的等待中的工作线程就可以取得这个任务。

task.run()才是真正执行任务的地方，当然这里还有注意去分析下t.start()和task.run()。

例如：

Thread t = new Thread(...);
t.start();

表示启动一个工作线程。之后这个工作线程从队列中取得Runnable task，再调用task.run()表示由当前这个已经启动的工作线程去执行任务。

👌以上就是我对模拟实现的讲解~

4. 定时器

上面我们已经学习了线程池，他所解决的主要是任务来了以后交给谁执行，而现在要学习了定时器要解决的是这个任务是么时候执行。

你可以把定时器类比一下为“闹钟”，先把任务和时间约好，等时间到了以后再去执行对应的代码。就像是计算机网络里学到的网络通信超过一定时间没有响应就重连，或者让某个缓存数据几秒以后过期。

4.1 标准库中的Timer

标准库提供了一个 Timer 类，Timer 类的核心方法就是Schedule；

Schedule包含两个参数，第一个参数指定即将要执行的任务代码，第二个参数指定多长时间之后执行（单位为毫秒）

Timer timer = new Timer();

timer.schedule(new TimerTask() {
    @Override
    public void run() {
        System.out.println("hello");
    }
}, 3000);

以上是匿名内部类写法，与讲线程的创建方法的时候类似。

主要就是以下三个要点：

1. 创建了子类（父类 TimerTask），匿名
2. 重写了 run
3. new 了子类的实例

正常描述任务，是 Runnable，但在定时器这里稍微特殊一些，把 Runnable 封装了一下为 TimeTask。那么 Timer 和 TimerTask 分别又是什么呢？

你可以这样理解，就是Timer负责什么时候执行，也就是调度者；TimerTask负责执行什么，也就是任务；

和线程池类似，线程池负责调度并执行 Runnable 任务，而 Timer 负责定时调度 TimerTask 任务；实现 Runnable 时需要实现 run() 方法，继承 TimerTask 时同样需要重写 run() 方法，因为真正的任务逻辑都写在 run() 中。

Thread thread = new Thread() {
    @Override
    public void run() {
        System.out.println("hello");
    }
};

thread.start();

以上就是两者的大概对比；还有就是和线程池一样，Timer 中也包含前台线程，阻止进程结束。

4.2 定时器的模拟实现

首先我们需要了解定时器的构成：

1. 一个带优先级队列（不需要使用 PriorityBlockingQueue，容易死锁）
2. 队列中的每个元素是一个 Task 对象
3. Task 中带有一个时间属性，队首元素就是即将要执行的任务
4. 同时有一个 worker 线程一直扫描队首元素，看对队首元素是否需要执行

而我们要实现定时器则需要按照下面这四部分：

1. 创建一个类MyTimeTask，表示一个任务
2. 定时器中，能够管理多个任务的集合类
3. 实现 schedule 方法，把任务添加到队列中即可
4. 额外创建一个线程，负责执行队列中的任务

和线程池不同，线程池是只要队列不为空，就立即取任务并执行。此处还要看队首元素的时刻是否到了，时刻到才能执行，时刻不到不能执行。

这里的话，我喜欢先讲解再展示代码哈：

• 我先创建两个类，分别是定时器类MyTimer,以及存放任务的 MyTimerTask。这里我没有实现Runnable，而是直接在MyTimerTask持有一个Runnable。所以MyTimerTask里就存在了两个参数，Runnable task和long time；接着就是必备着带着两个参数的构造方法。记住，既然自己实现了任务类就得自己实现一个比较器。
• 接着就是在MyTimer定时器里创建一个优先级队列PriorityQueue<MyTimerTask> queue，存放就是自己写的任务类MyTimerTask。再然后就是创建schedule方法，在这个方法里实例化一个新任务并放入队列中。
• 随后就是在MyTimer中通过构造方法创建线程，循环从队列中提取任务进行执行

这三部分我都是按照上面说的，只是将第二步与第三步放在了一起。然后是注意线程安全问题，注意加锁 synchronized 以及wait/notify；

package timer;

import java.util.PriorityQueue;

/**
 * Created with IntelliJ IDEA.
 * Description:
 * User: Syrena.
 * Date: 2026-09-20
 * Time: 13:24
 */
public class MyTimer {
    // 队列里的每一个元素都是MyTimerTask类型
    private PriorityQueue<MyTimerTask> queue = new PriorityQueue<>();
    private Object locker = new Object();
    // 创建schedule方法
    public void schedule(Runnable task, long delay) {
        synchronized (locker) {
            // 记录时间戳
            // 实例化时建议放在锁里，否则没拿到锁的时候就先实例化时间存在一定延迟
            MyTimerTask timerTask = new MyTimerTask(task, System.currentTimeMillis() + delay);
            queue.offer(timerTask);
            locker.notify();
        }
    }

    // 构造方法中，额外创建一个线程，负责执行队列中的任务
    public MyTimer() {
        Thread t = new Thread(() -> {
            try {
                while (true) {
                    synchronized (locker) {
                        while (queue.isEmpty()) {
                            locker.wait();
                        }
                        // 取出队首元素
                        MyTimerTask task = queue.peek();    // 先判断时间是否到再移除
                        if(System.currentTimeMillis() < task.getTime()) {
                            // 当前任务时间如果比系统时刻还大，说明还未到执行时刻
                            locker.wait(task.getTime()
                                    - System.currentTimeMillis());
                        } else {
                            task.run();
                            queue.poll();
                        }
                    }
                }
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
        t.start();
    }
}

package timer;

/**
 * Created with IntelliJ IDEA.
 * Description: 用来描述一个任务
 * User: Syrena.
 * Date: 2026-09-20
 * Time: 13:15
 */

    /*
    两个方法：
    1. 实现一个Runnable，但需要基于抽象类定义MyTimerTask
    2. 持有一个Runnable
     */
// 由于比较的类是自己写了类型，所以比较规则需要自己写（Comparable/Comparator）
public class MyTimerTask implements Comparable<MyTimerTask>{

    private Runnable task;
    private long time;  // 记录要执行的时刻，用时间戳

    // 构造函数里传入可运行的task
    public MyTimerTask (Runnable task,long time) {
        this.task = task;
        this.time = time;
    }

    @Override
    public int compareTo(MyTimerTask o) {
        return (int) (this.time - o.time);  // < 0，则this < 0；需求是让时间小的元素在队首，实现小根堆
    }
    public long getTime() {
        return this.time;
    }
    public void run() {
        task.run();
    }

    public static void main(String[] args) {
        MyTimer myTimer = new MyTimer();
        myTimer.schedule(new TimerTask() {
            @Override
            public void run() {
                System.out.println("Hello 1000");
            }
        },1000);
        myTimer.schedule(new TimerTask() {
            @Override
            public void run() {
                System.out.println("Hello 2000");
            }
        },2000);
        myTimer.schedule(new TimerTask() {
            @Override
            public void run() {
                System.out.println("Hello 3000");
            }
        },3000);
    }
}

以上就是定时器的模拟实现，需要注意的是：

public MyTimer() {
    Thread t = new Thread(() -> {
        try {
            while (true) {
                synchronized (locker) {
                    while (queue.isEmpty()) {
                        locker.wait();
                    }
                    // 取出队首元素
                    MyTimerTask task = queue.peek();    // 先判断时间是否到再移除
                    if(System.currentTimeMillis() < task.getTime()) {
                        // 当前任务时间如果比系统时刻还大，说明还未到执行时刻
                        locker.wait(task.getTime()
                                - System.currentTimeMillis());
                    } else {
                        task.run();
                        queue.poll();
                    }
                }
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    });
    t.start();
}

此处的构造方法本身可以写synchronized，但此处不能将synchronized直接包裹整个构造方法，因为此处的synchronized 保护的是线程的 run 里面的 lambda；

while (queue.isEmpty()) {
    locker.wait();
}

此处使用 wait 时要使用 while，避免异常唤醒以及其他可能唤醒能够循环再次检查一遍；如果使用if检查的话，会导致忙等，一直循环检查会消耗大量 CPU 资源。

if(System.currentTimeMillis() < task.getTime()) {
    // 当前任务时间如果比系统时刻还大，说明还未到执行时刻
    locker.wait(task.getTime()
            - System.currentTimeMillis());
} else {
    task.run();
    queue.poll();
}

此处使用 wait 时无需再 while 检查，因为外面有一层 while，就算这里被异常唤醒后能够再循环到这一步重新 wait。

标准库提供的 Timer 和自己写的 MyTimer 差不多，都是使用一个线程，负责扫描队首元素并执行。但其实可以结合线程池，创建多个线程，负责执行这里的队列中的任务（一个线程负责扫描，扫描到需要执行的任务，添加到另一个线程池的任务队列中，有多个线程负责执行）

如果任务少/任务的时间分散都无所谓，如果任务特别多，时间非常集中，一个线程就可能执行不过来~

定时器其实是一个非常重要的组件，在分布式系统中，把定时器专门提取出来，封装成一个单独的服务器~

1.1 什么是多线程

上一篇我们已经提到，一个程序运行起来就是一个进程。而一个进程里，又存在多个线程。

简单来说：

进程提供运行环境和资源，而线程是真正在这个环境中执行代码的执行流；

我们之前是这么比喻的：

进程 = 一套房子

线程 = 房子里干活的人

同一个房子里，可以住好几个人，就比如：

张三在厨房做饭
李四在客厅扫地
王五在阳台晾衣服

他们虽然在干不同的事情，但他们都在共享着一套房子里的资源。当然，在程序里也差不多。

在一个 Java 进程中可以存在多个线程，每个线程都有自己的执行流程，但是同一个进程里的线程又可以共享这个进程里的资源和数据。这就是所说的多线程。

1.2 为什么需要线程

还是拿上一篇“吃鸡”的例子

现在桌子上有 100 只鸡：

如果只有我一个人吃：

我必须得一只、两只、三只......

但如果我叫来一位老铁：

如果条件合适，两个人就可以分别处理一部分工作

对应到程序里就是一个任务可以被拆成很多个相对独立的任务，交给多个线程执行。

但，千万不要理解成：线程越多，程序就一定越快。这个结论当然是不成立的。

依旧是吃鸡这个例子，一张桌子本来坐四个人正好，你非得找 100 个人围着这张桌子：

“兄弟们！我们今天靠人数优势干爆这 100 只鸡！”

最后可能会出现这种情况：

鸡没吃几只，100 个人先因为 “你挡我了。”、“筷子给我。”、 “让我过去。”等各种原因先打起来。

线程也是一样。线程创建、切换和调度本省都有开销，而且 CPU 核心数量也是有限的。所以合理的多线程可以提高效率，而不是无限增加线程数量。

这里我给出了一段代码，可以尝试运行一下，比较线程串行和并行的时间效率：

/**
 * Created with IntelliJ IDEA.
 * Description:
 * User: Sirens007
 * Date: 2026-09-02
 * Time: 10:27
 */
public class TheadAdvantage {
    private static final long count = 10_0000_0000;

    private static void concurrency() throws InterruptedException {
        long begin = System.nanoTime();

        Thread thread = new Thread(new Runnable() {
            @Override
            public void run() {
                int a = 0;
                for (long i = 0; i < count; i++) {
                    a--;
                }
            }
        });
        // 主线程内计算b的值
        int b = 0;
        for (long j = 0; j < count; j++) {
            b--;
        }
        // 等待thread进程结束
        thread.join();

        long end = System.nanoTime();
        double ms = (end - begin) * 1.0 /1000 /1000;
        System.out.printf("并发：%f 毫秒 %n",ms);
    }

    private static void serial() {
        // 都在主线程计算a , b值
        long begin = System.nanoTime();
        int a = 0;
        for (long i = 0; i < count; i++) {
            a--;
        }
        int b = 0;
        for (long j = 0; j < count; j++) {
            b--;
        }
        long end = System.nanoTime();
        double ms = (end - begin) * 1.0 /1000 /1000;
        System.out.printf("串行：%f 毫秒 %n",ms);
    }

    public static void main(String[] args) {
        try {
            concurrency();
            serial();
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }

    }
}

2.Java 中创建线程

我了解到的是有三个方法：

2.1 继承 Thread

首先需要自己写一个类，主要是为了重写 Thread 中的 run()方法：

class MyThread extends Thread {

    @Override
    public void run() {
        System.out.println("我开始干活了");
    }
}

其中的 run()方法描述的是这个线程启动后，到底要做什么，然后就会创建线程对象 thread。

但是此时还没有真正开始执行，你可以类比这个例子：

我把李四叫到了公司

李四就说：“老板，我来了。”

我：“嗯”

然后谁也不说话，李四当然不会知道自己需要去做什么了。

所以这个时候还需要我们去启动线程：thread.start();

这就相当于：我跟李四说：“李四，开始干活！ ”

这个时候就算是真正的启动了一个线程。注意：run() 和 start()千万不要弄混淆；直接写 thread.run()的话只是相当于直接调用方法，而启动执行流才是使用：thread.start()

2.2 实现 Runnable 接口

除了直接继承Thread，Java 还可以把“线程”和“任务”拆开。

同样我们还是需要重写 run()方法，因为实现 Runnable 接口就得重写它的所有方法：

不过 Runnable 只有一个 run 方法~

class MyRunnable implements Runnable {

    @Override
    public void run() {
        System.out.println("开始搬砖");
    }
}

然后还要记得启用线程：

MyRunnable task = new MyRunnable();
Thread thread = new Thread(task);
thread.start();

不知道会不会有人觉得这样写法比继承 Thread 多绕了一层...

不过我推荐这样理解：

Thread 是员工，Runnable 是工作任务；

假如当前有个任务是搬 100 块砖，因此我需要去定义这个任务

MyRunnable task = new MyRunnable()，然后再把任务交给员工，Thread thread = new Thread(task)，最后老板说开始干，也就是thread.start()这样就会好理解多了；

2.3 其他变形

2.3.1 使用匿名内部类创建 Thread

如果你打算这个线程就使用一次的话，单独写 MyThread 就似乎有点麻烦了。

所以我们可以直接使用匿名内部类：

Thread thread = new Thread() {

    @Override
    public void run() {
        System.out.println("我开始干活了");
    }
};

thread.start();

本质上还是要重写 run 方法，只是这次这个类我没有单独取名字，直接现场创建。

2.3.2 使用匿名内部类创建 Runnable

既然上面 Thread 可以使用匿名内部类，Runnable 当然也是可以啦

Thread thread = new Thread(new Runnable() {

    @Override
    public void run() {
        System.out.println("我开始干活了");
    }
});

thread.start();

本质上还是：任务 + 执行任务的线程

2.3.3 使用 Lambda 创建线程

首先我们需要知道什么是 Lambda，Lambda 你可以理解为：对“只有一个抽象方法的接口”的简化写法。

Lambda 是从 Java8 开始引入的，主要就是为了“把一段代码装起来”，举个例子：

public static void hello() {
    System.out.println("Hello");
}

这个方法就描述了一件事情，但我现在想把这段“要执行的代码”交给另外一个东西，让它以后帮我们执行，我们一般就只能通过 接口 -> 实现类 -> 重写方法 -> 创建对象 这样的步骤完成；

// 创建接口
interface Task {
    void run();
}

// 创建类实现接口
class MyTask implements Task {

    @Override
    public void run() {
        System.out.println("Hello");
    }
}

// 最后创建对象
Task task = new MyTask();

引入 lambda 就是为了让这种代码变的简洁,于是这部分就变成了：

Task task = () -> {
    System.out.println("Hello");
};

能够省去了“创建类实现接口”这个部分；

3.Thread 常用属性和方法

至于线程我们已经知道如何创建出来了，那么我们就还得了解它现在在干嘛、怎么让它停下来、等待它结束，或者通知它停止？

3.1 Thread 常见属性

在我们创建线程的时候，thread 不只是一个普通的对象，它描述的就是后面那个线程执行流。

先来一段代码：

public class ThreadDemo {

    public static void main(String[] args) {

        Thread thread = new Thread(() -> {
            System.out.println("线程开始工作");
        });

        System.out.println("线程 ID：" + thread.getId());
        System.out.println("线程名称：" + thread.getName());
        System.out.println("线程状态：" + thread.getState());
        System.out.println("线程优先级：" + thread.getPriority());
        System.out.println("是否后台线程：" + thread.isDaemon());
        System.out.println("是否存活：" + thread.isAlive());
        System.out.println("是否被中断：" + thread.isInterrupted());
    }
}

这里面用到的方法就是 Thread 提供的线程 ID、名称、状态、优先级、是否存活以及终端标志等信息。

• getId()：获取线程的编号，就类似员工的工号；
• getName()：获取线程名字，我们当然可以自定义名字，方法如下；
• getState()：用于获取线程当前的状态，后面会再介绍进程的四个状态；
• getPriority()：用于查看线程优先级，但这里的线程优先级高也不代表一定会先执行；
• isDaemon()：用于查看是不是后台线程，也可以叫守护线程，你可以理解为做后勤的；然后一般前台线程、后台线程都是有多个的；如果有多个前台线程，必须得等所有前台线程都结束了，进程才能结束；
• isAlive()：用来判断该线程是否还活着；
• isInterrupted()：给线程发一个中断通知，但不是强制杀死线程；

// 自定义名字
Thread thread = new Thread(() -> {
    System.out.println("开始搬砖");
}, "李四");

3.2 Thread 常见构造方法

具体的使用例子如下：

Thread t1 = new Thread();
Thread t2 = new Thread(new MyRunnable());
Thread t3 = new Thread("这是我的名字");
Thread t4 = new Thread(new MyRunnable(), "这是我的名字");

如果我们想实时了解线程的状态，我们还可以通过 jdk 里的 jconsole 这个可执行文件查看，路径就在 jdk 下面的 bin 目录里，如下：

3.3 启动一个线程-start()

我们之前说过run() 描述线程要做的事情，而真正让线程独立运行的是 start()；只有调用 start()，底层才会真正创建新的线程。

所以我们要了解 start()我们就得了解这个方法：

会发现真正底层启动线程的工作是由 start0 这个方法完成的。从 native 可以看出这是一个本地方法或者说是Java 标准库/JVM 提供的方法，由 C++ 语言编写的方法。本质上是调用系统的 API，不过这对于我们学习 Java 目前应该不是那么必要。

3.4 中断一个线程

假设我们面对一个情境：

前面已经把员工成功招进公司，也知道怎么查看他的名字、状态这些信息了，但现实中老板安排下去的任务也不一定非得执行到底。

比如现在李四正在疯狂转账：

李四：老板放心，钱马上就转过去了。

结果老板突然接到电话：

“别转了！对面是骗子！”

那现在就有一个问题：

李四这个线程都已经开始执行了，我该怎么通知他赶紧停下来？

当然，Java 不是粗暴将它 thread.kill()掉，而是采用通知的方式告诉他你该停了。此时线程就会收到通知，但是否停止、什么时候停止就由线程的代码自己决定。

我学习到的常见就是以下两种方法：

1. 通过共享的标记来进行沟通；
2. 调用 interrupt()方法通知；

示例一：共享变量作为标志位（标志位要加上 volatile）

class MyRunnable implements Runnable {

    public volatile boolean isQuit = false;

    @Override
    public void run() {
        while (!isQuit) {
            System.out.println(
                    Thread.currentThread().getName()
                    + "：别管我，我忙着转账呢！"
            );
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        System.out.println(
                Thread.currentThread().getName()
                + "：啊！险些误了大事"
        );
    }
}
public static void main(String[] args)
        throws InterruptedException {
    MyRunnable target = new MyRunnable();
    Thread thread = new Thread(target, "李四");
    System.out.println("让李四开始转账");

    thread.start();
    Thread.sleep(10 * 1000);
    System.out.println("老板来电话了，对方是骗子！");
    target.isQuit = true;
}

此处的 volatile 关键字我们后面再继续专门讲解，这里先不用钻太深~

现在可以先简记为：volatile isQuit就是为了让一个线程修改以后，另外一个线程能够及时看到。

上面的代码流程如下：

共享变量此处再补充一个点：

如该例子：（我也不知道为什么截 IDEA 里就是这么糊）

Java 要求 Lambda 捕获的局部变量必须是：

final 或者 effectively final（实际没有被修改）

这里是触发“变量捕获”这样的语法，Lambda 是回调函数，执行时机是很久之后（操作系统真正创建出线程知乎偶，才会执行的）

所以很有可能，后续线程创建好了，当前 main 这里的方法都执行完了对应的 isFinished 就销毁了。所以为了解决上述的问题：

Java 将被捕获的变量给拷贝一份，拷贝给 Lambda 里面。外面的变量是否销毁，就不影响 Lambda 里面的执行了。

但是拷贝，就意味着这样的变量不适合进行修改。因为修改一方，另一方不会随之变化的（本质上是两个变量），所以 Java 语言的大佬就不允许在这里进行修改~

上面图片中可以利用成员变量（也就是定义在类里面、方法外面的变量，它属于对象或类）

public class Demo5 {
    private static boolean isFinished = false;
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(() -> {
            while (!isFinished) {
                System.out.println("Hello Thread");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    //somefunc...
                }
            }
            System.out.println("t 结束");
        });

        t.start();
        Thread.sleep(3000);
        System.out.println("main 线程尝试终止 t 线程");
        isFinished = true;
    }
}

但这里有一个隐患，就是线程之间可能看不到最新值，也就是存在可见性问题，涉及到 volatile，我们先保留该问题；但主要还是应为 CPU 缓存机制

示例二：使用interrupt通知线程

class MyRunnable implements Runnable {
    @Override
    public void run() {
        while (!Thread.currentThread().isInterrupted()) {
            System.out.println(
                    Thread.currentThread().getName()
                    + "：别管我，我忙着转账呢！"
            );
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                System.out.println(
                        Thread.currentThread().getName()
                        + "：收到老板的中断通知！"
                );

                // sleep 被 interrupt 后，中断标志会被清除
                // 因此这里直接 break 结束循环
                break;
            }
        }
        System.out.println(
                Thread.currentThread().getName()
                + "：啊！险些误了大事"
        );
    }
}

public class Main {
    public static void main(String[] args) throws InterruptedException {
        MyRunnable target = new MyRunnable();
        Thread thread = new Thread(target, "李四");
        System.out.println("让李四开始转账");
        thread.start();
        
        // 老板 10 秒后发现被骗
        Thread.sleep(10 * 1000);
        System.out.println("老板来电话了，对方是骗子！");

        // 通知李四线程停止
        thread.interrupt();
    }
}

Interrupt你可以先理解为老板让你先停一下，而不是让你人间蒸发。当然啦，老板的话听不听也可以取决于你~

interrupt() 的核心是通知线程发生了中断，而不是直接强制终止线程。

既然说到了 interrupt()那其实就还有一种方法，就是Thread.interrupted()也能判断

while (!Thread.interrupted()) {

}

它也可以用来检查当前线程的中断状态。注意是当前线程，因为Thread.interrupted()是静态方法。不过我们还要了解一个方法，就是 thread.isInterrupted()，它们存在一定区别。

如果在线程自己的代码中判断中断状态，经常会写成 Thread.currentThread().isInterrupted()。其中 Thread.currentThread() 获取的是当前正在执行这段代码的线程，然后再通过 isInterrupted() 查看它的中断状态。它们有个区别需要记一下：

thread.isInterrupted()读取中断标志后不会清除这个标志；

Thread.interrupted()读取中断标志后会清除这个标志；

就拿下面代码举个例子：

public class Demo4 {
    public static void main(String[] args) {
        Thread.currentThread().interrupt();
        System.out.println(Thread.currentThread().getName() + "+" + Thread.interrupted());
        System.out.println(Thread.currentThread().getName() + "+" + Thread.interrupted());
    }
}
// 得到结果
// main+true
// main+false

Thread.interrupted() 在获取当前线程中断状态的同时，还会将中断状态清除。因此第一次调用得到 true 后，如果中途没有再次调用 interrupt()，第二次调用就会得到 false。

public class Demo4 {
    public static void main(String[] args) {
        Thread.currentThread().interrupt();
        System.out.println(Thread.currentThread().getName() + "+" + Thread.currentThread().isInterrupted());
        System.out.println(Thread.currentThread().getName() + "+" + Thread.currentThread().isInterrupted());
    }
}
// 得到结果
// main+true
// main+true

而这里的 interrupted 是读取线程的状态而不是去修改（刚好也出现了后面要说的 volatile）

如果线程正好在 sleep()：

到这的话就有点意思了，假设李四正在干活：

while (!Thread.currentThread().isInterrupted()) {
    System.out.println("工作");
    Thread.sleep(1000);
}

此时老板打来个电话，thread.interrupt()

刚好李四又在睡觉sleep()，Thread.sleep() 本身声明了可能抛出 InterruptedException。如果线程正在 sleep() 的过程中，其他线程对它调用了 interrupt(),李四这线程就会被唤醒并抛出InterruptedException；此时被 catch 到了，那么接下来需要干什么就取决于 catch 里的内容了，可以跳出也可以继续执行；

public class Demo2 {
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(()->{
            while(!Thread.currentThread().isInterrupted()) {
                System.out.println("Hello Thread");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    /*throw new RuntimeException(e);*/
                    /*Thread.currentThread().interrupt();*/
                }
            }
            System.out.println("t 结束");
        });
        t.start();

        Thread.sleep(3000);
        System.out.println("main 线程尝试终止 t 线程");
        t.interrupt();
    }
}

因为收到 InterruptedException 并不代表 Java 自动决定这个线程必须结束。

对于这部分解释，正常来说，调用 Interrupt 方法就会修改 isInterrupted 方法内部的标志位（设置为 true），由于上述代码中，是把 sleep 给唤醒了，这种提前唤醒的情况下，sleep 就会在唤醒之后，把 isInterrupted 标志位给设置回 false。

所以在这样的情况下，如果继续执行到循环的条件判定，就会发在能够继续执行~

3.5 等待一个线程 - join()

我们前面知道了如何让线程暂停，但现实中还有另一种情况：

就是我的工作必须等你的工作做完以后才能继续

假设李四负责：

整理今天公司的转账记录；

而我负责：

根据李四整理出来的数据统计今天到底赚了多少钱；

那我肯定不能李四刚开始整理，我这边就直接开始统计。为了解决这种情况，Java 中就引入了join()，来看个例子：

public class Demo {
    public static void main(String[] args)
            throws InterruptedException {
        Thread t1 = new Thread(() -> {
            System.out.println("李四开始整理数据");
            try {
                Thread.sleep(3000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("李四整理完成");
        }, "李四");

        t1.start();
        t1.join();
        System.out.println("main：开始统计数据");
    }
}

注意哈这地方容易弄反，在主线程中调用 join 得用到 t1 对象；也就是说调用join()的那个线程才是真正等待的。

main 等待 t 线程 <-----> t.join()

说实话，这里主要是按正常语言逻辑不太符合主谓宾习惯，但我们可以反过来理解

t 线程合并入 main（合并前提，必然是 main 存在）

两个执行流合并为一个，一个执行流结束，另一个继续执行；

join 提供了带参数的版本，就是指定“超时时间”即等待的最大时间~

就像是你约了女神上午 8 点出来，最后女神 12 点才到；你继续在这里傻等就是“感动自己”~

3.6 获取、休眠当前线程

很明显这是个静态方法，也就是说哪个线程调用这个方法，返回哪个线程的引用，类似 this；

Thread.sleep()是让调用它的当前线程休眠；

从上面多个例子你会发现，实例中往往都有

throws InterruptedException

// 或者以下

try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
}

原因还是之前说的，线程睡眠期间，可能被其他线程通过 interrupt 方法打断提前醒来，它和 sleep、join、wait 这三个方法也一样密切；

注意:

sleep(0)不是不休眠，而是意味着让当前的线程立即放弃 CPU 资源，等待操作系统重新调度~

4.线程状态

Java 中一共有 6 种状态：

不过要注意：RUNNABLE 不完全说是线程一定正在运行；Java 中把正在运行和等待 CPU 调度都归到 RUNNABLE 状态；提到这我们可以联系到之前关于操作系统的进程的两个状态：就绪状态和阻塞状态；

4.1 线程状态的转换

NEW 状态其实就是 new 了 Thread 对象，还没有 start()

TERMINATED 状态是线程已经做完了他该做的了，内核中的线程已经结束，但 Thread 对象还在；

RUNNABLE 状态就是刚刚提到的，可工作，有可分成正在工作中和即将开始工作；

TIMED_WAITTING 状态描述的是指定时间的阻塞，当等待时间结束后，线程会自动恢复到可运行状态，重新参与 CPU 调度；也就是：

• 有明确的等待时间
• 等待时间到了以后，线程不会一直停留
• 线程是否立即执行取决于 CPU 调度

WAITING 状态表示无限等待状态，例子有thread.join()，会一直等待，等到天荒地老；

BLOCKED 状态表示阻塞状态，在我们后面继续了解锁的时候会重点遇到；

NEW --> RUNNABLE --> TIMED_WAITING --> TERMINATED 转换如下：

public class Demo6 {

    public static void main(String[] args) throws InterruptedException {
        Thread thread = new Thread(() -> {
            try {
                Thread.sleep(3000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });

        System.out.println(thread.getState());
        thread.start();
        System.out.println(thread.getState());
        Thread.sleep(1000);
        System.out.println(thread.getState());
        thread.join();
        System.out.println(thread.getState());
    }
}

// 输出结构：
// NEW
// RUNNABLE
// TIMED_WAITING
// TERMINATED

对于上面的结果，解释 RUNNABLE、TIMED_WAITING：

在第二个输出状态时，主线程由于本身就在运行，在创建新的线程时会需要进过调度，所以通常运行上述代码都是 main 先跑到第二个状态打印，虽然此时 thread 线程已经启动，但还没进入 sleep(3000)，这也是为什么后面还需要 main 线程先 sleep(1000)的原因；

而 WAITING 状态就如下演示：

public class Demo6 {

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            try {
                Thread.sleep(100000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        },"t1");
        Thread t2 = new Thread(() -> {
            try {
                Thread.sleep(1000);
                t1.join();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        },"t2");

        t2.start();
        t1.start();
    }
}

如果让 t2 自己打印自己的状态，就会受到执行时机影响，所以通常用外部工具观察线程状态，如下：

4.2 多线程带来的问题

直接先抛出一例子：

public class Demo7 {
    public static int count;
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                count++;
            }
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                count++;
            }
        });


            t1.start();
            t2.start();
            t1.join();
            t2.join();
        System.out.println(count);
    }
}

写 join 的原因是避免 main 线程先执行完，所以应该先等到两个线程并入 main 线程后再执行打印

执行后会发现，count 结果是一个随机数，而且还是随机小于 100000 的数字；像这样导致结果和预期不符合的就属于 BUG，需要修复，这也是多线程并发执行容易引起的安全问题；

深入一下底层会发现：count++看似是一行代码，实际上对应到的是 3 个 CPU 指令

1. load：将内存中 count 的值加载到 CPU 寄存器
2. add：把寄存器中的内容 +1
3. save：把寄存器中的内容保存回内存上

并且现代计算机操作系统都是抢占式调度，意思就是：

即使一个进程（或线程）还没有执行完，操作系统也可以强制暂停它，把 CPU 分配给其他进程。

也就说明，上面的代码中执行这三个步骤会是随机的、不可预期的

左侧是我们所预期的，但实际会是右边这种，当然这样的情况有很多种；

右侧的操作过程描述：

假设当前内存上的值为 0；

t1 线程会先去读取内存的 0 并加载到当前寄存器上，也就是拷贝一份

随后 t2 也进行了同样的操作，但它先完成了 add 并最终存入内存中，此时内存的值为 1

但此时 t1 线程还是在之前加载的 0 上面进行操作运算，最后得到值为 1 并覆盖掉 t2 线程得到的 1 放在内存上

所以在上面的代码 5w 次循环过程中，中间会发生很多类似的操作，最终的值一定是 <=10w；

对于发生线程安全问题通常有以下：

1. 操作系统对于线程的调度是随机的，也就是操作系统抢占式【根本原因】；
2. 多个线程同时修改同一个变量；
3. 修改操作，不是原子；
4. 内存可见性问题；
5. 指令重排序；

前两个问题我们已经讨论出，我们具体讨论 2 和 3 ，4 和 5 留到后面

问题 2：

对于多个线程修改同一变量，我们只能通过调整代码结构去规避一些线程不安全的代码，但这方案不够通用；Java 中有个东西，String 就是采取了“不可变”特性，确保线程安全；

String 实现“不可变”的效果是将内部的 char 数组设为 private（与 final 无关），导致无法访问，因此无法修改；

问题 3：

此处所说的原子性，就是指是数据库里事务提到的 ACID 中的原子性；

如果修改操作只是对应到一个 CPU 指令就可以认为是原子的，CPU 不会出现“一条指令执行一半”，但是如果对应到多个 CPU 指令就不是原子的，比如：++、--、+=、-=......；

原子性：

上面图片中被两个客户端并发拆开了，但【检查+扣减】应该作为一个整体，不可拆开；

所以在 Java 中解决线程安全问题最主要的方案就是加锁。

通过加锁操作，让不是原子的操作，打包成一个原子的操作；

计算机中的锁与生活中的锁，是同样的概念。互斥/拍他

这也就是下一节我们要讲的~

对了，对于上面的线程安全问题，我们这样解决：

public class Demo7 {
    public static int count;
    public static void main(String[] args) throws InterruptedException {
        Object locker = new Object();
        Thread t1 = new Thread(() -> {
            synchronized (locker) {
                for (int i = 0; i < 50000; i++) {
                    count++;
                }
            }
        });
        Thread t2 = new Thread(() -> {
            synchronized (locker) {
                for (int i = 0; i < 50000; i++) {
                    count++;
                }
            }
        });

            t1.start();
            t2.start();
            t1.join();
            t2.join();
        System.out.println(count);
    }
}

5.synchronized 关键字

Java 中的 synchronized本质就是加锁；但要注意，有时候也不是写了 synchronized 就 100%线程安全，这个需要具体代码具体分析~

拿一段代码举个例子：

public class Demo6 {
	public static void main(String[] args) {
		Object o1 = new Object();
		Object o2 = new Object();
		Thread t1 = new Thread(() -> {
			synchronized(o1) {
				try {
					Thread.sleep(100000);
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
			synchronized(o2) {
				System.out.println("t1线程两个锁都获取到");
			}
		});
		Thread t2 = new Thread(() -> {
			synchronized(o1) {
				try {
					Thread.sleep(100000);
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
			synchronized(o2) {
				System.out.println("t2线程两个锁都获取到");
			}
		});

		t1.start();
		t2.start();
	}
}

当这段代码开始运行后，可以调用 jconsole 去查看一下线程状态；

此时可以看到 t2 线程处于 BLOCKED 状态，也就是我们之前所说的阻塞状态；这里阻塞的原因就是 t1 线程上锁 o1 之后一直 sleep。此时线程 t2 想同步运行，但是锁在 t1 手上，所以 t2 第一段代码就执行不了，必须等到 t1 线程释放锁之后 t2 才能继续运行。这就是前面提到的 BLOCKED 阻塞状态；

5.1 synchronized 的特性

5.1.1 互斥性

我们首先需要知道锁是什么，在生活中好很理解：

对，这就是锁，因为厕所只能容纳一人，当他进去时就得上锁，出来时就得解锁；在代码中就这样理解，一个线程先上了锁，其他线程只能等待这个线程释放，这也就是互斥的含义；

synchronized中文名叫：同步锁；在 JVM 层面对应的是：Monitor Lock 监视器锁

也就是说每一个 Java 对象都可以关联一个监视器；

它在代码中的流程：

Thread t1 = new Thread(() -> {
    synchronized (locker) {
        for (int i = 0; i < 50000; i++) {
            count++;
        }
    }
});

尝试获取对象对应的锁 -> 获取成功 -> 执行代码 -> 释放锁

如果锁已经被其他线程占用，那么线程就会等待，直到其他线程释放锁，这中间还会存在锁竞争；

至于为什么需要互斥，就拿之前的火车票问题来说，只剩一张票了，两个客户端申请访问时必须只能一个一个访问，而不能并发访问；

以上就是互斥的必要性；

5.1.2 可重入性

synchronized 第二个特点就是：可重入性

引入可重入的概念目的其实就是为了解决死锁问题，那么什么是死锁问题？

假如下方的代码是不可重入的，那么当已经进入锁住状态的方法一调用方法二时，由于锁已被用且还未释放，因此方法二无法加锁且无法进入。最后就导致阻塞等待，两个方法都无法继续往下执行；

可重入性概念刚理解可能不太好明白，意思是：

一个线程已经拥有某把锁之后，可以再次进入有同一把锁保护的代码；

比如：

public class Demo {
    synchronized public void method1(){
        method2();
    }

    synchronized public void method2(){
        System.out.println("执行method2");
    }
}

当前线程调用method1()方法，线程 A 进入method1() -> 获得对象锁 -> 调用method2() -> method2()也是 synchronized；

又或者像是这样：

synchronized (counter) {		// 1.此处开始锁住
    synchronized (counter) {		// 2.直接放行
        synchronized (counter) {		// 3.直接放行
            counter.add();
        }	// 3->2 退出第三层
    }	// 2->1 退出第二层
}	// 1->0 退出第一层

至于 JVM 如何知道哪个“}”是真正要解锁的那个呢？

JVM 执行的是 .class 字节码，不是 Java 源代码里的 {}。
synchronized 代码块之所以能正确加锁、解锁，是因为编译器会把它编译成专门的字节码指令，而不是 JVM 运行时去判断“这个 } 属于谁”。

如果synchronized不可重入，这里就会发生线程 A 访问method2()时一直等待释放锁，因此会永远等待，也就是发生死锁；但由于可重入性的原因，因此此处不会发生阻塞；

5.1.3 死锁问题（重）

关于死锁问题，已经在上面初步解释过了，就再具体说一遍：

死锁就是

家钥匙锁车里了，车钥匙锁家里了

很好理解吧~

构成死锁主要有这四个必要条件（重点）

1.锁是互斥的。一个线程拿到锁之后，另一个线程再尝试获取锁，必须要阻塞等待；（锁的基本性质）

2.锁是不可抢占的。线程 1 拿到锁，线程 2 也尝试获取这个锁，线程 2 必须阻塞等待，而不是线程 2 直接把锁抢过来；（锁的基本特性）

3.请求和保持。一个线程拿到锁 1 之后，不释放锁 1 的前提下，获取锁 2

4.循环等待。多个线程、多把锁之间的等待过程构成“循环”

以上 1、2 点至少 Java 的 synchronized 是遵守这两点，

破坏掉上述的 3 或 4 任何一个条件都能够打破死锁；

（打破 3：把嵌套的锁改为并列的锁）

（打破 4：加锁的顺序做出约定）

在代码中构成死锁问题通常有下面三种情况：

情况一：两个线程、两把锁交叉等待

Thread t1 = new Thread(() -> {
    synchronized (lockA) {
        synchronized (lockB) {
        }
    }
});

Thread t2 = new Thread(() -> {
    synchronized (lockB) {
        synchronized (lockA) {
        }
    }
});

这是 Java 中典型的死锁，如果执行成这样

t1：拿到 A

t2：拿到 B

t1：等待 B

t2：等待 A

这就死锁了，这也可以叫所顺序不一致导致的死锁；注意我说的是如果，因为线程 t1 与 t2 是并发的，有可能 t1 和 t2 一样快，有可能 t1 比 t2 快...这样的结果是不确定的。

针对情况一就是同一加锁顺序，也就是说如果：必须同时获取多把锁，所有代码必须按照固定顺序获取。

情况二：哲学家就餐问题（多线程、多资源形成环形等待）

假设有 5 个哲学家，每个人面前都有一根筷子，总共 5 根，每个哲学家必须左筷子+右筷子才能吃饭。

换成代码就是这样理解：5 个人就相当于 5 个线程、5 根筷子就相当于 5 把锁，每个线程只需要拿到其中两根筷子即可~

大部分情况下上述模型可以很好的运转，只是在一些极端情况下会造成死锁，譬如：

同一时刻，大家都想吃面条，同时拿起左手的筷子

虽然上述情况的概率很小，但是只要基数足够大，任何小概率事件都是大事件；

针对情况二给出两种解决方法：

方法一：规定筷子获取顺序，让所有哲学家统一遵守“先拿编号小的，再拿编号大的”。

方法二：最多允许 4 个哲学家同时拿筷子，此时至少有一个哲学家有机会凑齐两根筷子，也就是限制同时参与资源竞争的线程数量。

5.2 synchronized使用示例

synchronized 本质上要修改指定对象的“对象头”。从使用角度看，synchronized 也是必要搭配一个具体的对象来使用；

5.2.1 synchronized 修饰代码块

这里要明确指定锁哪个对象。

格式：

synchronized(锁对象){
    // 需要保证线程安全的代码
}

synchronized(lock){
    count++;
}

前面已经解释过，线程进入代码块 -> 尝试获取 lock 对象的锁 -> 获取成功 -> 执行 count++ -> 释放 lock 锁

如果此时另外一个线程也执行synchronized(lock)，那么因为他们使用的是同一个 lock 所以只能排队。

至于为什么一定要是同一个对象，是因为两个线程，针对同一个对象加锁，才会产生互斥效果；如果是不同的锁对象，此时不会有互斥效果，线程安全问题就没有得到改变...

这里提到的锁对象，关于这个对象的类型是什么并不重要（在 Java 中任何一个对象都可以用作'锁'），重要的是是否有多个线程尝试针对这同一个对象加锁（是否在竞争同一个锁）

再拿前面的多线程 50000 次循环并发举例：

Thread t1 = new Thread(() -> {
    for (int i = 0; i < 50000; i++) {
        synchronized (locker) {    
            count++;
        }
    }
});

Thread t1 = new Thread(() -> {
    synchronized (locker) {
        for (int i = 0; i < 50000; i++) {
            count++;
        }
    }
});

以上两段代码看似运行结果相同，但实际运行过程差别很大，特别是在效率上；

这是代码一的运行过程：

这是代码二的运行过程：

至于为什么 Java 中不使用 lock + unlock 函数的方式的话，这个就有点意思了：

当然其实 Java 中也是有 lock/unlock 风格的锁，但一般很少用，因为...

Lock locker  = new Locker();
public void func() {
locker.lock();
// something code
locker.unlock();

这样的写法其实会容易忘记把 unlock 补上，就会导致其他线程死锁；

你要是说“只要我写了 lock，就会立即加上 unlock~”，那你纯纯就是大猪蹄子行为；

就像是你给女朋友保证，这辈子我只爱你一个，永远不会变心~

再来个例子：

void func() {
    lock();

    if (cond) {
        unlock();
        return;
    }

    if (cond2) {
        unlock();
        return;
    }
    func2();
    
    unlock();
}

其中 func2()又是调用：

void func2() {
    func3();
}

void func3() {
    func4();
}

void func4() {
    throw new Exception();
}

此时，代码中抛出异常，那么也有可能使 unlock 执行不到~

所以 Java 中采取 synchronized 就能保证，只要出了“}”一定能释放锁，无论因为 return 还是因为异常里，也无论里面调用了哪些代码，都是可以确保 unlock 操作执行到的；

5.2.2 synchronized 修饰普通方法

synchronized 还可以直接修饰方法：

public class Counter {
    private int count;
    public synchronized void increment(){
        count++;
    }
}

其实像是 StringBuffer、Vector 这些对象，方法上就是带有 synchronized：

所以会说这些对象会线程安全；

不过如果 synchronized 修饰的是静态方法的话，就相当于针对类对象加锁（从反射可以了解）；

• synchronized 修饰普通实例方法：锁的是 this
• synchronized 修饰静态方法：锁的是当前类对应的 Class 对象，也就是 类名.class

例如：

public class Counter {
    private int count;
    public synchronized void increment(){
        count++;
    }
}

此处：

public synchronized void increment()

等价于：

public void increment(){
    synchronized(this){
        count++;
    }
}

也就是说：

普通 synchronized 方法锁住的是当前对象。

在实际中通常会是这样：

Counter counter = new Counter();

然后会这样去调用counter.increment()，实际上锁的是 counter 对象，也就是 this==counter

然后多个线程：

Thread t1 = new Thread(() -> {
    counter.increment();
});

Thread t2 = new Thread(() -> {
    counter.increment();
});

此时线程 A：

获取 counter 对象锁

执行 increment

线程 B：

等待 counter 对象锁

而如果是：

Counter counter1 = new Counter();
Counter counter2 = new Counter();

这样的话两个线程分别尝试获取两把不同的锁，就不会产生竞争；

当然啦你也可以这样去理解：

代码块：

synchronized(lock)就像指定某个房间上锁；锁是指 lock 房间

普通方法：

synchronized method就像是给当前员工办公室上锁；锁是指当前员工对象

静态方法：

static synchronized method就是给整个公司总部上锁；这里的锁就是指整个 Class

锁虽好，但不可贪~

synchronized(lock){
    // 很多代码
}

可能会多人会犯这样一个错误，虽然线程安全，但是效率可能就不太好。因为真正需要保护的可能就只有count++，就像我前面举过的例子：synchronized (locker)放在 for 循环内与 for 循环外的对比。当你锁住的代码越多，线程等待的时间就越长，并发能力就越低。所以在实际开发中：

synchronized 的范围应该尽量控制，只保护真正需要同步的数据~

6.volatile 关键字

在前面讲线程安全问题的时候，提到过几个容易引发问题的原因：

原子性、内存可见性以及指令重排序

其中原子性的问题就在上面的synchronized已经大概了解如何处理了，但还有一个一直被搁置的问题：

一个线程修改了变量之后，为什么另一个线程有时候看不到？

当然前面其实遇到过一次，在中断线程的时候写过：public volatile boolean isQuit = false;

当时只是说“加上 volatile 后，一个线程修改 isQuit，另外一个线程能够及时看到。”

那现在就来正式解释一下~

6.1 内存可见性

先来举个例子：

假设老师布置作业后，让课代表把作业内容卸载教室后面的黑板上：“今日作业：完成练习册第 10 页”

这个黑板相当于全班同学都能看到的公共信息区域。

但是张三觉得每次回头看黑板太麻烦，于是第一次看到作业后，就把内容记在自己的草稿纸上：“今日作业：完成练习册第 10 页”

李四也记了一份自己的。后来老师临时修改了作业，于是让课代表把后黑板改成：“今日作业：完成练习册第 10～12 页”

此时，黑板上的内容已经更新了。

但问题来了：

如果张三之后一直只看自己之前记下来的草稿纸，而没有重新去看后黑板，他看到的仍然只会是“今日作业：完成练习册第 10 页”

张三并不知道公共信息已经发生了变化。这就很像多线程中的内存可见性问题：

一个线程已经修改了共享变量，但是另一个线程没有及时看到这个变量的最新值。

对于上述这样的情况，你可以抽象理解为“主内存”和“线程工作内存”模型

代码示例：

public static int flag = 0;
public static void main(String[] args) {

    Thread t1 = new Thread(() -> {
        while (flag == 0) {
            
        }
        System.out.println("t1 线程结束");
    });

    Thread t2 = new Thread(() -> {
        // 针对 flag 进行修改
        Scanner scanner = new Scanner(System.in);
        System.out.println("请输入 flag 的值：");
        flag = scanner.nextInt();
    });
    t1.start();
    t2.start();
}

这段代码当运行起来后，输入任何数字后按单线程的思想应该不进入循环而停下来，但事实并非

显然这是一个 BUG（线程安全问题）

一个进程读取，一个进程修改，修改线程的值，并没有被读线程读到。这也就是要说的“内存可见性问题”

其实上面的问题是，每个线程在读取主内存的时候都会先拷贝一份放到自己的工作内存中，如果要修改就会先在自己的工作内存中完成修改，随后就将修改好的值放入主内存中。但是由于 t1 只是进行读操作，它只会去读相对较近的内存（也就是 t1 的工作内存）

线程在运行过程中，并不一定每一次使用变量都重新读取共享区域中的最新结果，而可能使用自己工作内存中的值。我所说的“工作内存”可以先抽象理解为 CPU 寄存器、缓存有关的区域，因为访问这些位置速度更快，但也可能产生数据不一致。

产生这样的原因：

研究 JDK 的大佬们就希望通过让编译器 & JVM 对程序员写的代码，自动的进行优化

本来写的代码是进行 xxxxx，编译器 / JVM 会在你原有逻辑不变的前提下，对你的代码进行调整，是程序效率更高

JVM 和 CPU 为了提高执行效率，可能会对变量读取、缓存以及指令执行进行优化。在单线程环境中，这些优化不能改变程序原有语义；但在多线程环境下，如果程序没有通过 volatile、synchronized 等机制建立正确的线程间同步关系，就可能出现一个线程无法及时观察到另一个线程修改结果的情况~

上面的过程细化理解就是：

while (flag == 0) {

}

load 为读内存操作，cmp 是 CPU 寄存器操作；load 的时间开销可能是 cmp 的几千倍

其中的flag == 0为 cmp 运算操作，而比较操作又细化为 load、cmp（加载、运算）短时间内这个循环会进行很多次，执行过程中 JVM 感知到 load 反复执行的结果好像都是一样的。JVM 就会想：执行这么多次读 flag 操作发现值都为 0，既然结果一样，为什么还要反复执行这么多次呢~

于是就把读内存的操作优化成读寄存器（把内存的值读到寄存器了，后续再 load 就不再重新读内存）

此后，等到用户开始输入新的值真正修改 flag 时，t1 线程就感知不到了；当然如果引入 sleep 去等用户输入的话，那样效率又太低了；

于是就引入了 volatile 关键字，通过这个关键字来修饰某个变量，此时编译器这对这个变量的读取操作就不会被优化成寄存器了

public volatile static int flag = 0;

volatile解决了内存可见性问题·，但不是解决原子性问题；

6.2 JMM Java 内存模型

前面我们提到的“主内存”和“线程工作内存”模型其实就是 JMM，其含义你可以理解为：

Java 用来规定“多个线程之间如和读写共享变量，以及这些读写什么时候对线程可见”的一套规则。

在 Java 官方文档的描述中：

每个线程，有一个自己的“工作内存”，同时这些线程共享同一个“主内存”，当一个线程循环进行上述读取变量操作的时候，就会把主内存中的数据拷贝到该线程的工作内存中。后续另一个线程修改，也是先修改自己的工作内存，拷贝到主内存里。由于第一个线程仍然在读自己的工作内存，因此刚知不道主内存的变化。

这与我们前面讲到的把读内存的操作，优化成读寄存器操作是一样的意思。

以及上面所说的“工作内存”（work memory）就是指与 CPU 寄存器、缓存等相关的区域；

然后明确synchronized 能够保证原子性，而 volatile 保证的是内存可见性。

好了，以上就是关于 volatile 的内容...

7.wait 和 notify

前面学习多线程的时候，一直在强调一件事：

多个线程之间的执行顺序通常是不好控制的

谁先拿到 CPU、谁先执行，本身就带有一定随机性，但实际开发里肯定是不能“各干各的”。线程里一定也是存在“ 你先做完，我再继续”的协作关系。

所以 Java 就因此提供了：wait()、notify()、notifyAll()来实现线程之间的等待和唤醒；注意wait()、notify()、notifyAll()都是 Object 类的方法，所以 Java 中的任意对象都提供了 wait()和 notify()。

wait()/wait(long timeout)：让当前线程进入等待状态；

notify()/notifyAll()：唤醒在当前对象上等待的线程；

7.1 wait() 方法

从上面我们知道了 wait()方法的作用是：让当线程先别干了，进入等待；

比如：

Object lock = new Object();

Thread t1 = new Thread(() -> {
	synchronized (lock) {
		System.out.println("开始等待");
		lock.wait();
		System.out.println("等待结束");
	}
}

当执行到lock.wait()时候线程就会停下来，至于后面要打印的内容就不会立即执行了；

此时当前线程主要会经历这样三个过程：

当前线程进入等待状态 -> 释放当前持有的 lock 锁 -> 以后被唤醒时，再重新尝试获取 lock 锁

其中的释放锁这一步很关键；

那至于为什么要释放锁呢，继续举个例子：

（财务室在synchronized (lock) {}中）

假设李四进入财务室，此时李四手里拿着钥匙，然后李四发现：“我现在还缺一份材料，得等王五送过来。”

于是此时就调用 lock.wait()，然后王五想进财务室送材料：“钥匙还在李四手里，我进不去”

那么李四：“材料不来我就不继续 ”，接着王五：“你不放钥匙我就送不进去”

这个时候两个人就直接卡住了，所以所以 wait()必须要释放锁让王五进来。

当然啦，如果你wait()不写在 synchronized 中就会抛异常~

而wait()要等到什么时候呢？

wait()默认是一直等，等到被唤醒，所以它对应的状态通常就是 WAITTING 状态，但wait()是提供带参数的，时间参数单位是毫秒。然后关于wait(0)，类似于sleep(0)，不是等待 0 毫秒，而是无限期等待，直到被 notify()、notifyAll() 唤醒，或者线程被中断。

ok 我们上面也说了“notify()、notifyAll() 唤醒，或者线程被中断”通常就是这三种方式能把wait()唤醒。其中关于线程被中断这点，是指另外一个线程直接 thread.interrupt()，那么等待的线程会通过InterruptedException收到通知，与前面的 sleep()、join()是同一类思路；

但是wait()会释放所，而 sleep()不会释放锁~

注意被 notify 唤醒，不代表线程马上执行。因为线程醒来以后，会先从 ：

WAITING 状态出来 -> 重新去竞争那把 lock -> 拿到所以后 -> 才能继续执行 wait() 后面的代码

被唤醒以后，线程并不能马上继续执行，而是需要重新参与这把锁的竞争。什么时候真正拿到锁，仍然由线程调度决定。

记得要求 synchronized的锁对象必须和wait的对象是同一个；

7.2 notify()方法

然后接着刚才说的，李四进入到财务室然后睡着了，王五已经把材料放在桌子上，这个时候问题随之而来：

李四都已经睡着了，谁来告诉他“别睡了，可以继续干活了”？

这个时候就需要 notify()，而notify()的作用确实就是唤醒一个正在当前对象上**wait()**的线程；

当然了，既然wait()要配上synchronized，那notify()也是必须得配上synchronized使用了。因为他们都是围绕着同一个对象对应的monitor锁进行协调。所以这边必须对应一把锁。

对了，务必还要确保先wait()，后 notify()。相反如果先notify()那么wait()也就无法唤醒。

比如：

public class Demo {
    public static void main(String[] args)
            throws InterruptedException {

        Object lock = new Object();
        Thread t1 = new Thread(() -> {=
            synchronized (lock) {
                System.out.println("李四：材料没来，我先等等");
                try {
                    lock.wait();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("李四：材料到了，继续工作");
            }
        }, "李四");

        Thread t2 = new Thread(() -> {
            synchronized (lock) {
                System.out.println("王五：材料送到了");
                lock.notify();
                System.out.println("王五：我已经通知李四了");
            }
        }, "王五");

        t1.start();
        Thread.sleep(1000);
        t2.start();
    }
}

以上代码的执行过程就如下方：

注意上面所描述到的“李四重新竞争 lock”，李四的线程并不是接着马上就向后运行，而是重新与其他线程相互竞争；当然，也不是 notify 唤醒后 wait 马上就进入工作的...

那有个问题，假如有多个线程都在 wait 呢？

notify 还是规定只能唤醒一个，但是具体叫醒谁，并没有固定保证。但是如果想唤醒全部 wait 就可以用到 notifyAll；可以这样理解：notify 就是“老师面对三个趴桌子睡觉的人喊：起来一个帮我搬书！”，那么起来的是谁不一定；而 notifyAll 就是老师对这三个人都点名，让他们都起来去搬书。

然后在这里就可以区分 WAITING 和 BLOCKED了，假设李四调用了 lock.wait()，那么李四就是 WAITING（因为他主动释放锁，并通知被人等待），此时王五拿着 lock，赵六也想拿到锁但进不去，那赵六就是 BLOCKED。

7.3 notifyAll() 方法

（本来不想写 7.3，但是想了想还是需要补充一下哈）

前面举的这个例子，“老师面对三个趴桌子睡觉的人”如果想都叫醒就是用 notifyAll，但是调用了lock.notifyAll()也并不是三个线程马上一起执行后续代码，只是三个线程被唤醒，但还是需要重新竞争原来的那把锁。

7.4 wait() 和 sleep()的区别

到这里，我们已经很清晰的知道了 wait 和 sleep 完全没有可比性，毕竟一个是用于线程之间的通信，一个是让线程阻塞一段时间；唯一相同的就是都可以让线程放弃执行一段时间.

但还是需要总结下：

1. wait 需要搭配 synchronized 使用，而 sleep 不需要；
2. wait 是 Object 的方法，而 sleep 是 Thread 的静态方法；

我让 GPT 综合给出了一个表格，内容如下：

以 Windows 环境为例，磁盘中的.exe（可执行程序）文件本质上是一个静态程序，里面包含着程序运行所需的机器指令、数据，本身不会执行。只有当操作系统把程序加载到内存，为它分配运行需要的资源，并且让 CPU 执行其中的指令后，这个静态的可执行文件才真正变成一个正在运行的程序。

这个运行的程序实例，就是我想说的进程（Process）

1. 程序与进程

1.1 程序

点击键盘 CTRL + SHIFT + ESC 就会弹出下面这样一个界面，也就是任务管理器，正常会运行上百个进程。了解到这里，就应该想问出进程到底是什么？为什么操作系统需要进程？一个磁盘中的程序，又是如何变成一个正在运行的进程的？

首先得知道：程序不等于进程

程序 = 存放在磁盘上的一组指令和数据

就比如一个这样存放在你的电脑硬盘里的文件：

C:\Program Files\Google\Chrome\Application\chrome.exe

只要chrome.exe还没有启动，他就只是磁盘上的一个程序。

主要因为一下几点：

1. 不占 CPU 执行时间；
2. 没有正在使用的寄存器；
3. 没有自己的运行状态；
4. 没有变化的内存数据；

综上，所以说程序是静态的。

1.2 进程

当我们双击chrome.exe后，事情就不一样了，Windows 操作系统就会开始为它准备运行环境。

补充一下操作系统（Operating System, OS）扮演的角色：

操作系统就是计算机里的“总管 + 调度中心 + 翻译层”，可以理解为酒店里的经理吧或者说公司里的运营官，嗯对；操作系统是介于硬件和软件之间，负责统一管理真正干活的 CPU、内存、硬盘、显卡、网卡...这些硬件，对没错就是牛马们。

这时候呢，操作系统就有以下动作：

此时，它就不再只是一个磁盘中的文件里，而是程序的一次运行实例；

根据上面的描述，我总结出一句：

程序描述“要做什么”，进程描述“程序现在运行到什么状态”

2. 一个进程中有什么

不知道会不会有个疑惑觉得为什么会需要“进程”这个东西？

就比如我当前电脑正在同时运行这些软件：

CPU、内存、磁盘这些资源都很有限，操作系统就得知道哪些程序正在运行、占用了多少内存、谁正在等待 I/O、谁已经准备好运行，以及接下来应该让谁获得 CPU。

所以对操作系统来说，它就会把每一个进程抽象为用一个或多个结构体来描述和管理。

知道上面结果后就会容易想，一个进程中都有什么？或者一个进程运行本身需要哪些东西？

我给出一个简单的模型：

虚拟地址空间本身是一个比较大的话题，涉及代码段、数据段、堆、栈、内存映射...一些内容。这里暂时把它理解为：操作系统为每个进程提供的一套独立的虚拟内存视图，具体的内存管理机制后面有机会再展开~😁

上图其中运行所需的系统资源也包含里很多，比如 Chrome 运行起来后，就会需要内存、网络连接 Socket、文件描述符、权限信息、若干线程。 到这里我们能知道一个进程运行起来，需要代码、数据、内存以及各种操作系统资源。

但是，接着我再抛出一个问题：

“操作系统怎么知道这些东西属于哪一个进程？”

3. PCB：操作系统如何管理进程

上面已经说过“操作系统会把每一个进程抽象为用一个或多个结构体来描述和管理”。但其实，在操作系统原理中，通常把描述和管理一个进程所需要的核心信息统称为 PCB（Process Control Block，进程控制块），它会再把多个进程组织起来。

你可以脑补为这样：

struct PCB {
    int pid;              // 进程编号
    int state;            // 运行、就绪、阻塞……
    registers regs;       // CPU寄存器现场
    memory_info memory;   // 内存信息
    file_info files;      // 打开的文件
    priority prio;        // 优先级
    ...
};

操作系统里就会有很多这样的“进程档案”，但真正的进程包含的东西比这个结构体多得多，我让 ai 给了一份内容：

可以把 PCB 理解为“进程的档案袋”，然后这样一整套运行的程序信息，就被操作系统抽象为一个“进程”。

我整理为一段话就是：

进程是正在运行的程序实例，而 PCB 是操作系统用来描述和管理这个进程的“档案”。

PCB 中的一些关键点：

pid（进程的身份标识符）、内存管理信息（记录或指向进程的地址空间、页表等内存管理结构）、文件描述符表（记录打开了哪些文件/资源的表，这是在 Linux 中用叫法，Windows 常称句柄）、CPU 寄存器（保存进程当前正在使用的数据、地址和运算状态）......

4. 进程是如何被 CPU 运行的

前面说过，PCB 中会记录一个进程当前的状态。但一个进程从创建到结束，并不会一直占着 CPU 运行……实际上，在现如今的操作系统中，同一时间会存在上百甚至上千个进程，而 CPU 的核心数远没有那么多，就拿我的电脑举例：

20 个内核，28 个逻辑处理器你可以理解为：

20 个牛马，其中一些牛马有两张工作台，因此公司排班中能看到 28 个工作位，也就是在干 28 个人的活

也就是说：

想运行的进程很多，但真正能够同时在 CPU 上执行的进程数量是有限的。

所以操作系统就得解决两个问题：

1.一个进程当前到底处于什么状态？

2.CPU 下一步该运行到哪个进程？

这两个问题就涉及到刚刚提到过一点的状态、调度和上下文切换了；

4.1 进程的生命周期与状态

同样先给出一个简化模型，有点模糊哈将就将就：

以上是最常见的几个状态，最典型的两个就是就绪状态（Ready）和 阻塞状态（Blocked/Waiting）

就绪状态（Ready）

什么都准备好了，可以理解为随叫随到

运行状态（Running）

当 CPU 真正开始执行这个进程中的指令时，进程就进入运行状态。

阻塞状态（Blocked/Waiting）

进程当前不适合到 cpu 上执行。

不过在操作系统中，一般不区分就绪和执行，默认都是就绪。

举个例子：

假设 Chrome 发起一次网络请求：

在等待服务器返回的时候，即使一直把 CPU 给 Chrome，那它也没有办法继续执行。所以操作系统会让它进入阻塞状态，把 CPU 让给其他可以运行的进程。

这里的阻塞就可以理解为：CPU 给我也没用，我正在等别的东西。

等到网络数据回来后，这个进程就重新具备运行条件，于是：

阻塞状态->等待事件完成->就绪状态

注意，它通常不是直接变成运行状态，而是先进入就绪状态。

因为即使它已经准备好了，CPU 可能仍然正在执行其他进程。

至于什么时候再次获得 CPU，还需要由操作系统决定。

以上过程就是所说的 CPU 进程调度。

4.2 CPU 如何选择下一个进程

这一段的话，我就不是那么了解了，这部分就是借助 ai 理解了哈，如果有不对请纠正；

假设系统中同时存在这些进程：

Chrome、IDEA、微信、MySQL、AppleMusic

并且以上都处于就绪状态，但当前只有一个 CPU 核心可以使用，此时该怎么办呢？

当然不能放肆给大家一起抢了，不然你的电脑就崩溃了哈哈

所以需要到操作系统中的专门负责这一版块的组件了，称之为调度器（Scheduler）。

调度器可以简单理解为：

从所有可以运行的进程中，选择一个进程获得 CPU。

刚刚的假设呢，至于调度器要选谁，当然也不是随机的。操作系统还是会根据一些因素来决策，就比如：进程优先级、已经等待的时间、之前运行的时间、进程类型、系统调度策略...

关于这里我有一个例子有点意思：

假设我是一个妹子~我长得好看又有才华，就有很多人追我~

有以下三个

A：有钱

B：帅

C：会添

然后我同时和三个男朋友一起谈~

为了让这三个人不能刚知道对方存在

我就规划好，周一二和 A 约会；周三四和 B 约会；周五六和 C 约会；周日留给自己；默认每个小哥哥都是“随叫随到”

当前就是分时复用，并发执行

定制时间表并且按照时间表来执行，就是进程调度的过程~

当然这个例子只是用来理解“有限资源被多个任务轮流使用”，真正的 CPU 调度并没有一张提前写死的约会时间表，而是会根据任务状态、优先级和调度策略动态决定。

以上就涉及到 CPU 的一些调度算法了，关于调度算法这点我就不是很会啦~

不过只需要知道 CPU 不是某个进程永久占有的资源，而是由操作系统不断在多个可运行任务之间进行分配。

哦对了，这里还需要涉及一个概念——时间片（Time Slice / Quantum）。

又假如哈：

操作系统让 Chrome 得到了 CPU，Chrome 当然也不会一直运行下去，通常是毫秒级的一小段 CPU 时间，具体长度取决于操作系统和调度策略。

这段允许它连续使用 CPU 的时间，就可以理解为一个时间片。当时间片结束后，操作系统可能就会暂停 Chrome，然后让另一个进程运行，操作系统就是在不断的这样切换切换，让我们一直以为所有程序都在同时运行。当然，现代 CPU 通常有挺多个核心，所以也的确可以有多个任务在不同 CPU 核心上真正同时执行。

不过你想，一个 CPU 的常规为 1 秒计算 21 亿次，而且还不是睿频，所以可以想象到 CPU 切换的速度。

然后呢，在同一时刻真正同时执行多个任务的情况，通常称为并行；而在单个 CPU 核心上快速交替执行多个任务，更接近于并发。

上述提到的不断来回切换这里就产生了一个问题，就是 CPU 怎么知道刚刚的程序执行到哪个步骤？CPU 的寄存器里的数据怎么办？显然，操作系统不能简单地“停下来就不管了”。

所以这就需要进行上下文切换。

4.3 进程切换与上下文切换

CPU 在执行一个进程时，会存在大量和当前执行状态有关的信息。

就比如有：程序计数器、CPU 寄存器、栈指针、部分处理器状态；

其中程序计数器（Program Counter，PC）非常重要，你可以把它理解为：CPU 下一条应该执行哪条指令。

就比如 Chrome 当前执行到：

指令 100
指令 101
指令 102  ← 当前执行位置
指令 103
指令 104

这个时候 CPU 突然切换到正在做笔记的语雀，那么此时执行到了 102 的这个位置的信息就必须保存下来。所以在切换之前，操作系统会先保存当前进程的执行现场，然后被保存的这些运行信息，就是进程的“上下文”的一部分了。

我还有个例子哈，就是刚刚的三个小哥哥~

我和 A 约会的时候，

A：下个月，你陪我去一趟三亚，你提前准备准备~

我：好的好的~

B：下个月，我的妈妈要过生日，想让你陪我去挑选一下礼物，提前准备准备~

我：好的好的~

这个时候，当然不能出现我拿着一个金手镯子面对 A 问我准备如何；我当然也不能准备了一套性感的泳衣面对 B 问我准备如何啦。所以我就得在和 ABC 约会·的时候，每次结束都拿一个小本本把当天一些重要的事情记录下来，下次再和这个人约会时，就先翻一下小本子，回忆一下上次的进展。

这个例子还是很生动吧，然后这整个过程包括 Chrome 那个例子就是：上下文切换（Context Switch）。

这也就是为什么前面 PCB 中要保存：CPU 寄存器信息、程序计数器、进程状态、调度信息这些内容的原因了。

当然了，上下文切换也并不是免费的，毕竟切换这个过程还是有些性能开销的，就比如像是保存寄存器、恢复寄存器、切换相关内存管理信息、更新进程状态、执行调度逻辑...

不过到这里还有一个新问题，之前我们一直把一个进程看成是一个相对独立的运行单位，每个进程都有自己的地址空间和系统资源。

但是现实中的程序并不是完全互不相干的，就比如：

浏览器进程要和渲染进程交换数据

客户端要和服务器通信

一个程序产生的数据可能要交给另一个程序处理

我们又说不同进程之间默认相互隔离，那么一个进程要如何把数据交给另一个进程，就得需要继续了解进程之间如何交互协作了。

5. 进程之间如何协作

现在看，前面一直把一个进程看作一个相对独立的运行单位。

每个进程都有自己的运行状态、虚拟地址空间以及各种系统资源，这样的设计其实就是为了像是：

如果其中一个进程出现了问题，通常不会直接把另一个进程的内存也一起搞坏，抽象理解为：

就像是大家各住各的房子，正常情况下不能直接翻墙去别人家拿东西。这样的隔离可以提高可以提高系统的安全性和稳定性，但问题也随之出现。

我们上面提到过，现实中的程序并不是完全互不相干的，就比如浏览器：

当前 Chorme 一个进程需要多个进程一起完成浏览器工作

当用户在地址栏输入一个网址，那么这个信息可能还需要交给其他进程处理，就比如：渲染进程可能需要知道页面内容是什么、GPU 相关进程可能需要知道有什么图形任务需要处理...

这些进程之间如果不能交流，显然用户就达不到他想要的结果。所以操作系统必须在“进程隔离”的基础上，再提供一些受控制的数据交换方式。这些机制统称为：进程间通信（Inter-Process Communication，IPC）。

这些机制可以倾向于这么理解：

就是你们这些进程不能随便进对方家，但是我可以给你们提供电话、快递柜、公共会议室之类的方式进行交流。

具体来说，操作系统提供了管道、共享内存、消息队列、Socket 等多种进程间通信方式，也就是前面说的 IPC。每一种方式具体怎么实现，还有不少内容，这里暂时先不展开。（其实是我不太懂了😁）

到这里其实已经能发现，进程的一个重要特点就是彼此之间相对独立。

独立当然有好处，一个进程出了问题不容易直接影响另一个进程，但这种独立也意味着：如果两个进程想共享数据，就得借助 IPC；创建和管理多个进程本身也需要一定的系统资源。

那么问题又来了。

假设现在不是两个独立程序需要协作，而是同一个程序内部需要同时做很多事情呢？

比如一个音乐软件可能需要同时：

播放音乐

响应鼠标操作

更新界面

读取本地文件

请求网络数据

如果每做一件事情都创建一个新的进程，显然有点太“重量级”了。

有没有一种比进程更加轻量，同时又能让一个程序内部存在多个执行任务的东西？

这就要继续说到——线程（Thread）。

6. 为什么有了进程还需要线程

从前面已经知道，一个进程可以看作一个正在运行的程序实例，它有自己的地址空间、系统资源，也可以被操作系统独立管理。但是，如果同一个程序内部，需要同时做很多事情怎么办？

比如一个音乐软件运行时，可能需要同时：

播放音乐

响应鼠标点击

更新界面

读取文件

请求网络数据

当然，我们可以给每一个任务都创建一个新的进程，比如：

播放音乐进程

界面更新进程

网络请求进程

文件读取进程

但如果每个软件都这样需要这么多进程的话，实在是太“重”了。因为每创建一个新的进程，操作系统都要给它准备相对独立的地址空间以及各种管理信息；另外不同进程之间如果需要交换数据，还要借助前面提到的 IPC。

如果这些任务本来就同属一个程序，还每做一件事情就创建一个新进程，显然不太划算。

所以就出现了一个比进程更加轻量的执行单位：线程（Thread）

注意：进程是操作系统资源分配的基本单位；线程是 CPU 上调度执行的基本单位；

相比于进程：进程更像是一个程序的运行环境，而线程则是在这个环境中真正执行任务的执行流。

继续用前面的“房子”来比喻的话：

进程 = 一套房子

线程 = 住在房子里干活的人

不同进程就像不同的房子，彼此之间默认相互隔离。

而同一个进程中的多个线程，则像住在同一套房子里的人，它们可以共同使用客厅、厨房、冰箱这些公共资源，但每个人又可以同时做自己的事情。

我再换个比喻，这个可能会更生动些：

1. 两个老铁 两个酒桌 两套房间

我现在有 100 只鸡，需要人在房间的酒桌上吃完

此时如果有两个人，就得需要搞两套房间，两个酒桌，每个人就可以只需要吃 50 只鸡，但需要的花销就比较大

1. 一个房间 一个酒桌 两个老铁来吃

两个人在一个酒桌一个房间，两人一起吃 100 只，效率仍然能大幅度提高，还减少了酒桌和房间的开销

1. 引入更多线程的话，就如下图嘿嘿

不过虽然提高了线程的数目，能够提高效率，但也不是“线性增长”。线程数目达到一定程度之后，就算线程再多，也没法起到效果了。毕竟...桌子就那么大啦

线程数目太多的话，线程的调度开销的也会非常明显，从而拖慢了程序的性能。

所以：

进程解决的是程序运行和资源隔离的问题，而线程解决的是一个进程内部如何同时存在多个执行任务的问题。

而且严格来说，前面一直说“CPU 调度进程”主要是为了方便理解。现代操作系统中，真正被 CPU 调度执行的单位通常是线程。

至于线程到底是怎么创建的、多个线程是怎么同时运行的、为什么会出现线程安全问题，以及 Java 中的多线程到底是怎么回事，就留到下一篇继续说了。

适用环境：Java 8 及以上、JDBC 4.2、MySQL 8.0.39。

该部分内容为了解，实际中数据库连接已被包装好，仅需调用即可

1. JDBC 是什么

JDBC（Java Database Connectivity）是 Java 访问关系型数据库的一套标准 API，具体实现是由数据库厂商去完成的。它规定了连接数据库、发送 SQL、接收结果和处理异常的统一接口，真正与 MySQL 通信的代码则由 MySQL 驱动实现。

可以把三者的关系理解为：

Java 程序 → JDBC 标准接口 → MySQL Connector/J 驱动 → MySQL 服务器

业务代码主要面向 java.sql、javax.sql 中的接口编程。更换数据库时虽然仍要调整驱动、地址和方言 SQL，但操作流程基本不变。

一次完整的 JDBC 操作通常包括：

1. 引入数据库驱动；
2. 获取 Connection 连接；
3. 定义 SQL，并创建 PreparedStatement；
4. 为 SQL 中的占位符绑定参数；
5. 执行 SQL；
6. 处理执行结果：增删改读取影响行数，查询读取 ResultSet；
7. 按照结果集、执行对象、数据库连接的顺序释放资源。

如果多条增删改语句属于同一个业务，还要在同一个连接中统一提交或回滚事务。上面的顺序就是后文各节的编排顺序，也对应一段 JDBC 程序从开始到结束的实际执行过程。

2. 引入 MySQL 驱动

2.1 Maven 依赖

maven：类似应用商店，在maven仓库中维护了所有的Java工程需要用到的依赖，IDEA中已经内置好了maven

由于我的mysql版本为8.4.xx，因此使用的maven对应的是下面这部分依赖；

不同版本可以到Maven Repository: mysql此处找对应版本依赖

第一个 MySQL Connector-j 为最新版本的依赖推荐

IDEA创建模块选择maven后，在其下的pom.xml插入该依赖

<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <version>8.4.0</version>
    <scope>compile</scope>
</dependency>

驱动必须进入运行时类路径，否则连接时会出现 No suitable driver 一类错误。

如无法加载该依赖，则还需修改镜像源

2.2 配置国内镜像

内置的maven路径：IDEA安装目录/plugins/maven/lib/maven3/conf/setting.xml

<!-- 加入如下 Mirror 节点，使用国内阿里云仓库镜像 开始 -->
<mirror>
    <id>aliyunmaven</id>
    <mirrorOf>*</mirrorOf>
    <name>阿里云公共仓库</name>
    <url>https://maven.aliyun.com/repository/public</url>
</mirror>

<mirror>
    <id>central</id>
    <mirrorOf>*</mirrorOf>
    <name>aliyun central</name>
    <url>https://maven.aliyun.com/repository/central</url>
</mirror>

<mirror>
    <id>spring</id>
    <mirrorOf>*</mirrorOf>
    <name>aliyun spring</name>
    <url>https://maven.aliyun.com/repository/spring</url>
</mirror>
<!-- 加入如下 Mirror 节点，使用国内阿里云仓库镜像 结束 -->

2.3 是否还要手动加载驱动

旧代码常写 Class.forName("com.mysql.cj.jdbc.Driver")。从 JDBC 4 开始，驱动通常会自动注册，现代项目一般可以不用写。自动加载失败时，先检查运行时依赖；旧环境或特殊类加载器才可能显式调用。

3. 核心接口

这些对象多数是接口，变量也应尽量声明为接口类型，减少对具体驱动的依赖。

4. 建立数据库连接

4.1 JDBC URL

MySQL 连接地址的基本格式是：

jdbc:mysql://主机:端口/数据库?参数1=值1&参数2=值2

本机练习可以写成：

jdbc:mysql://127.0.0.1:3306/jdbc_demo?sslMode=DISABLED&allowPublicKeyRetrieval=true

其中，127.0.0.1:3306 是主机和端口，jdbc_demo 是数据库。后两个参数用于关闭 TLS、允许获取认证公钥，只适合可信的本地环境。生产环境应配置 TLS 和严格的证书校验，不能为了消除报错而照搬这两个参数。

4.2 使用 DriverManager

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public final class JdbcConfig {
    private static final String URL =
        "jdbc:mysql://127.0.0.1:3306/jdbc_demo"
        + "?sslMode=DISABLED&allowPublicKeyRetrieval=true";
    private static final String USER = System.getenv("DB_USER");
    private static final String PASSWORD = System.getenv("DB_PASSWORD");

    // 私有构造方法，禁止随意创建JdbcConfig对象
    private JdbcConfig() {}
	
    // 建立数据库连接
    public static Connection getConnection() throws SQLException {
        return DriverManager.getConnection(URL, USER, PASSWORD);
    }
}

由于方法都是静态方法，所以只需要使用JdbcConfig.function()调用即可，不需要创建对象。

账号和密码通过环境变量读取，避免直接写入源码并提交到仓库。应用程序也不应长期使用 root，应为它创建只拥有所需权限的独立账号。

4.3 DataSource 与连接池

DataSource 是 JDBC 提供的一个标准接口，但不等于连接池。MysqlDataSource 是基础数据源；HikariCP 等连接池会实现或包装它。使用连接池后，close() 通常表示归还连接，仍要及时调用。

DataSource 作用是：

向程序提供 Connection，并把连接地址、用户名、密码等配置集中管理起来；

使用方式为：

Connection connection = dataSource.getConnection();

但使用连接池仍然需要close()：

connection.close();

连接池可以理解为一个专门存放数据库连接的“容器”。

程序启动后，连接池会提前建立多个连接：

连接池
├── Connection 1：空闲
├── Connection 2：正在使用
├── Connection 3：空闲
└── Connection 4：空闲

比起 DriverManager 每次调用 getConnection()通常都要重新建立一次数据库连接，连接池够创建多个连接；可以避免频繁创建和关闭连接，节省开销。

5. 定义 SQL、创建执行对象与参数绑定

不要把外部输入拼进 SQL，例如 "... where name='" + inputName + "'"。输入中的引号或逻辑表达式可能改变语句结构，形成 SQL 注入。

可以举个例子（SQL注入演示）：

System.out.println("请输入学号：");
            String sno = scanner.next();
            String sql = "select id,name,sno,age,class_id from student_design2 where sno = '"+ sno +"'";
            // 5.执行SQL，获取查询结果
            resultSet = statement.executeQuery(sql);  

由于使用的是 Scanner.next() ,Scanner.next() 遇到空格就停止读取。

因此我们可以用别的表示方法绕过空格，比如 /**/ ，如果是网页中注入的话，通过url可以有：

%20 --代表url编码的空格，在空格过滤时可以代替。

%09--用于在输出或显示文本时在该位置产生一个固定的水平间距，类似于tab键。

%0a--代表换行符

%0b--用于在输出或显示文本时在该位置产生一个固定的垂直间距，类似于tab键。

%0d--回车换行

%a0--代表的是非断行空格

%00--%00代表的是ASCII码中的空字符

都是之前学攻防的底子哈哈哈哈哈

因此可以这样注入：'/**/or/**/1=1;#，使得查询语句被这样闭合

select id, name, sno, age, class_id from student_design2 where sno = ' sno ' or 1=1;#

使用 # 将后续语句屏蔽，由于 1=1 恒成立，因此完成全查询

所以应把 SQL 结构与参数值分开：

用预编译的方式 PreparedStatement 解决SQL注入问题

String sql = "select id, name, age from student where name = ? and age >= ?";

try (PreparedStatement ps = connection.prepareStatement(sql)) {
    ps.setString(1, inputName);
    ps.setInt(2, minAge);

    // 参数绑定完成后，在同一个 try 代码块中执行 SQL
}

这里的实际顺序是：先定义带 ? 的 SQL，再通过连接创建 PreparedStatement，最后调用 setXxx() 绑定参数。绑定完成后，才能在同一个 PreparedStatement 上执行 SQL。

使用时要记住：

• ? 是参数占位符，编号从 1 开始；
• 占位符外不要再加引号，应写 name = ?，不能写 name = '?'；
• setString、setInt、setBigDecimal 等方法会按类型安全传值；
• Java 值为 null 时可使用 setNull(index, Types.INTEGER)，或在驱动支持的情况下使用 setObject；
• 占位符只能代表“值”，不能代替表名、列名、ASC/DESC 等 SQL 结构。动态结构必须使用白名单选择，不能直接拼接外部输入。

PreparedStatement 既降低 SQL 注入风险，也让类型转换和重复执行更清晰，应作为业务代码的默认选择。

6. 执行 SQL 的三个方法

日常代码应选含义最明确的方法。不要对查询调用 executeUpdate()，也不要为了省事全部使用 execute()。

调用存储过程时使用 CallableStatement，形如 prepareCall("{call procedure_name(?, ?)}")；输出参数先用 registerOutParameter 注册。

7. 增删改查写法

以下代码假设 student 表含有自增主键 id、姓名 name、年龄 age 和创建时间 created_at。

7.1 新增并取得自增主键

String sql = "insert into student(name, age) values (?, ?)";

try (Connection conn = JdbcConfig.getConnection();
     PreparedStatement ps = conn.prepareStatement(
         sql, Statement.RETURN_GENERATED_KEYS)) {

    ps.setString(1, "小林");
    ps.setInt(2, 20);

    int rows = ps.executeUpdate();
    if (rows == 1) {
        try (ResultSet keys = ps.getGeneratedKeys()) {
            if (keys.next()) {
                long newId = keys.getLong(1);
                System.out.println("新增编号：" + newId);
            }
        }
    }
}

只有创建语句时传入 Statement.RETURN_GENERATED_KEYS，执行后才能规范地读取生成的主键。

7.2 删除

String sql = "delete from student where id = ?";

try (Connection conn = JdbcConfig.getConnection();
     PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setLong(1, 1L);

    int rows = ps.executeUpdate();
    System.out.println("删除行数：" + rows);
}

删除前要确认 WHERE 条件正确，并检查影响行数。没有 WHERE 条件的 DELETE 可能删除整张表中的记录。

7.3 修改

String sql = "update student set age = ? where id = ?";
try (Connection conn = JdbcConfig.getConnection();
     PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setInt(1, 21);
    ps.setLong(2, 1L);
    int rows = ps.executeUpdate();
    System.out.println("修改行数：" + rows);
}

新增、删除和修改都使用 executeUpdate()，并通过返回的影响行数判断条件是否匹配、操作是否符合预期。

7.4 查询

String sql = "select id, name, age from student where age >= ?";

try (Connection conn = JdbcConfig.getConnection();
     PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setInt(1, 18);

    try (ResultSet rs = ps.executeQuery()) {
        while (rs.next()) {
            long id = rs.getLong("id");
            String name = rs.getString("name");
            int age = rs.getInt("age");
            System.out.println(id + "，" + name + "，" + age);
        }
    }
}

查询使用 executeQuery() 获得 ResultSet，然后移动游标并读取每一行。查询结果的具体读取规则见下一节。

8. 读取 ResultSet

查询刚返回时，游标位于第一行之前。每次调用 next()，游标向后移动一行；有数据时返回 true，越过最后一行时返回 false。所以多行查询使用 while (rs.next())，只期待一行时可以使用 if (rs.next())。

读取列时推荐使用列名或别名，可读性比数字下标更好。联表查询若出现重名列，可写 c.name as class_name，再通过 rs.getString("class_name") 读取。

常见类型对应关系：

getInt、getLong 等基本类型方法遇到 SQL NULL 会返回 0，因此可在读取后调用 wasNull()；如果业务上需要区分“空值”和“数字 0”，应使用包装类型保存结果。金额不要用 double，应使用 BigDecimal。

9. 释放资源

执行结果处理完毕后，应关闭 ResultSet、Statement 或 PreparedStatement、Connection。推荐使用 try-with-resources：

String sql = "select id, name, age from student where id = ?";

try (Connection connection = JdbcConfig.getConnection();
     PreparedStatement ps = connection.prepareStatement(sql)) {

    ps.setLong(1, 1L);

    try (ResultSet rs = ps.executeQuery()) {
        if (rs.next()) {
            System.out.println(rs.getString("name"));
        }
    }
}

Java 会自动按照声明的相反顺序关闭资源，因此实际关闭顺序是：

1. ResultSet；
2. PreparedStatement；
3. Connection。

这与手动在 finally 中“先关闭结果集，再关闭执行对象，最后关闭连接”的顺序相同。try-with-resources 比逐个判空关闭更简洁，也能在发生异常时可靠释放资源。使用连接池时，connection.close() 通常表示把连接归还连接池，仍然必须调用。

10. JDBC 事务

新连接默认开启自动提交，即每条 SQL 执行成功后立即提交。一个业务动作包含多条 SQL 时，必须在同一个 Connection 上关闭自动提交，再统一提交或回滚。

public static void transfer(long fromId, long toId, BigDecimal amount)
        throws SQLException {
    try (Connection conn = JdbcConfig.getConnection()) {
        boolean oldAutoCommit = conn.getAutoCommit();
        try {
            conn.setAutoCommit(false);

            String debitSql = "update account set balance = balance - ? "
                            + "where id = ? and balance >= ?";
            try (PreparedStatement debit = conn.prepareStatement(debitSql)) {
                debit.setBigDecimal(1, amount);
                debit.setLong(2, fromId);
                debit.setBigDecimal(3, amount);
                if (debit.executeUpdate() != 1) {
                    throw new SQLException("扣款失败：账号不存在或余额不足");
                }
            }

            String creditSql =
                "update account set balance = balance + ? where id = ?";
            try (PreparedStatement credit = conn.prepareStatement(creditSql)) {
                credit.setBigDecimal(1, amount);
                credit.setLong(2, toId);
                if (credit.executeUpdate() != 1) {
                    throw new SQLException("收款账号不存在");
                }
            }

            conn.commit();
        } catch (SQLException e) {
            conn.rollback();
            throw e;
        } finally {
            conn.setAutoCommit(oldAutoCommit);
        }
    }
}

关键是多条语句共用同一连接，全部成功才 commit()，任意一步失败都 rollback()。归还池前还要恢复原来的 autoCommit，避免影响下一位使用者；事务中途不能重新获取连接。

数据库表还必须使用支持事务的存储引擎，例如 InnoDB，否则 Java 代码写了回滚也达不到预期效果。

11. 异常排查

排错时应保留 SQLException 的状态码、数据库错误码和信息：

catch (SQLException e) {
    System.err.println("SQLState：" + e.getSQLState());
    System.err.println("错误码：" + e.getErrorCode());
    System.err.println("错误信息：" + e.getMessage());
    throw e;
}

日志可记录 SQL 模板、SQLState 和错误码，但不能输出密码等敏感参数。异常也不能空处理，否则上层会误以为业务成功。

参考

• MySQL Connector/J：使用 Maven 安装
• Java JDBC API：Connection
• Java JDBC API：PreparedStatement 与 ResultSet

适用环境：MySQL 8.0.39。

1. 用户和权限

MySQL 安装完成后通常会有管理账号 root。它适合安装、维护和授权，但不适合作为普通项目的连接账号。

MySQL 的访问控制可以分成两步：

1. 身份验证：根据用户名、连接来源和密码确定能否登录。
2. 权限验证：登录成功后，每执行一条 SQL，MySQL 都会检查该账号是否拥有相应权限。

所以，“密码正确”只表示可以连接，并不代表可以查询、插入或删除数据。

2. MySQL 账号的组成

2.1 账号不是单独的用户名

MySQL 账号的完整格式为：

'user_name'@'host_name'

• user_name：用户名；
• host_name：允许该用户从什么主机连接。

例如，下面是两个不同的账号：

'app_user'@'localhost'
'app_user'@'192.168.1.10'

虽然用户名相同，但是是两个独立账号，密码和权限也可以不同。MySQL 按“用户名 + 主机”定位账号。

用户名和主机名要分别加引号：

-- 正确
'app_user'@'localhost'

-- 错误理解：这是用户名 app_user@localhost，主机部分被省略
'app_user@localhost'

省略主机等价于 'user_name'@'%'，允许从任意主机匹配。实际创建账号时应该明确写出主机。

2.2 常见主机范围

MySQL 8.0.35 起，主机部分的 %、_ 通配符已被弃用。MySQL 8.0.39 应优先使用明确 IP、主机名或 CIDR，并配合防火墙限制来源。

3. 查看用户和当前身份

3.1 查看已有账号

用户信息保存在 mysql 系统数据库的授权表中。管理员可以查看常用账号属性：

select
    user,
    host,
    plugin,
    account_locked,
    password_expired
from mysql.user;

字段含义如下：

• user、host：共同组成完整账号；
• plugin：账号使用的认证插件；
• account_locked：账号是否被锁定；
• password_expired：密码是否已经过期；

mysql.infoschema、mysql.session、mysql.sys 等通常是 MySQL 自己使用的保留账号，不应随意改密或删除。也不建议直接对 mysql.user 执行 INSERT、UPDATE、DELETE；应使用专门的账号管理语句，让 MySQL 正确维护所有授权表和内存权限数据。

3.2 USER() 与 CURRENT_USER()

select user(), current_user();

二者含义不同：

• USER()：客户端连接时提供的用户名，以及客户端来源；
• CURRENT_USER()：MySQL 最终用于身份验证和权限检查的账号。

普通情况下两者看起来相同，但匿名账号匹配、代理用户等场景下可能不同。判断权限属于哪个账号，应以 CURRENT_USER() 为准。

3.3 查看权限和账号定义

-- 查看当前账号的权限
show grants;

-- 查看指定账号的权限
show grants for 'app_user'@'localhost';

-- 查看账号的认证、密码策略和锁定状态等定义
show create user 'app_user'@'localhost';

如果结果中出现：

grant usage on *.* to 'app_user'@'localhost';

USAGE 不代表拥有全局操作权限，而表示账号存在，但在该层级没有实际权限。

4. 创建用户

4.1 基本语法

create user [if not exists]
    'user_name'@'host_name'
    identified by 'password';

示例：

create user if not exists
    'sqllearn_app'@'localhost'
    identified by 'Study-MySQL_2026!';

执行后只完成三件事：创建账号、限制连接来源、设置登录密码。新账号默认没有业务数据库的访问权限，还需要单独执行 GRANT。

IF NOT EXISTS 可避免账号已存在时报错，但不会修改已有账号。简单密码可能被密码策略拒绝。

MySQL 8.0 中推荐把创建和授权分开写：

create user if not exists 'sqllearn_app'@'localhost'
identified by 'Study-MySQL_2026!';

grant select, insert, update, delete
on sqllearn.*
to 'sqllearn_app'@'localhost';

这样能清楚区分“创建身份”和“授予权限”。

4.2 创建限定网段的账号

create user 'report_user'@'192.168.1.0/24'
identified by 'Report-Read_2026!';

该账号只能从匹配的 IPv4 网段连接。远程连接还取决于 MySQL 监听地址、防火墙和云服务器安全组。

5. 修改和删除用户

5.1 修改密码

推荐使用 ALTER USER：

alter user 'sqllearn_app'@'localhost'
identified by 'New-Study_2026!';

修改当前已认证账号的密码：

-- USER() 是 ALTER USER 为当前账号提供的专用写法
alter user user()
identified by 'My-New-Password_2026!';

也可以使用 SET PASSWORD：

-- 修改指定账号密码
set password for 'sqllearn_app'@'localhost'
= 'New-Study_2026!';

-- 修改当前账号密码
set password = 'My-New-Password_2026!';

优先掌握 ALTER USER，因为它还能管理账号锁定和密码过期等属性。

5.2 锁定、解锁和要求改密

-- 暂停账号登录，但保留账号和权限
alter user 'sqllearn_app'@'localhost' account lock;

-- 恢复账号登录
alter user 'sqllearn_app'@'localhost' account unlock;

-- 要求用户下次连接时修改密码
alter user 'sqllearn_app'@'localhost' password expire;

暂时停用时先锁定，确认废弃后再删除，便于恢复。

5.3 重命名和删除账号

rename user
    'sqllearn_app'@'localhost'
to  'sqllearn_service'@'localhost';

RENAME USER 会保留旧账号的权限。删除语法为：

drop user if exists 'sqllearn_service'@'localhost';

DROP USER 会删除账号及其授权记录，但不会删除它创建的数据库和表。删除前应检查它是否是视图、触发器或存储程序的 DEFINER。已有连接也不会被强制立即断开。

6. 权限类型和作用层级

6.1 常用权限

FILE、CREATE USER、PROCESS 等影响范围较大，普通应用通常不需要。

6.2 权限层级

同一种权限可以授予不同范围：

范围越大，风险越高。应用账号一般使用数据库级或更小的范围，不应轻易授权 *.*。

GRANT ALL ON sqllearn.* 只表示拥有 sqllearn 数据库层级能够授予的全部权限，不会因此获得 FILE、CREATE USER 等全局管理权限。

7. 授予权限

7.1 基本语法

grant priv_type [, priv_type ...]
on priv_level
to 'user_name'@'host_name'
[with grant option];

priv_type：权限类型

priv_level：权限作用范围，如数据库、某数据库中的某表...

with grant option：允许该用户把自己拥有的权限继续授权给其他用户

示例：授予 sqllearn 数据库的常用增删改查权限。

grant select, insert, update, delete
on sqllearn.*
to 'sqllearn_app'@'localhost';

创建只读账号：

create user 'sqllearn_read'@'localhost'
identified by 'Read-Only_2026!';

grant select
on sqllearn.*
to 'sqllearn_read'@'localhost';

在select权限下执行insert操作会有如下报错：

限制到一张表：

grant select
on sqllearn.student
to 'sqllearn_read'@'localhost';

限制到部分列：

grant select (id, name, age)
on sqllearn.student
to 'sqllearn_read'@'localhost';

7.2 WITH GRANT OPTION

grant select
on sqllearn.*
to 'team_leader'@'localhost'
with grant option;

该选项还允许 team_leader 把这项权限授予其他账号。普通业务用户不需要这种能力。

7.3 权限何时生效

通过 CREATE USER、GRANT、REVOKE、ALTER USER 等专用语句修改账号时，MySQL 会主动更新权限数据，通常不需要执行 FLUSH PRIVILEGES。

FLUSH PRIVILEGES表示刷新权限操作；

已有连接中不同层级的变化可能在不同时间体现：

• 表级、列级权限通常在下一条请求时体现；
• 数据库级权限可能要再次执行 USE 数据库名；
• 静态全局权限或密码变化通常要重新连接后体现。

若授权后仍报错，先确认授权账号与 CURRENT_USER() 是否一致，再根据层级重新选择数据库或连接。

FLUSH PRIVILEGES 主要用于直接修改授权表后重新加载，或 --skip-grant-tables 启动后的恢复；直接修改授权表并不推荐。

8. 回收权限

8.1 基本语法

revoke [if exists] priv_type [, priv_type ...]
on priv_level
from 'user_name'@'host_name';

回收写权限，只保留原有查询权限：

revoke insert, update, delete
on sqllearn.*
from 'sqllearn_app'@'localhost';

回收 sqllearn 数据库上的全部权限：

revoke all privileges
on sqllearn.*
from 'sqllearn_app'@'localhost';

清除该账号在所有层级的权限和转授权能力：

revoke all privileges, grant option
from 'sqllearn_app'@'localhost';

注意：

• REVOKE 只撤销权限，不删除账号；账号仍可能登录，但无法执行未获授权的操作。
• 只想撤销某个数据库的权限时，应写 sqllearn.*，不要误写成范围更大的全局清除语句。
• REVOKE IF EXISTS 从 MySQL 8.0.30 起支持。
• 撤权后使用 SHOW GRANTS 核对结果，不要只根据 SHOW DATABASES 判断。

区分授予和回收语法：

授予

grant ... to 用户;

回收

revoke ... from 用户;

9. 使用角色管理权限

许多用户需要同一组权限时，可以把权限封装成角色，再分配给用户。

-- 1. 创建角色
create role 'r_sqllearn_read';

-- 2. 给角色授权
grant select
on sqllearn.*
to 'r_sqllearn_read';

-- 3. 创建实际登录账号
create user 'analyst'@'localhost'
identified by 'Analyst-Read_2026!';

-- 4. 把角色授予用户；授予角色时没有 ON 子句
grant 'r_sqllearn_read'
to 'analyst'@'localhost';

-- 5. 设置为默认激活角色
set default role 'r_sqllearn_read'
to 'analyst'@'localhost';

查看当前会话已经激活的角色：

select current_role();

角色适合账号较多、权限模板相同的场景。少量账号直接 GRANT 即可。

10. 常见错误

10.1 Access denied for user（1045）

表示连接阶段失败，优先检查：

1. 用户名或密码是否正确；
2. 连接来源是否匹配账号的 host；
3. 使用的是否是预期账号，例如 'user'@'localhost' 与 'user'@'%' 并非同一个账号；
4. 客户端连接的是不是预期 MySQL 服务器和端口。

10.2 Access denied ... to database（1044）

账号已经登录，但没有目标数据库的访问权限。使用管理员账号执行：

show grants for 'user_name'@'host_name';

检查授权数据库名和账号主机是否准确。

10.3 command denied ... for table（1142）

说明账号能够访问数据库，但缺少当前命令所需权限。例如能 SELECT 却不能 INSERT，就需要检查是否授予 INSERT，而不是重新设置密码。

10.4 授权后仍未生效

依次检查：

select current_user();
show grants;

如果账号正确，再尝试重新执行 USE 数据库名 或重新连接。使用专用授权语句时不应把 FLUSH PRIVILEGES 当成固定步骤。

参考

flowchart LR
    A["用户和权限管理"]

    A --> U["用户"]
    U --> U1["mysql.user"]
    U --> U2["'user'@'host'"]
    U --> U3["CREATE USER"]
    U --> U4["ALTER USER"]
    U --> U5["SET PASSWORD"]
    U --> U6["DROP USER"]

    A --> P["权限"]

    P --> G["GRANT"]
    G --> G1["SELECT"]
    G --> G2["多个权限"]
    G --> G3["ALL"]
    G --> G4["WITH GRANT OPTION"]

    P --> S["权限范围"]
    S --> S1["*.*"]
    S --> S2["db_name.*"]
    S --> S3["db_name.table_name"]

    P --> SG["SHOW GRANTS"]
    SG --> SG1["USAGE"]

    P --> R["REVOKE"]
    R --> R1["回收权限"]

• MySQL 8.0：账号名称
• MySQL 8.0：创建与管理账号
• MySQL 8.0：GRANT
• MySQL 8.0：REVOKE
• MySQL 8.0：权限变化何时生效
• MySQL 8.0：角色

适用环境：MySQL 8.0。

视图可以理解为“有名字、可重复查询的 SELECT”，主要用于封装查询、限制可见数据和提供稳定的查询接口

1. 视图

视图（View）是一张虚拟表，它的内容来自一个或多个基表、其他视图或表达式的查询结果； 创建视图时，MySQL 主要保存的是视图名称、列信息和 SELECT 定义，而不是另存一份结果数据

flowchart LR
    Q["查询视图"] --> V["执行视图定义"]
    V --> S["student 基表"]
    V --> C["score 基表"]

视图有以下特点：

• 查询视图时，MySQL 根据视图定义读取当时的基表数据；
• 基表数据改变后，再次查询视图通常会看到新结果；
• 删除视图只删除查询定义，不会删除基表及其数据；
• 普通视图不是数据副本、备份或快照，也不会自动提高查询速度；
• 视图定义仍会保存在数据字典中，所以“视图不存结果数据”不等于完全不占任何空间。

例如，下面的视图只展示学生编号、姓名和年龄：

create view v_student_basic as
select id, name, age
from student;

查询视图与查询普通表的写法相同：

select * from v_student_basic;

2. 视图优点

简化复杂查询

多表连接、筛选和计算可以封装到视图中。应用以后只查询视图，不必反复编写同一段复杂 SQL。

限制可见的行和列

视图可以不暴露密码、身份证号等敏感列，也可以通过 WHERE 只展示某些行。但这只有与权限控制结合才真正安全：如果用户仍拥有基表的 SELECT 权限，他依然可以绕过视图直接查询基表。

提供相对稳定的查询接口

应用统一查询视图。底层表调整后，有时只需重新定义视图即可保持视图的列名不变，减少应用改动。但这种独立性并非绝对：删除视图依赖的列仍可能使视图失效。

统一名称和业务口径

视图可以为列起更清楚的名称，并把“总分如何计算”“有效记录如何筛选”等规则集中在一处，避免不同程序写出不同口径。

3. 创建视图

3.1 基本语法

create view 视图名 [(视图列名列表)] as
select 查询列
from 表名
[where 条件];

较完整的 MySQL 语法为：

create [or replace]
    [algorithm = {undefined | merge | temptable}]
    [definer = 用户]
    [sql security {definer | invoker}]
view 视图名 [(视图列名列表)] as
select_statement
[with [cascaded | local] check option];

• algorithm：这个是视图执行算法，MySQL 查询视图时，有三种处理方式。undefined（默认）、merge（合并）、tempable（临时表）

• definer：指定创建这个视图的人。如definer='root'@'localhost'表示该视图属于root用户

• sql security：表示查询视图时，使用谁的权限

  • definer 则表示使用创建视图用户的权限；
  • invoker 则表示当前查询用户自己的权限；

• with check option：防止通过视图修改出视图范围之外的数据

  • cascaded：检查所有关联视图；
  • local：只检查当前视图；

示例：

create or replace
algorithm = merge
definer = 'root'@'localhost'
sql security definer
view v_java_student (student_id, student_name, class_name)
as
select
    s.id,
    s.name,
    c.name
from student_design2 s
join class_design2 c
    on c.id = s.class_id
where c.name = 'Java001班'
with cascaded check option;

3.2 使用别名确定视图列名

以下示例连接学生、班级、课程和成绩表。显式 JOIN ... ON ... 能把连接条件与普通筛选条件分开，比逗号连接更容易阅读，也能减少漏写连接条件造成笛卡尔积的风险。

create view v_student_score as
select
    s.id          as student_id,
    s.name        as student_name,
    s.sno,
    s.age,
    s.gender,
    s.enroll_date,
    c.id          as class_id,
    c.name        as class_name,
    co.id         as course_id,
    co.name       as course_name,
    sc.id         as score_id,
    sc.score
from student s
join class c
    on c.id = s.class_id
join score sc
    on sc.student_id = s.id
join course co
    on co.id = sc.course_id;

来自不同表的列可能同名，例如四张表都可能有 id。视图中的列名必须唯一，所以要用 AS 改成 student_id、class_id 等明确名称。

3.3 在视图名后指定列名

也可以统一列出视图的列名：

create view v_student_name_age
    (student_id, student_name, student_age) as
select id, name, age
from student;

括号中的名称数量必须与 SELECT 返回的列数完全相同。两种命名方法选择一种即可；复杂查询通常使用 AS 别名更直观，因为名称紧挨对应表达式。

3.4 创建时的注意事项

1. 视图与表属于同一数据库名称空间，不能在同一数据库中同名。
2. 建议明确写出字段，不要长期依赖 SELECT *。视图定义在创建时确定；基表以后新增列，不会自动加入既有视图。
3. 如果基表的依赖列被删除或改名，查询视图可能报错，需要重新定义视图。
4. 不要依赖视图定义中的 ORDER BY 保证顺序。查询视图时应在最外层明确排序；外层自己的 ORDER BY 会取代视图内的排序。
5. CREATE VIEW 是 DDL，会触发隐式提交，不要把它混入需要回滚的业务事务。

4. 查询和使用视图

视图可出现在普通表能够出现的许多查询位置，并可继续筛选、连接、分组和排序：

-- 查询全部视图数据
select *
from v_student_score;

-- 对视图结果继续筛选和排序
select student_name, course_name, score
from v_student_score
where score >= 90
order by score desc;

-- 视图与真实表连接
select v.student_name, v.course_name, v.score, s.enroll_date
from v_student_score v
join student s
    on s.id = v.student_id;

视图也可以隐藏查询细节。例如只对外提供姓名和总分：

create view v_student_total_points as
select
    s.id as student_id,
    s.name as student_name,
    sum(sc.score) as total_points
from student s
join score sc
    on sc.student_id = s.id
group by s.id, s.name;

select student_name, total_points
from v_student_total_points
order by total_points desc;

用户只能从该视图获得定义中已有的列，不能临时查询未被视图暴露的学号或各科明细。若确实需要这些字段，应修改视图、另建视图或在有权限时查询基表。

5. 视图与基表数据的关系

5.1 修改基表会影响视图结果

update score
set score = 99
where student_id = 1 and course_id = 1;

select *
from v_student_score
where student_id = 1 and course_id = 1;

UPDATE 修改的是 score 基表。视图没有独立保存旧结果，所以再次查询时会显示修改后的成绩。

5.2 修改可更新视图会影响基表

创建一个行与基表行一一对应的简单视图：

create view v_class_one_student as
select id, name, age, class_id
from student
where class_id = 1;

update v_class_one_student
set age = 20
where id = 1;

如果这个视图满足可更新条件，这条语句最终修改的是 student 基表中 id=1 的记录。因此能看出，视图不是基表的副本；通过视图写数据同样需要事务、权限和条件控制。

6. 可更新视图

视图能够被 UPDATE、DELETE 或 INSERT 操作的核心条件是： 视图中的一行能够明确对应到底层表中的一行。 最容易更新的是“单表 + 简单列 + 普通 WHERE”视图。

以下结构通常会使视图不可更新：

• 聚合函数或窗口函数，如 SUM()、COUNT()、AVG()；
• DISTINCT；
• GROUP BY、HAVING；
• UNION、UNION ALL；
• 查询列表中的子查询；
• 某些多表连接；
• 在 FROM 中引用不可更新视图；
• 只查询常量，没有可对应的基表行；
• 明确使用 ALGORITHM = TEMPTABLE。

例如 v_student_total_points 使用了 SUM() 和 GROUP BY。 一条总分记录由多条成绩记录合成，MySQL 无法判断“把总分改成 500”应当修改哪一科，所以它只适合查询。

ORDER BY 可以出现在视图定义中，但不能把它简单记成“只要有 ORDER BY，视图就一定不可更新”。可更新性取决于完整定义和处理方式；为了职责清楚，可写视图通常不在内部排序，而在查询视图时排序。

“可更新”也不一定代表“可插入”。通过视图插入时，视图还要能为基表中所有没有默认值的必填列提供值，而且目标列通常必须是简单的基表列引用。

检查 MySQL 记录的可更新状态：

select table_name, is_updatable
from information_schema.views
where table_schema = database();

IS_UPDATABLE='YES' 表示该视图可用于某些更新操作，不表示任意 INSERT、UPDATE、DELETE 都必然合法；实际操作还受列、连接方式和权限等条件限制。

7. WITH CHECK OPTION

普通可更新视图有一个容易忽略的问题：通过视图修改数据后，新数据可能不再满足视图的 WHERE 条件，于是该行会从视图中“消失”。

create view v_class_one_student as
select id, name, age, class_id
from student
where class_id = 1;

-- 若没有检查选项，这次修改可能成功，随后该行不再出现在视图中
update v_class_one_student
set class_id = 2
where id = 1;

在可更新视图后加入 WITH CHECK OPTION，可以阻止通过该视图写入不再满足视图条件的数据：

create or replace view v_class_one_student as
select id, name, age, class_id
from student
where class_id = 1
with check option;

此时把 class_id 改为 2 会失败，因为修改后的记录不符合 class_id=1。 它既检查 UPDATE 后的行，也检查通过视图 INSERT 的行。

视图基于其他视图时还可指定检查范围：

• WITH LOCAL CHECK OPTION：检查当前视图的条件，并按下层视图原有的检查设置继续处理；
• WITH CASCADED CHECK OPTION：检查当前视图及所有下层视图的条件；
• 不写 LOCAL 或 CASCADED 时，默认是 CASCADED。

没有嵌套视图时，直接写 WITH CHECK OPTION 最容易理解。

8. 修改、查看与删除视图

8.1 修改定义

create or replace view v_student_basic as
select id, name, age, gender
from student;

CREATE OR REPLACE VIEW 在视图不存在时创建，在已存在时替换。也可以使用：

alter view v_student_basic as
select id, name, age, gender
from student;

ALTER VIEW 要求目标视图已经存在。两种方式都是重新定义视图，不会直接修改基表数据；它们属于 DDL，同样可能隐式提交当前事务。

8.2 查看视图

-- 查看当前数据库中的视图
show full tables where table_type = 'VIEW';

-- 查看完整创建语句，排查算法、安全模式和检查选项
show create view v_student_basic;

-- 查看视图对外提供的列
desc v_student_basic;

-- 检查视图依赖是否仍然有效
check table v_student_basic;

还可查询更完整的元数据：

select
    table_name,
    is_updatable,
    check_option,
    security_type
from information_schema.views
where table_schema = database();

8.3 删除视图

drop view if exists v_student_basic;

-- 一次删除多个视图
drop view if exists v_student_score, v_student_total_points;

IF EXISTS 可避免视图不存在时直接报错。 删除视图不会删除 student、score 等基表数据；但如果其他视图依赖被删除的视图， 依赖者可能变得不可用。DROP VIEW 也是会隐式提交的 DDL。

9. 视图处理原理

MySQL 处理视图主要有三种算法：

例如：

create algorithm = merge view v_adult_student as
select id, name, age
from student
where age >= 18;

执行：

select *
from v_adult_student
where id < 100;

采用 MERGE 时，可以近似理解为 MySQL 合并两个条件后查询基表：

select id, name, age
from student
where age >= 18 and id < 100;

视图不会自动拥有索引，普通视图也不能像表一样单独创建索引。查询性能主要取决于展开后的 SQL、基表索引、数据量和优化器选择；应使用 EXPLAIN 分析最终查询，不能把“创建视图”等同于“查询加速”。

10. 视图的安全上下文

完整语法中的 SQL SECURITY 决定执行视图时按照谁的权限检查底层对象：

• SQL SECURITY DEFINER：按视图定义者的权限执行，是默认值；
• SQL SECURITY INVOKER：按调用视图的用户权限执行。

create sql security invoker view v_student_public as
select id, name, age
from student;

要使用视图保护数据，应让普通用户只有所需视图的权限，而没有敏感基表的直接权限。仅仅不把敏感列写进视图，并不能阻止一个本来就能查询基表的用户。

参考

• MySQL 8.0：CREATE VIEW
• MySQL 8.0：视图处理算法
• MySQL 8.0：可更新与可插入视图
• MySQL 8.0：WITH CHECK OPTION
• MySQL 8.0：视图元数据
• MySQL 8.0：DROP VIEW

适用环境：MySQL 8.0，主要讨论 InnoDB

事务不是把 SQL 写在一起就结束，而是为一组相关操作划定“共同成功或共同失败”的边界。

1. 事务

事务（Transaction）是数据库执行工作的逻辑单位，可以包含一条或多条 SQL。事务结束只有两种主要结果：

• COMMIT：确认全部修改，使结果持久化；
• ROLLBACK：撤销本事务尚未提交的修改；

例如“张三向李四转账 100 元”至少包含扣款和入账两次更新。如果扣款成功后程序异常，而入账没有执行，总金额就会错误；所以两次更新必须属于同一事务

事务能力由存储引擎提供；InnoDB 支持事务，MyISAM 不支持，先检查表的引擎：

show engines;
show table status like 'bank_account';
show create table bank_account;

一次事务最好只操作支持事务的表。若混入非事务表，ROLLBACK 不能撤销其修改，会破坏“共同成功或失败”。

2. ACID 特性

一致性不是“开启事务后数据库自动理解全部业务”。数据库可保证主键、外键、CHECK 等规则，但“转账总额不变”“库存不能超卖”等业务不变量仍要由正确 SQL、锁定方式和应用判断共同保证。

3. 基本语法与事务边界

show engines; 	    -- 查看支持事务的存储引擎

start transaction;  -- 从这里开始，后面的修改先不要自动提交
-- 或 begin;

-- 执行 select / insert / update / delete 后
commit;             -- 提交并结束事务/永久保存

rollback;			-- 回滚当前事务/撤销修改

START TRANSACTION 与 BEGIN 在普通 SQL 中都能开启事务；前者还能使用：

start transaction read only;
start transaction read write;
start transaction with consistent snapshot;

READ ONLY 适合明确的只读事务，InnoDB 可据此优化。WITH CONSISTENT SNAPSHOT 在 REPEATABLE READ 下立即建立一致性快照。

MySQL 不支持普通事务嵌套。在未结束的事务中再次执行 START TRANSACTION，会先隐式提交原事务，不是创建子事务。存储过程里的 BEGIN ... END 表示程序块；需要开启事务时应明确写 START TRANSACTION。

4. 转账事务实操

4.1 开启事务，执行修改后回滚

开启事务

# 开启事务
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

# 在修改之前查看表中的数据
mysql> SELECT * FROM bank_account;
+----+------+---------+
| id | name | balance |
+----+------+---------+
|  1 | 张三 | 1000.00 |
|  2 | 李四 | 1000.00 |
+----+------+---------+
2 rows in set (0.00 sec)

执行修改

# 张三余额减少 100
mysql> UPDATE bank_account
       SET balance = balance - 100
       WHERE name = '张三';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

# 李四余额增加 100
mysql> UPDATE bank_account
       SET balance = balance + 100
       WHERE name = '李四';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

# 修改之后、回滚之前查看表中的数据
mysql> SELECT * FROM bank_account;
+----+------+---------+
| id | name | balance |
+----+------+---------+
|  1 | 张三 |  900.00 |
|  2 | 李四 | 1100.00 |
+----+------+---------+
2 rows in set (0.00 sec)

回滚事务

# 回滚事务
mysql> ROLLBACK;
Query OK, 0 rows affected (0.00 sec)

# 再次查询，发现修改没有生效
mysql> SELECT * FROM bank_account;
+----+------+---------+
| id | name | balance |
+----+------+---------+
|  1 | 张三 | 1000.00 |
|  2 | 李四 | 1000.00 |
+----+------+---------+
2 rows in set (0.00 sec)

4.2 开启事务，执行修改后提交

开启事务

# 开启事务
mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

# 在修改之前查看表中的数据
mysql> SELECT * FROM bank_account;
+----+------+---------+
| id | name | balance |
+----+------+---------+
|  1 | 张三 | 1000.00 |
|  2 | 李四 | 1000.00 |
+----+------+---------+
2 rows in set (0.00 sec)

执行修改

# 张三余额减少 100
mysql> UPDATE bank_account
       SET balance = balance - 100
       WHERE name = '张三';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

# 李四余额增加 100
mysql> UPDATE bank_account
       SET balance = balance + 100
       WHERE name = '李四';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

# 修改之后、提交之前查看表中的数据
mysql> SELECT * FROM bank_account;
+----+------+---------+
| id | name | balance |
+----+------+---------+
|  1 | 张三 |  900.00 |
|  2 | 李四 | 1100.00 |
+----+------+---------+
2 rows in set (0.00 sec)

提交事务

# 提交事务
mysql> COMMIT;
Query OK, 0 rows affected (0.01 sec)

# 再次查询，数据已经被修改，说明数据已经持久化到磁盘
mysql> SELECT * FROM bank_account;
+----+------+---------+
| id | name | balance |
+----+------+---------+
|  1 | 张三 |  900.00 |
|  2 | 李四 | 1100.00 |
+----+------+---------+
2 rows in set (0.00 sec)

5. 自动提交与隐式提交

MySQL 新连接默认开启自动提交。未显式开启事务时，每条成功语句各自形成一个事务，执行后立即提交：

select @@session.autocommit;	-- 查看当前设置
set autocommit = 0;  -- 当前会话关闭自动提交
set autocommit = 1;  -- 恢复自动提交

两种常用方式：

-- 方式一：保留默认自动提交，只临时开启一次事务
start transaction;
update bank_account set balance = balance + 10 where id = 1;
commit;

-- 方式二：持续关闭当前连接的自动提交
set autocommit = 0;
update bank_account set balance = balance - 10 where id = 1;
commit;              -- 之后仍需继续显式提交或回滚

当 autocommit=0 时，会话结束而最后一个事务未提交，MySQL 会回滚它；从 0 改成 1 会隐式提交当前事务。

以下语句通常会隐式提交当前事务，不能指望随后 ROLLBACK 撤销：

• DDL：CREATE、ALTER、DROP、TRUNCATE、RENAME；
• 部分账户、管理和锁表语句；
• 再次执行 START TRANSACTION，或执行使值从 0 变为 1 的 SET autocommit=1。

注意：

[!CAUTION]

• 只要使用 start transaction 或 begin 开启事务，必须要通过 commit 提交才会持久化，与是否设置 set autocommit 无关；
• 手动提交模式下，不用显式开启事务，执行修改操作后，提交或回滚事务时直接使用commit 或 rollback；
• 已提交的事务不能回滚；

6. 保存点

涉及语法：

savepoint 保存点名称;

回滚到指定保存点：

rollback to 保存点名称;

例如：

保存点用于只撤销事务后半段，不等于提交前半段：

start transaction;
savepoint before_transfer;

update bank_account set balance = balance - 100 where id = 1;
update bank_account set balance = balance + 100 where id = 2;
rollback to savepoint before_transfer;  -- 撤销上面两次更新

-- 改用 50 元重新执行
update bank_account set balance = balance - 50 where id = 1;
update bank_account set balance = balance + 50 where id = 2;

release savepoint before_transfer;      -- 删除保存点，不提交事务
commit;

ROLLBACK TO SAVEPOINT 不结束事务；目标保存点之后创建的保存点会被删除。COMMIT 或不带保存点的 ROLLBACK 才会结束事务并清除全部保存点。InnoDB 回滚到保存点时不保证释放之后取得的全部内存行锁，因此保存点不能代替“缩短事务”。

7. 事务的隔离性和四种隔离级别

7.1 隔离性

MySQL服务被多个客户端同时访问，每个客户端执行的DML语句以事务为基本单位，那么不同的客户端在对同一张表中的同一条数据进行修改时就可能出现相互影响的情况，为保证不同事务直接执行时不受影响，因此事务之间就需要相互隔离

7.2 隔离级别及设置语法

从上往下：并发性能越低，隔离度（安全性）越高

隔离越强不代表所有事务真的在全库中逐个执行。即使是 SERIALIZABLE，互不冲突的事务仍可并发；它主要通过更严格的锁让冲突操作等待，因此吞吐量通常更低。

涉及语法：

1. 查看全局隔离级别

   select @@global.transaction_isolation;
   

2. 查看当前会话隔离级别

   select @@session.transaction_isolation;
   

以下是设置SESSION隔离级别

设置事务的隔离级别和访问模式，可以使用以下语法：

# 通过 GLOBAL | SESSION 分别指定不同作用域
SET [GLOBAL | SESSION] TRANSACTION transaction_characteristic;

transaction_characteristic: {
      ISOLATION LEVEL level
    | access_mode
}

# 隔离级别
level: {
      REPEATABLE READ     # 可重复读
    | READ COMMITTED      # 读已提交
    | READ UNCOMMITTED    # 读未提交
    | SERIALIZABLE        # 串行化
}

# 访问模式
access_mode: {
      READ WRITE          # 事务可以读取和修改数据
    | READ ONLY           # 事务只能读取数据，不能修改普通表中的数据
}

# 示例

# 设置全局事务隔离级别为串行化
# 对之后新建的连接生效，不影响当前及已有连接
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;

# 设置当前会话的事务隔离级别为串行化
# 对当前会话后续的所有事务生效，不影响正在执行的事务
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

# 不指定作用域时，只对当前会话的下一个事务生效
# 随后的事务恢复为之前的会话隔离级别
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

# 方式一：直接设置系统变量
SET GLOBAL transaction_isolation = 'SERIALIZABLE';

# 隔离级别中原本使用空格的位置，需要改成连字符
SET SESSION transaction_isolation = 'REPEATABLE-READ';


# 方式二：使用 @@GLOBAL 和 @@SESSION 设置系统变量
SET @@GLOBAL.transaction_isolation = 'SERIALIZABLE';

# 隔离级别中原本使用空格的位置，需要改成连字符
SET @@SESSION.transaction_isolation = 'REPEATABLE-READ';

使用系统变量赋值时值中写连字符，如 SET SESSION transaction_isolation='READ-COMMITTED'；使用 SET TRANSACTION ... LEVEL 语法时写空格。改变隔离级别前应确认作用域，做双会话实验时直接设置 SESSION 最清楚。

7.3 脏读示例

脏读：一个事务读取到了另一个事务尚未提交的数据。

客户端 A 设置 READ UNCOMMITTED

客户端 B 设置 READ UNCOMMITTED

客户端 A 开启事务并修改，但不提交

start transaction;

update bank_account
set balance = 100000
where name = '王五';

select *
from bank_account
where name = '王五';

客户端 A 自己看到：王五 100000.00

客户端 B 读取数据

start transaction;

select *
from bank_account
where name = '王五';

在 READ UNCOMMITTED 下，按照资料的实验逻辑，客户端 B 可以看到事务A尚未提交的修改：王五 100000.00

此时发生了脏读

客户端A                         客户端B
事务A                           事务B

START TRANSACTION
     │
UPDATE 王五=100000
     │
没有COMMIT
     │
     ├──────────────────────→ SELECT
     │                         读到100000
     │
ROLLBACK
     │
王五恢复2000
                               SELECT
                               读到2000

7.4 不可重复读示例

不可重复读：同一个事务中，使用相同条件读取同一行数据，两次得到的字段值不同。

客户端A                             客户端B
事务A                               事务B

START TRANSACTION
    │
SELECT 王五
    │
    └── 2000

                                START TRANSACTION
                                       │
                                UPDATE 王五=1000
                                       │
                                   尚未COMMIT

SELECT 王五
    │
    └── 2000
        ↑
        看不到B未提交的数据

                                   COMMIT
                                     │
                                     ↓
                                1000正式提交

SELECT 王五
    │
    └── 1000

事务A中：
第一次 = 2000
第二次 = 1000

→ 不可重复读
事务 A 中的两条查询完全相同，但第一次得到 2000，第二次得到 1000，因此称为“不可重复读”。

因为 InnoDB 在 READ COMMITTED 下，每次普通一致性查询都会建立一个新的数据快照，所以第二次查询可以看到其他事务新提交的修改。

在 REPEATABLE READ 下，同一个事务中的普通 SELECT 通常使用第一次查询建立的快照，所以能够保持重复读取结果一致。

7.5 幻读示例

幻读：同一个事务中，使用相同范围条件查询两次，第二次查询出现或消失了一些符合条件的记录

假设第一次查询余额不低于 1000 元的账户：

-- 事务 A
start transaction;

select *
from bank_account
where balance >= 1000;

第一次结果有两行：

然后事务 B 插入一条符合条件的数据并提交：

-- 事务 B
start transaction;

insert into bank_account (name, balance)
values ('王五', 2000);

commit;

事务 A 再次执行相同查询：

select *
from bank_account
where balance >= 1000;

如果第二次结果变成三行：

事务 A 会感觉像凭空出现了一条记录，因此称为“幻读”。

注意：

不可重复读是指同一行的值变了，而幻读是结果集中的行变了。

不可重复读通常是由另一个事务执行 update 并提交引起；

幻读通常是由另一个事务执行 insert 或 delete 并提交引起。

但 MySQL InnoDB 比较特殊

在InnoDB的 REPEATABLE READ 下，典型的幻读通常已经被解决。涉及到MVCC，Next-Key Lock。

7.6 串行化 SERIALIZABLE 解释

尽量让事务表现得像一个一个顺序执行。

事务A
  ↓
执行完成

事务B
  ↓
执行完成

事务C
  ↓
执行完成

8. MVCC 与一致性读原理

MVCC（多版本并发控制）让读操作在许多情况下不必阻塞写操作。InnoDB 聚集索引记录内部包含：

• DB_TRX_ID：最后一次插入或更新该行的事务 ID；
• DB_ROLL_PTR：指向 undo log 中的旧版本；
• 没有合适聚集键时还会使用隐藏的 DB_ROW_ID。

flowchart LR
    Q["一致性读与 Read View"] --> C["当前版本：trx 120"]
    C --> U1["undo 旧版本：trx 105"]
    U1 --> U2["undo 更旧版本：trx 88"]
    Q -.-> U1

查询读取当前记录后，用 Read View 判断创建该版本的事务对自己是否可见；不可见就沿 DB_ROLL_PTR 在 undo 版本链中寻找第一个可见版本。Read View 可近似理解为“生成快照时哪些事务已提交、哪些仍活跃”的可见性规则，不是复制出一整份数据库。

• READ COMMITTED：每条普通 SELECT 建立新 Read View，所以同一事务后一次查询可能看到新提交；
• REPEATABLE READ：通常由第一次一致性读建立 Read View，事务内后续普通读复用它；
• 当前事务自己的修改始终可见。

长事务会让旧版本长期不能清理，使 undo 膨胀并增加版本链读取成本，所以不要无故让事务长时间保持开启。

参考

• MySQL 8.0：事务的开始、提交与回滚
• MySQL 8.0：事务隔离级别
• MySQL 8.0：一致性非锁定读
• MySQL 8.0：InnoDB 锁
• MySQL 8.0：MVCC
• MySQL 8.0：隐式提交

适用环境：MySQL 8.0，存储引擎以 InnoDB 为主。

索引的最终目标不是“数量多”，而是让常用查询以更少的页面访问得到更少的候选行。

1. 索引

索引是存储引擎维护的、有序的数据结构。它保存索引键及定位记录所需的信息，使 MySQL 不必从第一行扫描到最后一行

索引类似书的目录，但数据库索引还会随着数据变化而维护：

• select 可能因索引减少扫描、排序和回表；
• insert、delete、更新索引列时，需要同步修改索引；
• 索引占用磁盘与缓冲池空间；
• 优化器按成本选择执行计划，有索引不等于一定使用；

因此，索引是“以空间和写入成本换取读取效率”，适合高频查询，而不是给所有列机械建索引

2. InnoDB 主要使用 B+ 树

[!NOTE]

InnoDB 是 MySQL 的一种存储引擎，负责真正管理表的数据、索引、事务等底层操作

2.1 Hash 为什么不是默认选择

Hash 根据哈希值定位桶，平均等值查找很快，但键值没有顺序，难以支持 <、between、前缀排序和连续范围扫描。InnoDB 的普通索引只支持 B-tree；MEMORY 引擎才允许显式选择 Hash。InnoDB 内部的自适应哈希索引是一种自动优化机制，不能等同于用户创建的索引。

2.2 二叉树为什么不适合磁盘索引

普通二叉搜索树可能退化成链表；

AVL、红黑树虽能控制高度，但每个节点只有两个分支；

面对海量数据时树仍然较高；

索引节点通常按“页”存储，向下一层可能意味着访问另一个页面，所以数据库更希望一层容纳更多分支，减少树高和页面访问次数

2.3 B+ 树

2.3.1 B+树的优势

B+ 树是多路平衡查找树，核心特点如下：

1. 非叶子节点主要保存分隔键和子页面指针，同一页可容纳较多分支，树通常很矮；
2. 真正的索引记录集中在叶子层，从根到任意叶子的路径长度相同；
3. 叶子页按键值顺序组织，并通过链表相连，找到范围起点后可顺序扫描；
4. 插入、删除会触发页分裂、合并或重平衡，仍能保持有序和平衡；

flowchart TD
    R["根页：分隔键"]
    R --> I1["内部页 A"]
    R --> I2["内部页 B"]
    I1 --> L1["叶子页：1～20"]
    I1 --> L2["叶子页：21～40"]
    I2 --> L3["叶子页：41～60"]
    L1 <--> L2
    L2 <--> L3

等值查询沿根页逐层缩小范围；范围查询先定位第一个叶子记录，再沿叶子页有序扫描。MySQL 文档常统称其为 B-tree，讨论 InnoDB 实现原理时通常称 B+ 树。

2.3.2 B树与B+树的区别

3. MySQL 中的页

3.1 InnoDB 的数据页

页是 InnoDB 管理索引和数据的基本单位，索引页默认大小为 16KB：

show variables like 'innodb_page_size';

每一个页中即使没有数据也会使用16KB的存储空间；

一次查询需要的页若已在 Buffer Pool 中，可直接从内存读取；不在时才需要从磁盘加载。按页读取利用了局部性：刚访问的数据及其附近数据，近期再次使用的概率较高。

一个索引页可概括为：

数据页的基本结构如下图：

页内记录通过链表维持逻辑顺序；查询时先对 Page Directory 的槽做二分定位，再在很小的分组内查找。B+ 树解决“定位哪一页”，页目录解决“在这一页的哪里”。叶子页之间的双向链表则服务于跨页范围扫描。

类似“三层 B+ 树可存两千多万行”只是基于固定页大小、索引项和行大小的估算。真实容量会受主键长度、行格式、变长列、页填充率和分裂影响；实际查询也不等于固定发生三次磁盘 I/O，因为根页和热点页通常已被缓存。

3.2 页文件头和页文件尾

页文件头与页文件尾中包含的信息如下图：

上图中我们只关注：上一页页号和下一页页号，就类似链表中的头节点、尾节点链接形成一个双向链表

3.3 页主体

页主体是保存真实数据的主要区域，在每当创建一个新页时，都会自动分配两个行，分别是页内最小行Infimun、页内最大行Supremun，这两行实际不存储任何真实信息，而是做为数据行链表的头和尾。

此外，每一个数据行都有一个记录下一行的地址偏移量的区域next_record将页内所有数据行组成了一个单向链表，其结构图如下：

当有一个新页插入数据时，将Infimun连接第一个数据行,最后一行真实数据行连接Supremun，该单向链表就如下图结构所示：

3.4 页目录

为了避免沿着链表顺序逐个比对查找每个页数百行数据，InnoDB通过二分查找法来解决查找效率问题；

所利用的方式就是在每一页中加入一个叫页目录Page Directory的结构，将页内包括头行、尾行在内的所有行进行分组，约定头行单独为一组，其他组最多8条数据，同时把每个组最后一行在页中的地址按主键从小到大的顺序记录在页目录中；

页目录中的每一个位置称为一个槽，每个槽都对应了一个分组，一旦分组中的数据行超过分组的上限8个时，就会分裂出一个新的分组；

所以后续在查询某行时，通过二分查找，先找到对应的槽，随后在槽内最多8个数据行中进行遍历即可；

3.5 数据页头

数据页头记录了当前页保存数据相关的信息，如下图：

4. 聚集索引、二级索引与回表

4.1 聚集索引

每张 InnoDB 表都有一个聚集索引，其叶子记录保存完整行数据，数据按聚集键组织：

1. 有 primary key：使用主键作为聚集索引；
2. 无主键：选择第一个所有列都为 not null 的 unique 唯一索引作为聚集索引；
3. 两者都没有：创建名为 GEN_CLUST_INDEX 的隐藏聚集索引，使用 6 字节行 ID，也就是偷偷生成DB_ROW_ID，按照这个 GEN_CLUST_INDEX 隐藏ID建立聚集索引；

所以“主键索引就是聚集索引”只适用于通常的 InnoDB 主键场景，并非概念上的绝对同义关系。主键应尽量短、稳定；因为主键值还会存入每个二级索引。递增主键通常有利于顺序插入，但仍应先满足业务身份和分布式设计要求

4.2 二级索引与回表

聚集索引之外的索引称为二级索引。其叶子记录主要保存“二级索引列 + 对应主键值”。例如往篇中提及的在 student_design2(name) 上建索引后，按姓名查询的过程是：

1. 搜索姓名索引，得到匹配记录的主键 id；
2. 再用 id 搜索聚集索引，取得完整学生行。

第二步叫回表。如果查询所需列已全部包含在同一个二级索引中，可直接返回，这叫覆盖索引。例如索引 (class_id, name) 可覆盖：

select class_id, name
from student_design2
where class_id = 1;

覆盖索引减少回表，但不要为了覆盖 select * 而建立过宽索引；宽索引会降低单页容量并增加写入成本。

5. 索引的分类

约束负责数据规则，索引负责访问路径，两者不是同一种对象。primary key、unique 会用唯一索引实现；外键要求相关列存在可用索引，从表缺少时 MySQL 会自动创建，但这不代表外键就是索引。

6. 索引操作

6.1 手动创建索引

6.1.1 主键索引

主键列的值必须唯一且非空，一张表只能定义一个主键，但主键可以由多列组成。

方式一：建表时使用列级语法

适合单列主键，写法最简洁。

create table t_user_pk1 (
    id bigint unsigned primary key auto_increment,
    username varchar(30) not null
);

方式二：建表时使用表级语法

主键定义与字段定义分开，结构更清晰，并且可以定义复合主键。

create table t_user_pk2 (
    id bigint unsigned auto_increment,
    username varchar(30) not null,
    primary key (id)
);

方式三：给已有表添加主键

先添加主键，再设置自增，是因为 auto_increment 列必须受到索引支持。

create table t_user_pk3 (
    id bigint unsigned not null,
    username varchar(30) not null
);

alter table t_user_pk3
    add primary key (id);

alter table t_user_pk3
    modify id bigint unsigned not null auto_increment;

添加前必须检查已有的 id 是否包含 NULL 或重复值，否则主键创建会失败。CREATE INDEX 不能创建主键，已有表必须使用 ALTER TABLE ... ADD PRIMARY KEY；

6.1.2 唯一索引

唯一索引用于电话号码、学号、邮箱等不可重复的业务字段。若字段允许 NULL，MySQL 唯一索引通常允许多个 NULL；要求必须填写且唯一时，应同时定义 NOT NULL。

方式一：建表时使用列级语法

create table t_user_uk1 (
    id bigint unsigned primary key auto_increment,
    username varchar(30) not null unique
);

方式二：建表时命名唯一约束

显式命名便于根据业务含义识别和删除，工程中更推荐这种写法。

create table t_user_uk2 (
    id bigint unsigned primary key auto_increment,
    username varchar(30) not null,
    constraint uk_user_username unique (username)
);

方式三：给已有表添加唯一约束

alter table t_user_uk3
    add constraint uk_user_username unique (username);

方式四：使用独立的索引语句

create unique index uk_user_username
    on t_user_uk4 (username);

UNIQUE 强调“不允许重复”的数据规则，UNIQUE INDEX 强调实现该规则的索引结构；在 MySQL 中，两者都会建立唯一索引；

6.1.3 普通索引

普通索引只提供查询访问路径，不限制字段值重复。索引名建议使用 idx_表或业务_字段，便于维护。

方式一：建表时创建

create table t_user_idx1 (
    id bigint unsigned primary key auto_increment,
    phone varchar(20),
    index idx_user_phone (phone)
);

方式二：使用 ALTER TABLE 给已有表添加

alter table t_user_idx2
    add index idx_user_phone (phone);

方式三：使用 CREATE INDEX 独立创建

create index idx_user_phone
    on t_user_idx3 (phone);

方式二和方式三最终都给已有表增加索引。ALTER TABLE 适合把多项表结构调整写在一起，CREATE INDEX 的语义则更直观。

MySQL 8.0.13 及以上还支持函数索引，表达式需要额外一层括号：

create index idx_user_birth_year
    on t_user_idx3 ((year(birthday)));

函数索引保存的是表达式结果，适合不能改写成原列范围查询、且确实频繁使用相同表达式的场景；

6.2.4 复合索引

复合索引包含两个或更多索引列，创建语法与单列索引相同，只需按查询需要排列多个字段。具体利用规则见第 7 节“复合索引与最左前缀”。

方式一：建表时创建

create table t_user_multi1 (
    id bigint unsigned primary key auto_increment,
    class_id bigint unsigned not null,
    username varchar(30) not null,
    index idx_user_class_name (class_id, username)
);

方式二：使用 ALTER TABLE 添加

alter table t_user_multi2
    add index idx_user_class_name (class_id, username);

方式三：使用 CREATE INDEX 创建

create index idx_user_class_name
    on t_user_multi3 (class_id, username);

复合索引也可以具有主键或唯一属性：

-- 复合主键：同一学生与同一课程只能形成一条记录
primary key (student_id, course_id)

-- 复合唯一索引：同一班级中学号不能重复
unique index uk_student_class_sno (class_id, sno)

6.2 查看索引

6.2.1 查看完整索引信息

下面三种写法等价，实际使用一种即可：

show index from t_user_multi1;
show indexes from t_user_multi1;
show keys from t_user_multi1;

MySQL 命令行客户端可用 \G 将宽表结果纵向显示：

show keys from t_user_multi1\G

\G 是客户端结束符，不是标准 SQL 语法。在 DBeaver 中通常直接执行带分号的 SHOW INDEX，通过结果网格查看即可。

6.2.2 查看表结构摘要

desc t_user_multi1;

DESC 的 Key 列只提供摘要：PRI 表示主键，UNI 表示唯一索引，MUL 表示该列可出现重复值的索引。它不能完整展示索引名和复合索引列顺序，因此不能代替 SHOW INDEX。

6.2.3 查看真实建表定义

show create table t_user_multi1;

修改或删除索引前先查看建表语句，可以确认字段完整属性、约束名和索引名，避免删除错对象。

6.2.4 查看是否使用索引

使用 explain + select 查询可以知道该查询是否使用了索引以及使用了哪个索引

例如：

1. select_type：查询类型，常见有simple、primary、subquery、derived、union；

2. type：MySQL 访问这张表时采用什么方式。排序有以下

   【好 <- system、const、eq_ref、ref、fulltext、ref_or_null、index_merge、unique_subquery、index_subquery、range、index、ALL -> 差】；

   All：全表扫描

   index：扫描全部索引树

   range：扫描部分索引，索引范围扫描，对索引的扫描开始于某一点，返回匹配值域的行，常见于between、<、>等的查询

   ref：使用非唯一索引或非唯一索引前缀进行的查找，不是主键或不是唯一索引

   （eq_ref和const的区别）

   eq_ref：唯一索引性扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描

   const、system：单表中最多有一个匹配行，查询起来非常迅速，例如根据主键或唯一索引查询。system是const类型的特例，当查询的表只有一行的情况下，使用system。

   NULL：不用访问表或者索引，直接就能得到结果

3. possible_keys：MySQL 判断这条 SQL 可能使用的索引，但不代表最终真的用了；

4. key：这个才表示 MySQL 最终实际选择使用的索引；

5. Extra：执行情况的说明和描述，常见有以下

6.3 修改索引

MySQL 可以重命名索引：

alter table t_user_multi1
    rename index idx_user_class_name to idx_user_class_username;

但不能直接修改索引包含的字段或字段顺序。此时应先删除旧索引，再创建新索引；把两个动作写在同一条 ALTER TABLE 中，可以清楚表达一次结构调整：

alter table t_user_multi1
    drop index idx_user_class_username,
    add index idx_user_name_class (username, class_id);

MySQL 8.0 还可修改非主键索引的可见性，用于验证优化器不使用该索引时的执行计划：

alter table t_user_multi1
    alter index idx_user_name_class invisible;

alter table t_user_multi1
    alter index idx_user_name_class visible;

不可见索引仍会在写入时维护，所以它不能减少索引的空间和写入成本。

6.4 删除索引

删除前先执行 SHOW CREATE TABLE 或 SHOW INDEX，原因是主键、唯一约束、外键和普通索引的删除语法及依赖关系不同。

6.4.1 删除主键索引

alter table t_user_pk1
    drop primary key;

主键名固定为 PRIMARY，不能使用普通的 DROP INDEX 索引名 代替。若主键列带有 auto_increment，并且主键是支持该自增列的唯一索引，直接删除会报错。应先核对字段完整定义，再移除自增属性：

-- 第一步：确认 unsigned、not null、default、comment 等原有属性
show create table t_user_pk1;

-- 第二步：只移除 auto_increment，其他需要保留的属性必须重新写全
alter table t_user_pk1
    modify id bigint unsigned not null;

-- 第三步：自增依赖解除后再删除主键
alter table t_user_pk1
    drop primary key;

MODIFY 不会自动保留未写出的字段属性，因此不能不看原定义就机械执行 MODIFY id BIGINT。生产表还应先检查该主键是否被其他表的外键引用。

6.4.2 删除普通、唯一或复合索引

以下两种写法等价：

drop index idx_user_phone on t_user_idx1;

alter table t_user_idx1
    drop index idx_user_phone;

删除唯一索引会同时取消它所实现的唯一性规则。删除复合索引会删除整个索引，不能只从索引中直接移除某一列；若需改变列组成，应删除后重建。

外键约束与支持外键的索引是两个对象。如果某索引仍被外键检查需要，MySQL 会拒绝直接删除；应先确认依赖，再决定是保留索引、建立替代索引，还是删除对应外键约束。

参考

• MySQL 8.0：InnoDB 聚集索引与二级索引
• MySQL 8.0：InnoDB 索引物理结构
• MySQL 8.0：复合索引
• MySQL 8.0：B-tree 与 Hash 索引
• MySQL 8.0：CREATE INDEX
• MySQL 8.0：EXPLAIN

适用环境：MySQL 8.0（示例按 MySQL 8.0.39 编写）

1. 联合查询解决什么问题

规范化会把实体拆到不同表中；读取完整业务信息时，需要重新组合数据

“联合查询”在本章中是一个宽泛概念，主要包括：

外键不会自动连接表，查询仍须写连接条件

2. 多表查询的逻辑与实际执行

2.1 用笛卡尔积理解逻辑结果

若 A 表有 3 行、B 表有 4 行，交叉连接会产生 3 × 4 = 12 行：

select *
from table_a cross join table_b;

内连接可在逻辑上理解为“组合后保留满足条件的行”：

select s.name, c.class_name
from student_design2 s
join class_design2 c on c.id = s.class_id;

漏写条件会使行数成倍膨胀；一对多连接还会按匹配数重复左侧行

2.2 MySQL 不一定真的生成完整笛卡尔积

笛卡尔积是逻辑模型，不等于物理执行。优化器会根据统计信息、索引和成本：

1. 决定表的连接顺序，而不一定按 SQL 中的书写顺序
2. 为每张表选择全表扫描、索引范围扫描或索引查找
3. 选择嵌套循环连接或 Hash Join 等算法
4. 尽早过滤无效行

MySQL 常用嵌套循环，合适的连接索引可加快内层查找。8.0.18 起支持 Hash Join，8.0.20 起用它替代 Block Nested-Loop 的场景

SQL 的逻辑处理顺序可简化为：

3. 内连接 INNER JOIN

3.1 语法

select 查询列
from 表1 别名1
[inner] join 表2 别名2 on 连接条件
where 普通过滤条件;

join 默认就是 inner join，内连接只返回两边能够匹配的行。

from a, b where ... 也能表达内连接，但工程中推荐显式 join ... on，因为它把连接条件与普通过滤分开，更不容易漏写条件

3.2 表别名与列歧义

多个表都有 id、name 时，裸写列名可能出现错误 1052。应使用短别名和 别名.列名：

select
    s.id as student_id,
    s.name as student_name,
    c.class_name
from student_design2 s
join class_design2 c on c.id = s.class_id
where s.name = '孙悟空';

3.3 三表、四表连接

查询每名学生的课程与成绩：

select
    s.sno,
    s.name,
    c.course_name,
    sc.score
from student_design2 s
join score_design2 sc on sc.student_id = s.id
join course_design2 c on c.id = sc.course_id
order by s.id, c.id;

每增加一张表都要确认连接列和连接基数；结果异常时检查条件、列和源数据。

3.4 连接后分组

统计每名学生已出分课程数和平均分：

select
    s.id,
    s.name,
    count(sc.score) as graded_count,
    avg(sc.score) as avg_score
from student_design2 s
join score_design2 sc on sc.student_id = s.id
group by s.id, s.name;

count(sc.score) 不统计 NULL，适合统计已出分课程；count(*) 统计结果行。开启 only_full_group_by 时，查询列应参与分组、被聚合，或能被分组列函数依赖

4. 外连接 OUTER JOIN

4.1 左连接与右连接

-- 保留左表全部行
select ...
from 表1 left join 表2 on 连接条件;

-- 保留右表全部行
select ...
from 表1 right join 表2 on 连接条件;

left join 保留左表全部行，右侧无匹配时补 NULL。交换表顺序即可把右连接改为左连接，项目中统一左连接通常更易读

统计所有班级人数，包括 0 人班级：

select
    c.id,
    c.class_name,
    count(s.id) as student_count
from class_design2 c
left join student_design2 s on s.class_id = c.id
group by c.id, c.class_name;

必须用 count(s.id)；若用 count(*)，外连接产生的空行会让空班级被统计为 1

4.2 查找“没有关联记录”的数据

查找没有任何选课记录的学生：

select s.id, s.sno, s.name
from student_design2 s
left join score_design2 sc on sc.student_id = s.id
where sc.student_id is null;

应检查右表中本来就不允许为 NULL 的主键或外键列。不要用 sc.score is null 判断“没有记录”，因为本系统允许 score 为 NULL 表示已选课但尚未出分。

这叫反连接模式，也可用 not exists 表达

4.3 ON 与 WHERE 的关键区别

on 决定如何匹配，where 过滤连接后的结果。右表条件放在 where 中会删除补出的 NULL 行，使左连接近似退化为内连接：

-- 只返回存在及格成绩的学生
select s.name, sc.score
from student_design2 s
left join score_design2 sc on sc.student_id = s.id
where sc.score >= 60;

要保留所有学生，只匹配及格成绩，应把条件写入 on：

select s.name, sc.score
from student_design2 s
left join score_design2 sc
    on sc.student_id = s.id and sc.score >= 60;

4.4 全外连接

MySQL 8.0 没有原生 full outer join，可用“左连接 + 反向左连接的未匹配部分”：

select a.id, b.id
from table_a a
left join table_b b on b.id = a.id
union all
select a.id, b.id
from table_b b
left join table_a a on a.id = b.id
where a.id is null;

5. 自连接 SELF JOIN

自连接不是新关键字，而是同一张表在一个查询中扮演不同角色，必须使用不同别名。比较同一学生的 MySQL 与 Java 成绩：

select s.name, m.score as mysql_score, j.score as java_score
from score_design2 m
join score_design2 j on j.student_id = m.student_id
join student_design2 s on s.id = m.student_id
join course_design2 cm on cm.id = m.course_id
join course_design2 cj on cj.id = j.course_id
where cm.course_name = 'MySQL'
  and cj.course_name = 'Java'
  and m.score > j.score;

用 m、j 区分两种成绩，用 student_id 保证比较同一学生。

6. 子查询

子查询嵌套在另一条语句中，其用法取决于返回一个值、一行、多行还是结果表。

6.1 标量子查询：返回一个值

查询高于全体平均分的成绩：

select student_id, course_id, score
from score_design2
where score > (
    select avg(score) from score_design2
);

单值比较要求子查询至多返回一行一列；返回多行会出现错误 1242。

6.2 多行子查询：IN

查询 Java 或 MySQL 课程的成绩：

select *
from score_design2
where course_id in (
    select id
    from course_design2
    where course_name in ('Java', 'MySQL')
);

in 表示等于集合中的任意值。若子查询含 NULL，not in 可能得到 unknown 而查不到行；排除关联记录时优先用 not exists，或显式排除 NULL。

6.3 EXISTS 与关联子查询

查询至少选过一门课的学生：

select s.id, s.name
from student_design2 s
where exists (
    select 1
    from score_design2 sc
    where sc.student_id = s.id
);

内层引用外层 s.id，属于关联子查询。exists 只判断匹配行是否存在；没有选课则用 not exists。

子查询不一定比连接慢。MySQL 可能将 in、exists 转为半连接或物化结果，应通过执行计划验证。

6.4 多列子查询

行构造器可让多个列作为一个整体比较：

select *
from score_demo
where (student_id, course_id, score) in (
    select student_id, course_id, score
    from score_demo
    group by student_id, course_id, score
    having count(*) > 1
);

内外列的数量、顺序、类型须对应。正式表已有复合主键，重复选课应在写入时被拒绝

6.5 FROM 中的子查询与 CTE

from 中的子查询称为派生表，MySQL 要求给它别名：

select t.class_id, t.avg_score
from (
    select s.class_id, avg(sc.score) as avg_score
    from student_design2 s
    join score_design2 sc on sc.student_id = s.id
    group by s.class_id
) t
where t.avg_score >= 80;

MySQL 8.0 还可用 with 名称 as (子查询) 定义 CTE，提高复杂查询可读性。派生表或 CTE 不代表一定创建磁盘临时表；优化器可能合并它，也可能物化后使用

6.6 如何选择

返回关联表列用 join；判断存在性用 exists；与单值比较用标量子查询；与集合比较用 in；复杂逻辑可用 CTE。先保证语义清楚，再验证性能

7. 集合查询

连接是在同一行上横向补列；集合操作把多个查询的结果纵向叠加

7.1 UNION 与 UNION ALL

select sno, name from current_student
union
select sno, name from archived_student;

select sno, name from current_student
union all
select sno, name from archived_student;

• union 默认去除完全相同的结果行，需要额外的去重工作
• union all 保留重复行，通常更快；业务允许重复时优先考虑
• 各查询必须返回相同列数，同一位置的数据类型应兼容
• 最终列名取第一个查询的列名或别名
• 整体排序应在最后写一次，并使用最终结果的列名：

select sno, name from current_student
union all
select sno, name from archived_student
order by sno;

7.2 MySQL 8.0.31 之后的集合运算

MySQL 8.0.31 新增 intersect（交集）和 except（差集）：

查询1 intersect [all | distinct] 查询2;

查询1 except [all | distinct] 查询2;

8.0.39 支持；旧版需用连接改写。集合运算默认 distinct。

8. 保存查询结果

8.1 INSERT ... SELECT

把查询结果插入已有表：

insert into excellent_student (student_id, avg_score)
select student_id, avg(score)
from score_design2
group by student_id
having avg(score) >= 90;

目标列与查询列的数量、顺序、类型须对应，并应显式写目标列名。目标表约束仍会执行；自增列通常省略

它只复制数据。大量迁移前先单独核对 select，并按原子性要求使用事务

8.2 CREATE TABLE ... SELECT

根据查询结果直接创建新表：

create table class_score_report as
select
    s.class_id,
    count(sc.score) as graded_count,
    avg(sc.score) as avg_score
from student_design2 s
join score_design2 sc on sc.student_id = s.id
group by s.class_id;

它适合临时报表，但不会自动创建索引，auto_increment 等属性也可能丢失，表达式应起别名。复制同构表通常使用：

create table student_backup like student_design2;
insert into student_backup select * from student_design2;

like 复制字段属性和索引，但不复制外键；完成后用 show create table 检查

9. 用 EXPLAIN 理解执行计划

不要凭 SQL 外观猜性能，应查看执行计划：

explain analyze
select s.name, sc.score
from student_design2 s
join score_design2 sc on sc.student_id = s.id;

explain 展示估算计划；explain analyze 会实际执行并显示行数与耗时，不要对高风险语句随意使用

重点检查：

1. 实际连接顺序及各步读取行数
2. key 是否使用预期索引，是否出现不必要的 ALL 扫描
3. 估算与实际行数是否差异很大
4. 是否出现 Hash Join、临时表、排序或大量循环

连接列两侧类型应一致，被驱动表的连接列需要可用索引；复合索引应依据真实筛选和排序设计。索引会增加写入成本，并非越多越好

10. 常见错误与排查

排查时先验证单表条件，再一次加入一张表和一个 on，比较每步行数，最后添加分组与排序。连接错误进入聚合后，常只留下看似合理的错误数字

11. 综合查询

查询所有学生的班级、已选课程数、平均分，并保留没有选课的学生：

select
    s.id,
    s.sno,
    s.name,
    c.class_name,
    count(sc.course_id) as course_count,
    round(avg(sc.score), 2) as avg_score
from student_design2 s
join class_design2 c on c.id = s.class_id
left join score_design2 sc on sc.student_id = s.id
group by s.id, s.sno, s.name, c.class_name
order by avg_score desc, s.id;

设计原因：

1. 学生必须属于有效班级，所以学生与班级使用内连接。
2. 学生可以暂时没有选课，所以成绩使用左连接。
3. count(sc.course_id) 让无选课学生得到 0，而不是 1。
4. avg 忽略未出分的 NULL；没有有效成绩时仍为 NULL，不同于 0 分。
5. 聚合发生在连接之后，因此分组必须与“一名学生一行”的目标粒度一致。

12. 总结

1. 内连接只保留匹配行；外连接还保留指定一侧的未匹配行。
2. on 决定如何匹配，where 过滤连接结果；自连接靠角色别名区分。
3. 子查询按结果形态选择 =、in、exists 或派生表，not in 要警惕 NULL。
4. union 去重，union all 保留重复且通常更高效。
5. insert ... select 写入已有表；create table ... select 创建表并写入。
6. 笛卡尔积解释逻辑语义，物理执行和性能必须通过 explain 验证。

参考

• MySQL 8.0：嵌套循环连接
• MySQL 8.0：Hash Join 优化
• MySQL 8.0：子查询优化
• MySQL 8.0：UNION
• MySQL 8.0：INSERT ... SELECT
• MySQL 8.0：CREATE TABLE ... SELECT
• MySQL 8.0：使用 EXPLAIN 优化查询

适用环境：MySQL 8.0（示例按 MySQL 8.0.39 编写）

1. 数据库设计

数据库设计首先考虑的是以下问题：

1. 业务中有哪些需要长期保存的对象？
2. 每个对象应该保存哪些属性？
3. 一行数据代表什么，即表的粒度是什么？
4. 哪些字段能够唯一标识一行？
5. 对象之间是一对一、一对多还是多对多？
6. 哪些数据会重复，修改时是否可能产生不一致？
7. 常用查询是什么，需要怎样的索引？

1.1 类、实体与表

类、实体和表经常近似一一对应，但不能机械地认为“一个 Java 类必须是一张表”。DTO、VO 通常不需要建表，集合属性往往要设计为子表或中间表。

2. 部分概念

2.1 表的粒度

粒度指“一行数据到底描述什么”

例如，成绩表的一行可以定义为：

一名学生对一门课程的最终成绩。

于是 (student_id, course_id) 可以唯一确定一行。如果业务改为“一名学生同一门课程可以补考多次”，原粒度就不够了，应增加 attempt_no，或单独设计考试场次表。

2.2 候选键、主键与业务键

• 候选键：能够唯一标识一行的最小字段集合。
• 主键：从候选键中选出的主要行标识。
• 业务键：业务本身具有唯一性的字段，如学号、课程编号。
• 代理键：没有业务含义、专门用于标识行的字段，如自增 id。

学生表可以使用自增 id 作为主键，同时给 sno 添加唯一约束。这样连接时主键稳定，数据库又能保证学号不重复。

2.3 函数依赖

若已知 A 的值，就能唯一确定 B 的值，可以写成：

A → B

例如：

学号 → 学生姓名
课程编号 → 课程名、学分
(学号, 课程编号) → 成绩

范式的核心就是检查：每个非关键字段究竟依赖谁。

3. 数据库范式

范式是一组减少重复和异常的设计规则。常见范式包括 1NF、2NF、3NF、BCNF、4NF 和 5NF。一般业务系统先把表设计到第三范式，再根据明确的性能证据决定是否反范式。

3.1 第一范式

一列保存一个业务意义上的值

第一范式（1NF）要求每个字段在当前业务语义下是原子的，不能在一列中保存一组可独立查询和维护的值。

反例：

course_ids 保存了多个课程编号，难以使用外键、连接和普通索引，也容易在增删编号时破坏格式。

正确方式是把选课关系拆成多行：

“原子”与业务语义有关。地址在只展示的场景中可以是一个字符串；若要按省、市统计，就应拆成独立字段或关联地区表。因此，字段使用了 MySQL 基本数据类型，并不代表设计天然合理。

3.2 第二范式

消除对复合候选键的部份依赖

第二范式（2NF）建立在 1NF 之上，要求每个非关键字段依赖候选键的全部字段，而不是只依赖其中一部分。

假设把所有数据放进一张表：

student_course(
  sno, course_code, student_name, birthday,
  course_name, credit, score
)

候选键是 (sno, course_code)，但实际依赖关系为：

sno → student_name, birthday
course_code → course_name, credit
(sno, course_code) → score

学生信息只依赖 sno，课程信息只依赖 course_code，因此发生了部分依赖，应拆为：

• 学生表：保存 sno → 学生属性。
• 课程表：保存 course_code → 课程属性。
• 成绩表：保存 (sno, course_code) → score。

不满足 2NF 容易产生四类异常：

1. 数据冗余：学生姓名和课程学分反复保存。
2. 更新异常：修改学分时必须更新多行，可能出现不同值。
3. 插入异常：还没有学生选课时，无法单独录入新课程。
4. 删除异常：删除最后一条成绩时，课程信息也被误删。

如果所有候选键都是单列，就不存在“只依赖键的一部分”，因此不会违反 2NF；但仍可能违反 3NF。

3.3 第三范式

消除非关键字段的传递依赖

第三范式（3NF）建立在 2NF 之上，重点消除非关键字段通过另一个非关键字段间接依赖候选键的情况。

反例：

student(
  id, sno, name, college_id,
  college_name, college_phone
)

依赖链为：

id → college_id → college_name, college_phone

学院名称和电话描述的是学院，不是学生。若每个学生都保存一份学院电话，修改时就会产生大量重复更新。应拆成：

student(id, sno, name, college_id)
college(id, college_name, college_phone)

记忆方式：

非关键字段应依赖于键、依赖于整个键，并且只依赖于键。

3.4 范式不是拆表越多越好

范式主要保证一致性和可维护性，不直接保证查询最快。拆表过多会增加连接查询和维护成本；反范式则会增加重复数据及同步成本。

合理顺序是先按 3NF 建立正确模型，再用真实慢查询和执行计划确认瓶颈。只有收益明确时，才增加汇总表或缓存列，并设计可靠的同步机制；不要仅凭“以后可能更快”就提前反范式。

4. E-R 图与关系落地

E-R 图用于在写 SQL 前表达实体、属性、关系、基数和可选性。矩形通常表示实体，属性描述实体特征，连线表示关系。

4.1 一对一关系（1:1）

一对一关系必须同时保证“能够引用”和“不能重复引用”。只添加普通 account_id 并不能阻止多个用户指向同一个账户。

最严格的实现是让从表主键同时充当外键：

create table user_profile (
    user_id bigint unsigned primary key,
    nickname varchar(30),
    constraint fk_user_profile_user
        foreign key (user_id) references users(id)
);

因为 user_id 是主键，所以同一用户最多只有一份档案。若使用独立主键，则关联列必须再加 unique。外键放在哪一侧，应根据生命周期和访问方向决定。

4.2 一对多关系（1:N）

把“一”方主键保存到“多”方：

class_design2.id ← student_design2.class_id

原因是一个班级对应多名学生，而每名学生只需要保存一个所属班级编号。不要在班级表中保存用逗号拼接的学生编号。

4.3 多对多关系（M:N）

关系数据库不能用一个普通外键直接表达多对多，需要建立中间表：

student_design2
        ↓ 1:N
score_design2
        ↑ N:1
course_design2

中间表不仅保存两端主键，还可以保存关系自身的属性，如成绩、选课时间、状态。若业务规定同一学生只能选同一课程一次，应使用复合主键或联合唯一约束防止组合重复。

5. 从需求到建表的设计过程

操作顺序不能颠倒：先澄清能否退课、重修和多次考试等规则，才能确定实体粒度；再用候选键和基数表达关系，通过范式检查消除错误依赖；最后根据数据范围选择类型与约束，并用真实查询设计索引。建表后还要主动测试重复学号、无效班级、重复选课和越界成绩。

6. 学生选课系统完整设计

下面是我练习用的四张练习表。

create database if not exists design_study
    character set utf8mb4
    collate utf8mb4_0900_ai_ci;

use design_study;

drop table if exists score_design2;
drop table if exists student_design2;
drop table if exists course_design2;
drop table if exists class_design2;

create table class_design2 (
    id bigint unsigned primary key auto_increment,
    class_name varchar(30) not null,
    constraint uk_class_design2_name unique (class_name)
) engine = InnoDB;

create table course_design2 (
    id bigint unsigned primary key auto_increment,
    course_code varchar(20) not null,
    course_name varchar(50) not null,
    credit decimal(3, 1) not null,
    constraint uk_course_design2_code unique (course_code),
    constraint ck_course_design2_credit
        check (credit between 0.5 and 20.0)
) engine = InnoDB;

create table student_design2 (
    id bigint unsigned primary key auto_increment,
    sno varchar(20) not null,
    name varchar(30) not null,
    birthday date,
    gender tinyint unsigned,
    enroll_date date not null,
    class_id bigint unsigned not null,
    constraint uk_student_design2_sno unique (sno),
    constraint ck_student_design2_gender
        check (gender in (0, 1, 2)),
    constraint fk_student_design2_class
        foreign key (class_id)
        references class_design2(id)
        on delete restrict
) engine = InnoDB;

create table score_design2 (
    student_id bigint unsigned not null,
    course_id bigint unsigned not null,
    score decimal(5, 2),
    selected_at datetime not null default current_timestamp,
    constraint pk_score_design2
        primary key (student_id, course_id),
    constraint ck_score_design2_score
        check (score is null or score between 0 and 100),
    constraint fk_score_design2_student
        foreign key (student_id)
        references student_design2(id)
        on delete restrict,
    constraint fk_score_design2_course
        foreign key (course_id)
        references course_design2(id)
        on delete restrict
) engine = InnoDB;

6.1 关键设计原因

• 学号使用 varchar，因为编号可能有前导 0，也不参与数学运算。
• 保存 birthday 而不是 age，因为年龄会随时间变化，可在查询时计算。
• 学分和成绩使用 decimal，避免 float 的近似值误差。
• score 允许为 null，用于表示已经选课但尚未出分；0 表示实际得了 0 分。
• 成绩表使用 (student_id, course_id) 复合主键，直接表达“一名学生一门课程一条记录”。
• on delete restrict 防止误删学生或课程后连带丢失成绩。是否级联删除必须由业务规则决定。
• 班级表不保存 student_count，因为人数可从学生表统计，重复保存会产生同步问题。

如果需要记录补考或多次考试，应将主键改为 (student_id, course_id, attempt_no)，或增加考试场次表，不能继续假设一门课程只有一个成绩。

7. 常用验证与查询

7.1 检查实际表结构

show create table score_design2;
show index from score_design2;

SHOW CREATE TABLE 用于检查主键、外键、检查约束和引擎；SHOW INDEX 用于检查索引列顺序。设计文档写了什么不重要，数据库实际创建出的结构才是最终结果。

7.2 统计班级人数

select
    c.id,
    c.class_name,
    count(s.id) as student_count
from class_design2 c
left join student_design2 s on s.class_id = c.id
group by c.id, c.class_name;