JavaEE 【知识改变命运】04 多线程（3)

多线程带来的风险-线程安全

线程不安全的举例

场景： 用两个线程对同一个变量分别自增5万次，预期结果和自增结果是一个累加和，10万次。

    public static  int count;public static void main(String[] args) {Counter counter = new Counter();Thread t1 =new Thread(()->{for(int i=0;i<5_0000;i++){counter.count();}});Thread t2 =new Thread(()->{for(int i=0;i<5_0000;i++){counter.count();}});t1.start();t2.start();try {t1.join();t2.join();} catch (InterruptedException e) {e.printStackTrace();}System.out.println("Count: "+counter.count);}public  void count(){{count+=1;}} }

执行结果：

程序运行得到的结果与预期的结果值不一样，而且是一个错误的结果，而且我们程序的逻辑是正确的，这个现象所表现的问题称为线程安全问题

分析产出线程安全的原因：

1.线程是抢占式的

线程是抢占执行的（执行顺序是随机的）
由于线程的执行顺序无法为人控制，抢占式执行是造成线程安全问题的主要罪魁祸首，而且我们解决不了，完全是CPU自己调度，而且和CPU的核数有关

2. 多线程修改同一个变量（程序的要求）

单个线程修改同一个变量不会产生线程安全问题
多个线程修改不同的变量不会产生线程安全问题
多个线程修改同一个变量，会产生线程安全问题

3. 原子性

• 什么是原⼦性
  我们把⼀段代码想象成⼀个房间，每个线程就是要进⼊这个房间的⼈。如果没有任何机制保证，A进⼊房间之后，还没有出来；B 是不是也可以进⼊房间，打断 A 在房间⾥的隐私。这个就是不具备原⼦性那我们应该如何解决这个问题呢？是不是只要给房间加⼀把锁，A
  进去就把⻔锁上，其他⼈是不是就进不来了。这样就保证了这段代码的原⼦性了。 有时也把这个现象叫做同步互斥，表⽰操作是互相排斥的。
• ⼀条 java 语句不⼀定是原⼦的，也不⼀定只是⼀条指令 比如上面的：count++，对应的是多条CPU指令 1：从内存或者寄存器读取count值 LOAD 2：执行自增 ADD 3：把计算结果写回寄存器或者内存 STORE
• 不保证原⼦性会给多线程带来什么问题 如果⼀个线程正在对⼀个变量操作，中途其他线程插⼊进来了，如果这个操作被打断了，结果就可能是错误的。 这点也和线程的抢占式调度密切相关. 如果线程不是 “抢占” 的, 就算没有原⼦性, 也问题不⼤.
  

4. 内存可见性

• 什么是内存可见性 一个线程对共享变量进行了修改，其他线程能感知到变量修改后的值。
• Java内存模型（JMM） java虚拟机规范定义了Java内存模型 ⽬的是屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到⼀致的并发效果.
  
• 分析Java内存模型
  1.工作内存和线程之间是一一对应的
  2.java的共享变量都在主内存里面，java线程线程首先从主内存读取变量的值到自己的工作内存
  3.每个线程都有自己的工作内存，且线程工作内存直接是相互隔离的
  4.线程在工作内存修改完变量的值后，又从工作内存把变量的值刷回主内存里面。
  5.在以上执行count++操作，由于两个线程在执行，每个线程都有自己的工作内存，且相互不可见，最终导致了线程安全问题。线程对共享变量的修改线程之间相互感知不到
• 注意： 为什么整这么多内存？ 实际并没有这么多 “内存”. 这只是 Java 规范中的⼀个术语, 是属于 “抽象” 的叫法，所谓的 “主内存” 才是真正硬件⻆度的 “内存”. ⽽所谓的 “⼯作内存”, 则是指 CPU 的寄存器和⾼速缓存 为啥要这么⿇烦的拷来拷去? 因为
  CPU 访问⾃⾝寄存器的速度以及⾼速缓存的速度, 远远超过访问内存的速度(快了 3 - 4 个数量级,也就是⼏千倍,
  上万倍).那为什么不全部用寄存器，原因很简单，太贵了。
• 关于JMM内存模型的面试题：JMM规定
  1.所以线程不直接修改主内存中的共享变量
  2.如果修改共享变量，需要把这个变量从主内存复制到自己的工作内存中，修改完之和再刷回主内存
  3.各个线程之间不能相互通信，做到了内存级别的线程隔离。

5. 指令重排序

1.什么是指令重排序 我们写的代码，在编译之后可能与代码对应的指令顺序不同，这个过程就是指令重排序（JVM层面可能重排序，CPU执行指令也可能重排序）
1.一段代码是这样的 a.代阳去教室取英语书 b.代阳去食堂吃饭 c.代阳去教室去数学书 在单线程情况下,JVM,CPU指令集会对其优化，执行顺序按a–c–b的方式执行，也是没有问题，可以少跑一次教室，这就叫指令重排序
编译器对于指令重排序的前提是 “保持逻辑不发⽣变化”. 这⼀点在单线程环境下⽐较容易判断, 但是在多线程环境下就没那么容易了,
多线程的代码执⾏复杂程度更⾼, 编译器很难在编译阶段对代码的执⾏效果进⾏预测, 因此激进的重排序很容易导致优化后的逻辑和之前不等价

总结线程安全问题产生的原因

1. 线程是抢占式执行的

• CPU的调度问题，硬件层面，我们解决不了

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

• 在真实业务场景中，使用多线程就是为了提升效率，在并发编成中这个需求是满足的

3. 原子性

• 指令是在CPU上执行，怎么才能让CPU在执行时实现原子性，这个可能可以解决

4. 内存可见性

• java层面应该可以解决，进程之间可以进行通信，那那么在线程中应该也有这样的机制，让线程在内存中也可以彼此感知

5. 指令重排序

• 对于代码来说谁的优先级高，我们可以通过某种方式告诉编译器，不要对我的代码进行重排序

6. 总结以上1，2我们不能改变，但是3，4，5我们可以进行改变，只要满足3，4，5中的一条或者多条，线程安全问题就可以解决

解决线程安全问题

1. synchronized关键字的介绍（监视器锁 monitor lock）

a.锁的概念

比如线程A拿到了锁，别的线程如果要执行被锁住的代码，那就要等到线程A释放锁之后，如果A没有释放锁，那么别的线程只能阻塞等待，这个状态就是BLOCK

b.synchronized的特性

1. 互斥：synchronized会引起互斥效果，某个线程执行到某个对象的synchronized时，其他线程如果也执行到同一个对象sychronized就会阻塞等待
2. 保证了原子性（通过加锁实现）
3. 保证了内存可见性（通过串行执行实现）
4. 不保证有序性

c.synchronized的用法

修饰方法：

1. 修饰非静态方法：默认锁对象是this（当前对象）
2. 修饰静态方法：默认锁对象是本身类
   修饰代码块：
   可以充当锁对象的是实例对象（new出来的对象，类对象，this）

d.针对上述问题，加synchronied解决问题，分析底层逻辑

    public synchronized void count(){ //  修饰代码块加锁synchronized(this){ //            count+=1; //        }synchronized(this){count+=1;}} }

如果修饰方法：其实把方法进行了串行化处理
如果修饰的是代码块：其实把修饰代码块的内容，进行了串行话处理。对于部分类似这种要修改共享变量的情况进行串行话，其他代码模块继续并行执行，这样就可以提高效率

画图分析：

注意的点： t1释放锁之后，也可能第二次还是t1先于t2拿到锁，因为线程是抢占式执行的，不一定是t2
由于线程在执行逻辑之前要拿到锁，当拿到锁时，上一个线程已经执行完所有的指令，并把修改的值刷新会主内存，所有当前线程永远读到的是上一个线程执行完后的值

synchronized保证了原子性
因为当前线程永远拿到的是前一个线程修改后的值，所有这样也现象上实现了内存可见性，但是并没有真正对内存可见性做出技术上的处理。
synchronized没有保证有序性（不会禁止指令重排序）

e.关于synchronized的总结

1. 被synchronized修身的代码块会编成串行执行
2. synchronized可以修饰方法或者代码块
3. 被修饰的代码并不是一次性在CPU执行完，而是中途可能会被CPU调度走，当所有指令执行完后才会释放锁
4. 只给一个线程加锁，也会出现线程安全

f.不同锁对象的情况

1. 同·一个引用调用（静态和非静态）两个方法（一个用synchronized修饰一个不用synchronized不修饰）只加一把锁

public static  int count;public  static void main(String[] args) {Counter_Demo1 counter = new Counter_Demo1();Thread t1 =new Thread(()->{for(int i=0;i<5_0000;i++){counter.count();}});Thread t2 =new Thread(()->{for(int i=0;i<5_0000;i++){counter.count1();}});t1.start();t2.start();try {t1.join();t2.join();} catch (InterruptedException e) {e.printStackTrace();}System.out.println("Count: "+counter.count);}public  void count(){//修饰非静态代码块synchronized(this){count+=1;}}public  void count1(){{count+=1;}}
//修饰非静态方法    
//    public void synchronized count(){
//         {
//            count+=1;
//        }
//    }
//    public  void count1(){
//        {
//            count+=1;
//        }
//    }
修饰静态的方法和代码块
//    public static void count(){
//        //修饰代码块
//        //静态方法里面不能用this
//        synchronized(Counter_Demo1.class){
//            count+=1;
//        }
//    }
//    public static void count1(){
//        {
//            count+=1;
//        }
//    }
//    public synchronized static void count(){
//        //修饰代码块
//        //静态方法里面不能用this
//        {
//            count+=1;
//        }
//    }
//    public static void count1(){
//        {
//            count+=1;
//        }
//    }

执行结果
都不符合预期

2. 两个引用调用同一个方法（锁对象是实例对象new）

 public static  int count;public  static void main(String[] args) {Counter_Demo1 counter1 = new Counter_Demo1();Counter_Demo1 counter2 = new Counter_Demo1();Thread t1 =new Thread(()->{for(int i=0;i<5_0000;i++){counter1.count();}});Thread t2 =new Thread(()->{for(int i=0;i<5_0000;i++){counter2.count();}});t1.start();t2.start();try {t1.join();t2.join();} catch (InterruptedException e) {e.printStackTrace();}System.out.println("Count: "+counter1.count);}Object object=new Object();public void count(){synchronized (object){count+=1;}}

执行结果不符合预期

用类对象来加锁

static Object  object= new Object();public void count(){synchronized (object){count+=1;}}

执行结果符合预期

结论：

1. 只要一个线程A获得锁，没有锁竞争
2. 线程A和线程B共同抢一把锁，谁先拿到锁就先执行谁，另一个线程就要阻塞等待，等到持有锁的线程释放锁之后再竞争锁
3. 线程A与线程B抢的不是同一把锁，它们之间没有竞争关系，分别去拿到自己的锁，不存在锁关系

g.如何判断多个线程竞争的是不是同一把锁

1. 实例对象：new出来的对象，每个都是单独存在
2. 类中的属性：类没有用static修饰的变量，每个实例对象都是不同的
3. 类中的静态成员变量：用static修饰，属于类对象，全局唯一
4. 类对象:.class文件加载jvm之后的对象，全局唯一
5. 线程之间是否存在锁竞争，关键是看访问的是不是同一个锁对象，如果是则存在锁竞争，如果不是则不存在锁竞争

h.可重入锁

• 对同一个锁对象和同一个线程，如果可以重复加锁，称之为不互斥，称之为可重入。
• 对同一个锁对象和同一线程，如果不可以重复加锁，称之为互斥，就会形成死锁。
• 已经获取锁对象的线程，如果再多次进行加锁操作，不会产生互斥现象
  

I.锁对象

• 锁对象记录了获取锁的线程信息
• 任何对象都可以做锁对象
• java中每个对象都是由以下几个部分组成：
  – 1.markword
  – 2.类型指针
  – 3.实例数据
  – 4.对齐填充
  – 5对象默认带线啊哦是16byte
  
  

Java 标准库中的线程安全类

不安全类

• Arraylist
• LinkedList
• HashMap
• TreeMap
• HashSet
• TreeSet
• StringBuilder

安全类

-Vector（不推荐）

• HashTable（不推荐）

• CocurrentHashMap

• StringBuffer

• String （虽然没有加锁，但是不涉及修饰仍然是线程安全的）

volatile 关键字

解决线程安全的问题

• 真正意义上解决了内存可见性
• 解决了指令重排序（禁止指令重排序）问题
• 没有解决原子性问题

内存可见性

• 我们都知道，实际工作时候，访问的数据都是工作内存里面的数据，这样是为了保证效率，但是这样有时候会产生安全问题。但是加上 volatile , 强制读写内存. 速度是慢了, 但是数据变的更准确了
• 代码在写⼊ volatile 修饰的变量的时候
  – 改变线程⼯作内存中volatile变量副本的值
  – 将改变后的副本的值从⼯作内存刷新到主内存
• 代码在读取volatile修改的变量时候
  –从主内存中读取volatile变量的最新值到线程的⼯作内存中
  –从⼯作内存中读取volatile变量的副本

实例

static class Counter {public volatile int flag = 0;}public static void main(String[] args) {Counter counter = new Counter();Thread t1 = new Thread(() -> {while (counter.flag == 0) {// do nothing}System.out.println("循环结束!");});Thread t2 = new Thread(() -> {Scanner scanner = new Scanner(System.in);System.out.println("输⼊⼀个整数:");counter.flag = scanner.nextInt();});t1.start();t2.start();}
// 执⾏效果
// 当⽤⼾输⼊⾮0值时, t1 线程循环不会结束. (这显然是⼀个 bug)
//static class Counter {
//    public volatile int flag = 0;
//}
// 执⾏效果
// 当⽤⼾输⼊⾮0值时, t1 线程循环能够⽴即结束.

• 对于线程t1来说，只是比较flag这个变量的值，从来都没有修改过，所有认为，这个值永远也不会改变，从而也不会重新从主内存中读取值（cpu为了提升高运行效率这个值一般存在寄存器或者cpu的缓存中）

• 在多线程环境下，就会出现出现这个问题，一个线程修改了另一个线程无法感知到的变量

CPU层面保证可见性

MESI缓存 一致协议（可以理解是一种通知机制）

Java层面（保证指令顺序，从而保证内存可见性）

内存屏障：作用是保证指令执行的顺序，从而保证内存可见性

volatile写：

volatile读：

有序性：用volatile 修改过的变量，由于前后有内存屏障，保证了指令的执行顺序，也可以理解为告诉编译器，不要进行指令重排序。

总结

volatile不保证原子性

public static volatile int count;public synchronized static void main(String[] args) {Counter counter = new Counter();Thread t1 =new Thread(()->{for(int i=0;i<5_0000;i++){counter.count();}});Thread t2 =new Thread(()->{for(int i=0;i<5_0000;i++){counter.count();}});t1.start();t2.start();try {t1.join();t2.join();} catch (InterruptedException e) {e.printStackTrace();}System.out.println("Count: "+counter.count);}public  void count(){count+=1;}

volatile保证可见性：MESI缓存 一致协议（可以理解是一种通知机制）
volatile保证有序性：内存屏障：作用是保证指令执行的顺序，从而保证内存可见性

wait() 和 notify()

wait和notify的基础知识

• wait() 和notify(),notifyAll()是object方法
• wait()/wait(long timeout):让线程进入等待的线程
• notify()/notifyAll():唤醒在当前对象上等待的线程

wait()方法

• wait做的事情
  – 使当前执行代码的线程进行等待（把线程放到等待队列中）
  – 释放当前锁
  – 满足一定条件被唤醒，尝试重新获得这个锁
  – wait要搭配sychronized来使用，脱离sychronized使用wait会之间抛出异常
• wait 结束等待的条件：
  – 其他线程调用 调用该对象的notify方法
  – wait等待时间超时(wait ⽅法提供⼀个带有 timeout 参数的版本, 来指定等待时间)
  – 其他线程调用该等待线程的interrupted方法，导致wait抛出InterruptedException 异常.
• wait()方法代码使用

public static void main(String[] args) throws InterruptedException {Object object = new Object();System.out.println("等待中");synchronized (object) {object.wait(1000);}System.out.println("等待结束");}这样在执⾏到object.wait()之后就⼀直等待下去，那么程序肯定不能⼀直这么等待下去了。这个时候就
需要使⽤到了另外⼀个⽅法唤醒的⽅法notify()。

notify()⽅法

• notify ⽅法是唤醒等待的线程.
  – 方法notify()也要在同步方法或者同步代码块中执行，该方法是用来通知哪些可能等待该对象的对象锁的其他线程，对其发出通知，并使它们重新获取该对象对象锁
  – 如果由多个线程等待，则有线程调度器随机挑选出一个呈现wait状态的线程。（并没有 “先来后到”)）
  – 在notify()方法后，当前线程不会立马释放该对象锁，需要等到notify方法线程将程序执行完，也就是退出同步代码块之后才会释放锁对象。
• 使用notify()方法唤醒线程

static class WaitTask implements Runnable  {private Object locker;public WaitTask(Object locker) {this.locker = locker;}@Overridepublic void run() {synchronized (locker){try {System.out.println("等待开始") ;locker.wait();System.out.println("等待结束");} catch (InterruptedException e) {e.printStackTrace();}}}}static class NotifyTask implements Runnable {private Object locker;public NotifyTask(Object locker) {this.locker = locker;}@Overridepublic void run() {synchronized (locker) {System.out.println("notify 开始");locker.notify();System.out.println("notify 结束");}}}public static void main(String[] args) throws InterruptedException {Object locker = new Object();Thread t1 = new Thread(new WaitTask(locker));Thread t2 = new Thread(new NotifyTask(locker));t1.start();Thread.sleep(1000);t2.start();}

notifyAll()⽅法

• notify⽅法只是唤醒某⼀个等待线程. 使⽤notifyAll⽅法可以⼀次唤醒所有的等待线程.

 static class WaitTask implements Runnable {private Object locker;public WaitTask(Object locker) {this.locker = locker;}@Overridepublic void run() {synchronized (locker) {try {System.out.println("等待开始");locker.wait();System.out.println("等待结束");} catch (InterruptedException e) {e.printStackTrace();}}}}static class NotifyTask implements Runnable {private Object locker;public NotifyTask(Object locker) {this.locker = locker;}@Overridepublic void run() {synchronized (locker) {System.out.println("notify 开始");locker.notifyAll();System.out.println("notify 结束");}}}public static void main(String[] args) throws InterruptedException {Object locker = new Object();Thread t1 = new Thread(new WaitTask(locker));Thread t3 = new Thread(new WaitTask(locker));Thread t4 = new Thread(new WaitTask(locker));Thread t2 = new Thread(new NotifyTask(locker));t1.start();t3.start();t4.start();sleep(1000);t2.start();}}

注意: 虽然是同时唤醒 3 个线程, 但是这 3 个线程需要竞争锁. 所以并不是同时执⾏, ⽽仍然是有先有后的执⾏

wait 和 sleep和join的对⽐（⾯试题）

1. wait需要搭配synchronized使用 sleep，join不需要
2. wait是Object的方法，sleep是Thread的静态方法，join是类中的方法（实例方法）
3. 一个是用于线程之间的通信的，两个是让线程阻塞一段时间
4. 相同点：可以让线程放弃执行一段时间

wait和notify的总结

• join和wait是两个不同的操作
  –join是Thread类中的方法
  – wait和notify是Object类中的方法
  – join状态，主线程要等待子线程的结果
  – wait是等待另一个线程的资源
• wait和notify必须跟synchronized一起使用，并且使用同一个对象
  – 否则会报错
  
  – wait的线程进入阻塞状态，调用wait的线程会释放自己持有的锁（不再占有cpu资源）
• notify()和notifyAll()，
  – notify随机唤醒一个线程，notifyAll唤醒所有线程，唤醒后的线程需要重新去竞争锁，拿到锁之后wait位置的代码才会继续执行。
• 使用小结
  – wait和notify必须搭配synchronized一起使用
  – wait和notify使用的锁对象必须是同一个
  – notify执行多少次都没有关系（及时没有wait）（类似老板把包子做好空喊了一声）
• 举例：
  – 现实举例：
  – 指令举例