首先我们回顾一下上一章节引起线程不安全的原因

本质原因:线程在系统中的调度是无序的/随机的(抢占式执行)

  

1.抢占式执行

2.多个线程修改同一个变量.

        一个线程修改一个变量=>安全

        多个线程读取同一个变量=>安全

        多个线程修改不同的变量=>安全

3.修改操作,不是原子的.(最小不可分割的单位)

例如:对一个变量进行自增操作可分为3步:1.load 2.add 3.save

其中一个操作对应单个CPU指令,是原子的.如果跟上述自增这个操作,对应三步,也就对应多个CPU指令,大概率就不是原子的.

4.内存可见性(本章内容进行讲解)

5.指令重排序(本章内容进行讲解)

目录

1. 解决线程抢占式执行  -- 加锁

如何进行加锁呢?

Synchronized的用法(其他) 

2. 内存可见性

3. 指令重排序

---

1. 解决线程抢占式执行  -- 加锁

我们学过的join不能防止线程抢占执行吗？

这个思想是一个办法，不过如果这么搞，就不需要多线程了，直接一个线程串行执行。

多线程的初心：进行并发编程，更好地利用多核CPU.

那么如何保证自增这个操作,是一个原子的呢?--->加锁

举例:

生活中常见的例,去公共厕所.

 上厕所，打开门进去，把门锁了。上完厕所，解锁，打开门离开.

锁的核心操作有两个

1.加锁

2.解锁

         一旦某个线程加锁了之后，其他线程也想加锁，就不能直接加上了，就需要阻塞等待，一直等到拿到锁的线程释放锁了为止。

记得，线程调度，是抢占式执行的

当1号释放锁之后，等待的2和3和4，谁能抢先一步拿到锁，那是不确定的了。图中就是3号老铁抢到了.

此处的“抢占式执行”导致了线程之间的调度是“随机”的。

如何进行加锁呢?

synchronnized是java中的关键字，直接使用这个关键字来实现加锁效果.

具体如下图所示

package threading;
class Counter{private int count=0;public void add(){synchronized (this){//加锁count++;}}public int get(){return count;}
}
public class ThreadDemo10 {public static void main(String[] args) throws InterruptedException{Counter counter=new Counter();//搞两个线程，两个线程分别对这个counter自增5w次Thread t1=new Thread(()->{for (int i = 0; i <50000 ; i++) {counter.add();}});t1.start();Thread t2=new Thread(()-> {for (int i = 0; i < 50000; i++) {counter.add();}});t2.start();t1.join();t2.join();System.out.println(counter.get());}
}

运行结果:

此时来说明一个点:

join是完全让两个线程变成串行的,而加锁是将两个线程的一小部分变成串行,而不加锁的部分还是并发执行的.

加锁之前:

在上述代码中，一个线程做的工作大概是这些：

1.创建i

2.判定i<50000

3.调用add

4.count++

5.add返回

6.i++

其中只有虽然都是并行的，但是因为自增操作不是原子性的,导致线程之间出现抢占式执行.

加锁之后:

其中只有count++是串行的，(抢到锁的先自增完,剩下的再自增)剩下的12356两个线程仍然是并发的。

在保证线程安全的前提下，同时还能让代码跑的更快一些，更好地利用下多核cpu。

无论如何，加锁都可能导致阻塞。代码阻塞，对于程序的效率肯定还是会有影响的。此处虽然是加了锁，比不加锁要慢些，肯定是比串行快，比不加锁算的准。

Synchronized的用法(其他) 

1.直接修饰普通成员方法  ==> 以this为锁对象进行加锁

2.修饰静态成员方法 ==> 以类对象为锁对象

 等价于下面==>

 

2. 内存可见性

首先给出一个结论:

所谓的内存可见性就是多线程环境下，编译器对于代码优化，产生了误判，从而引起了bug，进一步导致了我们代码的bug。

下面给出一个例子

package threading;import java.util.Scanner;public class ThreadDemo11 {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(()->{Scanner scanner=new Scanner(System.in);System.out.println("请输入一个整数");flag=scanner.nextInt();});t1.start();t2.start();}
}

上述代码:我们创建了一个新的线程,里面写了一个循环,我们期待通过t2线程改变标志位,使得标志位变为非0,然后终止t1线程的循环.

运行代码,当我们多次输入1的时候,线程t1循环没有终止. 

出现的原因:

t1的这个循环,步骤是这样的,load从内存中读取数据到寄存器,cmp比较寄存器的值是否为0,

此时load的开销非常的大,要一直重复上述操作.读取内存虽然比读硬盘来的快，但是读寄存器，比读内存又要快。此时，编译器就做了一个非常大胆的操作，把load就给优化掉了。只有第一次执行load才真正的执行了。后续循环都只cmp，不load（相当于是复用之前寄存器中的load过的值）.这是编译器优化的手段，是一个非常普遍的事情，能智能地调整你的代码执行逻辑，保证程序结果不变地前提下，语句变化，通过一些列操作，让整个程序执行的效率大大提升。编译器对于“程序结果不变”单线程下判定是非常准确的。但是多线程不一定，可能导致调整后，效率提高，结果变了。

那么我们如何针对,这个操作进行修改呢?

1.可以让读寄存器的这个速度稍微慢下来,此时编译器就不会进行优化,也就会每次进行重新load这个操作,那么就会读取到真正的修改后标志位的值. 

public class ThreadDemo12 {public static int flag = 0;public static void main(String[] args) {Thread t1 = new Thread(()->{while (flag == 0){try {Thread.sleep(10);//加了sleep就让循环执行的很慢,编译器就不会进行优化.load} catch (InterruptedException e) {throw new RuntimeException(e);}}System.out.println("循环结束!t1结束");});Thread t2 = new Thread(()->{Scanner scanner = new Scanner(System.in);System.out.println("请输入一个整数:");flag = scanner.nextInt();});t1.start();t2.start();}
}

 运行结果:我们可以看到,我们成功的将线程t1的循环停止下来了.

 那么除了上述操作,我们还可以使用volatile关键字来进行修改.

被volatile修饰的变量，此时编译器就会禁止上述优化，能够保证每次都是从内存重新读取数据。

 注意:

3. 指令重排序

这就是volatile的另一个作用了,防止指令重排序

什么事指令重排序呢?

指令重排序:也是编译器优化的策略，调整了代码执行的顺序，让程序更高效。前提也是保证整体逻辑不变。谈到优化，都要保证调整之后的结果和之前是不变得。单线程下容易保证，多线程就不好说了。

举例:

就拿房子装修来说:

A买了一个新房子(精装修)

B买了一个新房子(毛坯房)

那么A这个过程就是

1.交钱 2.房地产装修 3.交付钥匙

那么B这个过程就是

1.交钱 3.交付钥匙 2.房地产装修

最后AB都拿到了一样的房子(假设装修队是一样的),但是这个过程是不一样的.

 上述伪代码

t1中的语句大体可以分为三个操作：

1.申请内存空间——交钱

2.调用构造方法（初始化内存的数据）——装修

3.把对象的引用赋值给s（内存地址的赋值）——拿到钥匙

如果是单线程环境，此处就可以指令重排序：

1肯定先执行，2和3谁先执行，谁后执行，都可以。

  

那么如果两个线程按照两种不同的方式执行呢?

如果t1按照 1 3 2的顺序执行，当t1执行完1 3 之后，即将执行2的时候，t2开始执行。由于t1的3已经执行过了，这个引用已经非空了。t2开始调用s.learn()。但是由于t1还没有初始化，learn的结果是什么不知道了，(也就是相当于A拿到了毛坯房的钥匙,这不就坏了吗)，就出现了bug。

这个代码难以演示，因为大部分情况是正确的。

上述情况,不好演示,因为大部分是正确的,但是也会发生,那么使用volatile关键字修饰这个对象进行修饰,就会保证不会受到指令重排序的影响.