【JavaEE精炼宝库】多线程（3）线程安全

一、线程安全

1.1 经典线程不安全案例：

1.2 线程安全的概念：

1.3 线程不安全的原因：

1.3.1 案例刨析:

1.3.2 线程不安全的名词解释：

1.3.3 Java 内存模型 (JMM)：

1.3.4 解决线程不安全问题：

二、synchronized 关键字

2.1 synchronized 的特性：

2.1.1 互斥：

2.1.2 可重入：

2.2 synchronized 使用示例：

2.2.1 修饰代码块:

2.2.2 直接修饰普通方法：

2.2.3 修饰静态方法：

2.3 Java 标准库中的线程安全类：

一、线程安全

1.1 经典线程不安全案例：

线程安全是多线程中最核心的部分，因此线程安全也是难点和面试的考点，可以说只要写多线程代码，基本上都会涉及到。下面我就举一个经典的线程不安全案例，友友们来观察一下线程不安全。（注意要把自增的次数写大一点，因为如果次数太小，线程 2 还没启动线程 1 就已经运行结束了，所以看不到线程不安全的情况）。

public class Main {
    private static int count = 0;
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            //对 count 变量进行自增 5w次
            for (int i = 0; i < 50000; i++) {
                count++;
            }
        });
        Thread t2 = new Thread(() -> {
            //对 count 变量进行自增 5w次
            for (int i = 0; i < 50000; i++) {
                count++;
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        // 预期值为 10w
        System.out.println(count);
    }
}

案例的预期值应为 10w。

案例的结果如下：

如果友友们，把这个案例自己拿起来跑，会发现每次的运行的结果都有差异，不符合我们的预期，显然出现了线程不安全的问题。

1.2 线程安全的概念：

线程安全的确切定义是复杂的，但我们可以这样认为：如果在多线程环境下代码运行的结果是符合我们预期的，即在单线程环境应该的结果，则说这个程序是线程安全的。

1.3 线程不安全的原因：

1.3.1 案例刨析:

如果我们将上述的案例部分改为下面红色方框（可以解决问题，但不是一种好的方法，因为这样写就无法利用到多线程的优势，更优的方法在下面的 synchronized 中会详细介绍），那么运行的结果就符合我们的预期了。

其实就是把多线程并发执行改为串行执行。那么我们就可以确定是因为多线程才导致出现这个现象。上面不安全案例的执行过程大致如下：（）中的数字表示执行顺序。如果对工作内存和主内存不了解的话，在下面的 Java 内存模型中有解释。

之所以会出现少加 5 的情况是因为，两个线程在进行抢占式执行。

那么为什么多线程会出现这种现象呢？

线程调度是随机的，这是线程安全问题的罪魁祸首，随机调度使⼀个程序在多线程环境下，执行顺序存在很多的变数。程序猿必须保证在任意执行顺序下，代码都能正常工作。

1.3.2 线程不安全的名词解释：

• 原子性：

• 什么是原子性？

我们把⼀段代码想象成⼀个房间，每个线程就是要进入这个房间的人。如果没有任何机制保证，A进入房间之后，还没有出来，B 是不是也可以进入房间，打断 A 在房间里的隐私。这个就是不具备原子性。一条 Java 语句不一定是原子的，也不一定只是一条指令。比如我们刚才看到 count++，其实是由三步操作组成的：（1）从内存把数据读到 CPU。（2）进行数据更新。（3）把数据写回到 CPU。

• 不保证原子性会给多线程带来什么问题？

如果一个线程正在对一个变量操作，中途其他线程插入进来了，如果这个操作被打断了，结果就可能是错误的。(这点也和线程的抢占式调度密切相关。如果线程不是 "抢占" 的，就算没有原子性，也问题不大)。

• 可见性：

可见性指，一个线程对共享变量值的修改，能够及时地被其他线程看到。

• 指令重排序：

什么是代码重排序，假如：一段代码是这样的：（1）去前台取下 U 盘。（2）去教室写 10 分钟作业。（3）去前台取下快递。

如果是在单线程情况下，JVM、CPU指令集会对其进行优化，比如，按 1->3->2的方式执行，也是没问题，可以少跑一次前台。这种叫做指令重排序。

编译器对于指令重排序的前提是 "保持逻辑不发生变化"。这⼀点在单线程环境下比较容易判断，但是在多线程环境下就没那么容易了，多线程的代码执行复杂程度更高，编译器很难在编译阶段对代码的执行效果进行预测，因此激进的重排序很容易导致优化后的逻辑和之前不等价。重排序是一个比较复杂的话题，涉及到 CPU 以及编译器的一些底层工作原理，此处不做过多讨论。

1.3.3 Java 内存模型 (JMM)：

Java 虚拟机规范中定义了 Java 内存模型。目的是屏蔽掉各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的并发效果。

• 线程之间的共享变量存在主内存（Main Memory）

• 每一个线程都有自己的 "工作内存" （Working Memory）

• 当线程要读取一个共享变量的时候，会先把变量从主内存拷贝到工作内存，再从工作内存读取数据。

• 当线程要修改一个共享变量的时候，也会先修改工作内存中的副本，再同步回主内存。

由于每个线程有自己的工作内存，这些工作内存中的内容相当于同一个共享变量的 "副本"。此时修改线程 1 的工作内存中的值，线程 2 的工作内存不一定会及时变化。

此时引入了两个问题：

• 为啥要整这么多内存？

实际并没有这么多 "内存"。这只是 Java 规范中的一个术语，是属于 "抽象" 的叫法。所谓的 "主内存" 才是真正硬件角度的 "内存"。而所谓的 "工作内存"，则是指 CPU 的寄存器和高速缓存。

• 为啥要这么麻烦的拷来拷去？

因为 CPU 访问自身寄存器的速度以及高速缓存的速度，远远超过访问内存的速度(快了 3 - 4 个数量级，也就是几千倍，上万倍)。

那么接下来问题又来了，既然访问寄存器速度这么快，还要内存干啥？

答案就是一个字：贵。

1.3.4 解决线程不安全问题：

下面这几点是线程不安全问题的原因，友友们一定要记住。

1. 线程在系统中是随机调度的，抢占式执行的。（线程不安全的罪魁祸首，万恶之源）。

2. 当前代码中，多个线程同时修改同一个变量。

3. 线程针对变量的修改操作，不是“原子”的。

4. 内存可见性问题，引起的线程不安全。

5. 指令重排序，引起的线程不安全。

我们从原因入手，解决问题。

原因 1：我们无法干预，这是操作系统自己分配的，我们干预不了。

原因 2：是一个切入点，但是在 Java 中，这样的做法不是很普适（因为当前代码，就是要多线程修改同一个变量），只是针对一些特定场景是可以的。

原因 3：这是解决线程安全问题，最普适的方案。我们就从原因 3 入手。

我们可以通过一些操作，把上述一系列 “非原子” 的操作，打包成一个 “原子” 操作。就是下面要介绍的 synchronized 加锁操作。

下面给出的案例大家看看就行，关于 synchronized 后续会详细介绍。

public class Main {
    private static int count = 0;
    public static void main(String[] args) throws InterruptedException {
        Object lock = new Object();
        Thread t1 = new Thread(() -> {
            //对 count 变量进行自增 5w次
            for (int i = 0; i < 50000; i++) {
                synchronized(lock){
                    count++;
                }
            }
        });
        Thread t2 = new Thread(() -> {
            //对 count 变量进行自增 5w次
            for (int i = 0; i < 50000; i++) {
                synchronized(lock){
                    count++;
                }
            }
        });
        t1.start();
        t1.join();
        t2.start();
        t2.join();
        // 预期值为 10w
        System.out.println(count);
    }
}

案例结果：可以看到符合我们的预期值，说明线程不安全问题被成功解决。

二、synchronized 关键字

大家一定要去多练习一下 synchronized 的读法，和拼写。因为面试的时候，说出来要让面试官听得懂。注意：这是个 Java 的关键字。（注意不是方法，里面的功能是 JVM 内部实现的）。

利用 synchronized 我们就可以把花括号里面的非原子操作，打包成原子。从而不允许别的线程 “插队”。

2.1 synchronized 的特性：

2.1.1 互斥：

synchronized 会起到互斥效果，某个线程执行到某个对象的 synchronized 中时，其他线程如果也执行到同⼀个对象 synchronized 就会阻塞等待。

• 加锁：t1 加上锁之后，t2 也尝试进行加锁，就会阻塞等待（系统内核控制），在 Java 中就能看到 BLOCKED状态，进入 synchronized 修饰的代码块，相当于加锁。

• 解锁：直到 t1 解锁之后，t2 才有可能（可能还有别的线程也在等待）拿到锁，退出synchronized 修饰的代码块，相当于解锁。

synchronized 用的锁是存在 Java 对象头里的。

• 理解"阻塞等待"：

针对每一把锁，操作系统内部都维护了一个等待队列。当这个锁被某个线程占有的时候，其他线程尝试进行加锁，就加不上了，就会阻塞等待，⼀直等到之前的线程解锁之后，由操作系统唤醒一个新的线程，再来获取到这个锁。

注意：

• 上一个线程解锁之后，下一个线程并不是立即就能获取到锁，而是要靠操作系统来 "唤醒"。这也就是操作系统线程调度的一部分工作。

• 假设有 A B C 三个线程，线程 A 先获取到锁，然后 B 尝试获取锁，然后 C 再尝试获取锁，此时 B 和 C 都在阻塞队列中排队等待，但是当 A 释放锁之后，虽然 B 比 C 先来的，但是 B 不⼀定就能获取到锁，而是是和 C 重新竞争，并不遵守先来后到的规则。

synchronized的底层是使用操作系统的 mutex lock实现的。

2.1.2 可重入：

synchronized 同步块（花括号里面内容）对同一条线程来说是可重入的，不会出现自己把自己锁死的情况。

• 理解 "把自己锁死"：

⼀个线程没有释放锁，然后又尝试再次对同一对象加锁。按照之前对于锁的设定，第二次加锁的时候，就会阻塞等待，直到第一次的锁被释放，才能获取到第二个锁，但是释放第⼀个锁也是由该线程来完成，结果这个线程已经躺平了，啥都不想干了，也就无法进行解锁操作。这时候就会死锁。

这样的锁称为：不可重入锁

Java 中的 synchronized 是可重入锁，因此没有上面的问题。

案例如下：

public class demo1 {
    public static void main(String[] args) {
        Object lock = new Object();
        Thread t = new Thread(() -> {
            synchronized(lock){
                synchronized(lock){
                    System.out.println("hello t");
                }
            }
            System.out.println("t.end");
        });
        t.start();
    }
}

案列结果演示如下：

那么 synchronized 是如何完成可重入锁的这种机制呢？

在可重入锁的内部，包含了 "线程持有者" 和 "计数器" 两个信息。

• 如果某个线程加锁的时候，发现锁已经被人占用，但是恰好占用的正是自己，那么仍然可以继续获取到锁，并让计数器自增。

• 解锁的时候计数器递减为 0 的时候，才真正释放锁。(才能被别的线程获取到)

2.2 synchronized 使用示例：

在 Java 中任何一个对象都可以作为加锁的对象（Java 中特定独立的设定，其他语言中C++,Go,Python....）都是只有极少数特定的对象可以用来加锁。

synchronized 后面带上（）里面就是写的 “锁对象”。

注意：

锁对象的用途，有且只有一个，就是用来区分两个线程是否是针对同一个对象加锁。如果是，就会出现锁竞争 / 锁冲突 / 互斥，就会引起阻塞等待。如果不是，就不会出现锁竞争，也就不会阻塞等待。和对象具体是啥类型，和它里面有啥属性，有啥方法，接下来是否要操作这个对象.....统统没有任何关系，不要自己脑补出其他的功能。

2.2.1 修饰代码块:

明确指定锁哪个对象。

• 锁任意对象：

我们前面所写的都是这种写法。

public class SynchronizedDemo {
    private Object locker = new Object();
    public void method() {
        synchronized (locker) {
        }
    }
}

• 锁当前对象：

public class SynchronizedDemo {
    public void method() {
        synchronized (this) {
        }
    }
}

2.2.2 直接修饰普通方法：

当加锁的生命周期和方法的生命周期，是一样的，这个时候，就可以直接把 synchronized 写到方法上。（可以和 public 位置互换）这个写法就相当于是一进入方法就针对 this 加锁。

锁的 SynchronizedDemo 对象。

public class SynchronizedDemo {
    public synchronized void methond() {
    }
}

上面的这两种写法等价。

2.2.3 修饰静态方法：

锁的 SynchronizedDemo 类的对象（一个类可以有多个对象，但是只有一个类对象）

public class SynchronizedDemo {
    public synchronized static void method() {
    }
}

如果我们要把 synchronized 放到方法里面，但是 static 里面不能使用 this。如果使用会出现如下错误。

解决方法：我们可以利用反射来拿到类对象。

例如：

public class SynchronizedDemo {
    public static void method() {
        synchronized (Counter.class){
        }
    }
}

到这相信友友们就能理解上面利用 synchronized 解决线程不安全问题。

我们重点要理解，synchronized 锁的是什么。两个线程竞争同一把锁，才会产生阻塞等待。两个线程分别尝试获取两把不同的锁，不会产生竞争。

2.3 Java 标准库中的线程安全类：

Java 标准库中很多都是线程不安全的。这些类可能会涉及到多线程修改共享数据，又没有任何加锁措施。

例如：ArrayList、LinkedList、HashMap、TreeMap、HashSet、TreeSet、StringBuilder等。

但是还有一些是线程安全的，使用了一些锁机制来控制。

Vector(不推荐使用) 、HashTable (不推荐使用) 、ConcurrentHashMap 、 StringBuffer等。

还有的虽然没有加锁，但是不涉及 "修改"，仍然是线程安全的。例如：String。

结语：

其实写博客不仅仅是为了教大家，同时这也有利于我巩固知识点，和做一个学习的总结，由于作者水平有限，对文章有任何问题还请指出，非常感谢。如果大家有所收获的话还请不要吝啬你们的点赞收藏和关注，这可以激励我写出更加优秀的文章。