Java EE初阶启程记05---线程安全 - 指南

 个人主页：寻星探路

作者简介：Java研发方向学习者

个人专栏：、《

⭐️人生格言：没有人生来就会编程，但我生来倔强！！！

---

​

---

一、多线程带来的的风险---线程安全(重点)

1、观察线程不安全

// 此处定义⼀个 int 类型的变量
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();
    // 如果没有这俩 join, 肯定不⾏的。 线程还没⾃增完, 就开始打印了， 很可能打印出来的 count 就是个 0
    t1.join();
    t2.join();
    // 预期结果应该是10w
    System.out.println("count: " + count);
}

        大家观察下是否适用多线程的现象是否⼀致？同时尝试思考下为什么会有这样的现象发生呢？

2、线程安全的概念

想给出一个线程安全的确切定义是复杂的，但我们可以这样认为：

  如果多线程环境下代码运行的结果是符合我们预期的，即在单线程环境应该的结果，则说这个程序是线程安全的。

3、线程不安全的原因

3.1线程调度是随机的

        这是线程安全问题的罪魁祸首

        随机调度使⼀个程序在多线程环境下，执行顺序存在很多的变数

        程序猿必须保证在任意执行顺序下，代码都能正常工作

3.2修改共享数据

多个线程修改同一个变量

        上面的线程不安全的代码中，涉及到多个线程针对 count 变量进行修改

        此时这个count 是一个多个线程都能访问到的“共享数据”

3.3原子性

        当客户端A检查还有一张票时，将票卖掉，还没有执行更新数据库时，客户端B检查了票数，发现大于0，于是又卖了一次票。然后A将票数更新回数据库。这是就出现了同一张票被卖了两次。

3.3.1什么是原子性

        我们把一段代码想象成一个房间，每个线程就是要进入这个房间的人。如果没有任何机制保证，A进入房间之后，还没有出来；B是不是也可以进入房间，打断A在房间里的隐私。这个就是不具备原子性的。

        那我们应该如何解决这个问题呢？是不是只要给房间加一把锁，A进去就把门锁上，其他人是不是就进不来了。这样就保证了这段代码的原子性了。

        有时也把这个现象叫做同步互斥，表示操作是互相排斥的。

        一条java语句不一定是原子的，也不一定只是一条指令

比如刚才我们看到的n++，其实是由三步操作组成的：

1）从内存把数据读到CPU

2）进行数据更新

3）把数据写回到CPU

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

        如果一个线程正在对一个变量操作，中途其他线程插入进来了，如果这个操作被打断了，结果就可能是错误的。

        这点也和线程的抢占式调度密切相关，如果线程不是“抢占”的，就算没有原子性，也问题不大

3.4可见性

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

Java内存模型(JMM)：Java虚拟机规范中定义了Java内存模型

        目的是屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到⼀致的并发效果

        线程之间的共享变量存在主内存(MainMemory)

        每一个线程都有自己的“工作内存”(WorkingMemory)

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

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

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

1）初始情况下，两个线程的工作内存内容一致

2）一旦线程1修改了a的值，此时主内存不一定能及时同步；对应的线程2的工作内存的a的值也不一定能及时同步

这个时候代码中就容易出现问题

此时引入了两个问题：

        为啥要整这么多内存?

        为啥要这么麻烦的拷来拷去?

1) 为啥整这么多内存?

        实际并没有这么多"内存"，这只是Java规范中的一个术语，是属于"抽象"的叫法

        所谓的"主内存"才是真正硬件角度的"内存"，而所谓的"⼯作内存"，则是指CPU的寄存器和高速缓存

2) 为啥要这么麻烦的拷来拷去?

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

        比如某个代码中要连续10次读取某个变量的值，如果10次都从内存读，速度是很慢的，但是如果只是第一次从内存读，读到的结果缓存到CPU的某个寄存器中，那么后9次读数据就不必直接访问内存了，效率就大大提高了

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

答案就是一个字：贵

        值的⼀提的是,，快和慢都是相对的。CPU访问寄存器速度远远快于内存，但是内存的访问速度又远远快于硬盘

        对应的，CPU的价格最贵，内存次之，硬盘最便宜

3.5指令重排序

3.5.1什么是代码重排序

一段代码是这样的：

1）去前台取下U盘

2）去教室写10分钟作业

3）去前台取下快递

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

        编译器对于指令重排序的前提是“保持逻辑不发生变化”，这一点在单线程环境下比较容易判断，但是在多线程环境下就没那么容易了，多线程的代码执行复杂程度更高，编译器很难在编译阶段对代码的执行效果进行预测，因此激进的重排序很容易导致优化后的逻辑和之前不等价

        重排序是一个比较复杂的话题，涉及到CPU以及编译器的一些底层工作原理，此处不做过多讨论

4、解决之前的线程不安全问题

        这里用到的机制，我们马上会给大家解释

// 此处定义⼀个 int 类型的变量
private static int count = 0;
public static void main(String[] args) throws InterruptedException {
    Object locker = new Object();
    Thread t1 = new Thread(() -> {
        // 对 count 变量进⾏⾃增 5w 次
        for (int i = 0; i < 50000; i++) {
            synchronized (locker) {
                count++;
            }
        }
    });
    Thread t2 = new Thread(() -> {
        // 对 count 变量进⾏⾃增 5w 次
        for (int i = 0; i < 50000; i++) {
            synchronized (locker) {
                count++;
            }
        }
    });
    t1.start();
    t2.start();
    // 如果没有这俩 join, 肯定不⾏的。 线程还没⾃增完, 就开始打印了。 很可能打印出来的， count 就是个 0
    t1.join();
    t2.join();
    // 预期结果应该是 10w
    System.out.println("count: " + count);
}