Juc

在Java中，线程部分是一个重点，本篇文章说的JUC也是关于线程的。JUC就是java.util.concurrent工具包的简称。这是一个处理线程的工具包。

进程与线程

进程是计算机中程序关于某数据集合的一次运行活动，是系统进行资源分配和调度的基本单位，是操作系统结构的基础。

线程是操作系统能够进行运算调度的最小单位。它被包含在进程之中，是进程中的实际运作单位。一个进程中可以并发多个线程，每条线程并行执行不同的任务。

简单来说：

进程：指系统中正在运行的一个应用程序；程序一旦运行就是进程；进程—–资源配分的最小单位

线程：系统分配处理机时间资源的基本单位，或者说进程之内独立执行的一个单元的执行流。线程—-程序执行的最小单位。

比如360安全卫士，打开这个软件就是一个进程，里面有木马查杀，垃圾清理，优化加速等可以分别执行的线程。

volatile关键字

一、简介
volatile是Java提供的一种轻量级的同步机制。Java 语言包含两种内在的同步机制：同步块（或方法）和 volatile 变量，相比于synchronized（synchronized通常称为重量级锁），volatile更轻量级，因为它不会引起线程上下文的切换和调度。但是volatile 变量的同步性较差（有时它更简单并且开销更低），而且其使用也更容易出错。

二、并发编程的3个基本概念
1.原子性
定义：即一个操作或者多个操作要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。

原子性是拒绝多线程操作的，不论是多核还是单核，具有原子性的量，同一时刻只能有一个线程来对它进行操作。简而言之，在整个操作过程中不会被线程调度器中断的操作，都可认为是原子性。例如 a=1是原子性操作，但是a++和a +=1就不是原子性操作。Java中的原子性操作包括：

（1）基本类型的读取和赋值操作，且赋值必须是值赋给变量，变量之间的相互赋值不是原子性操作。

（2）所有引用reference的赋值操作

（3）java.concurrent.Atomic.* 包中所有类的一切操作

2.可见性
定义：指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

在多线程环境下，一个线程对共享变量的操作对其他线程是不可见的。Java提供了volatile来保证可见性，当一个变量被volatile修饰后，表示着线程本地内存无效，当一个线程修改共享变量后他会立即被更新到主内存中，其他线程读取共享变量时，会直接从主内存中读取。当然，synchronize和Lock都可以保证可见性。synchronized和Lock能保证同一时刻只有一个线程获取锁然后执行同步代码，并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。

3.有序性
定义：即程序执行的顺序按照代码的先后顺序执行。

Java内存模型中的有序性可以总结为：如果在本线程内观察，所有操作都是有序的；如果在一个线程中观察另一个线程，所有操作都是无序的。前半句是指“线程内表现为串行语义”，后半句是指“指令重排序”现象和“工作内存主主内存同步延迟”现象。

在Java内存模型中，为了效率是允许编译器和处理器对指令进行重排序，当然重排序不会影响单线程的运行结果，但是对多线程会有影响。Java提供volatile来保证一定的有序性。最著名的例子就是单例模式里面的DCL（双重检查锁）。另外，可以通过synchronized和Lock来保证有序性，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。

三、锁的互斥和可见性
锁提供了两种主要特性：互斥（mutual exclusion）和可见性（visibility）。

（1）互斥即一次只允许一个线程持有某个特定的锁，一次就只有一个线程能够使用该共享数据。

（2）可见性要更加复杂一些，它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的。也即当一条线程修改了共享变量的值，新值对于其他线程来说是可以立即得知的。如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值，这将引发许多严重问题。要使 volatile 变量提供理想的线程安全，必须同时满足下面两个条件：

a.对变量的写操作不依赖于当前值。

b.该变量没有包含在具有其他变量的不变式中。

实际上，这些条件表明，可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。事实上就是保证操作是原子性操作，才能保证使用volatile关键字的程序在并发时能够正确执行。

四、Java的内存模型JMM以及共享变量的可见性
JMM决定一个线程对共享变量的写入何时对另一个线程可见，JMM定义了线程和主内存之间的抽象关系：共享变量存储在主内存(Main Memory)中，每个线程都有一个私有的本地内存（Local Memory），本地内存保存了被该线程使用到的主内存的副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。

juc

对于普通的共享变量来讲，线程A将其修改为某个值发生在线程A的本地内存中，此时还未同步到主内存中去；而线程B已经缓存了该变量的旧值，所以就导致了共享变量值的不一致。解决这种共享变量在多线程模型中的不可见性问题，较粗暴的方式自然就是加锁，但是此处使用synchronized或者Lock这些方式太重量级了，比较合理的方式其实就是volatile。

需要注意的是，JMM是个抽象的内存模型，所以所谓的本地内存，主内存都是抽象概念，并不一定就真实的对应cpu缓存和物理内存

public class VolatileTest {
    static boolean run = true;

    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(()->{
            while(run){
                
            }
        },"t1");
        t.start();
        sleep(1);
        run = false; // 线程t不会如预想的停下来
    }
}

运行以上代码，可以看到结果，程序并没有结束，而是一直处于运行状态，按道理来说主线程不是将run 置于false了吗？t1应该暂停才对啊，这就涉及到可见性问题，主线程在自己的工作内存修改了run的值，但是t1线程不知道主线程修改了run的值，所以一直在运行。

解决办法：

将run用volatile修饰

再次运行程序，程序暂停下来了，说明volatile可以将run在任何一个线程中做出的修改马上让其他线程可见。(volatile是Java提供的一种轻量级的同步机制)

在while(){}里加一个System.out.println();

点开println()方法

可以看到println()里加了synchronized锁

JMM关于synchronized的两条规定:

1）线程加锁时，将清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新获取最新的值

2）线程解锁前，必须把共享变量的最新值刷新到主内存中

（注意：加锁与解锁需要是同一把锁）

synchronized具体过程是：

获得同步锁；
清空工作内存；
从主内存拷贝对象副本到工作内存；
执行代码(计算或者输出等)；
刷新主内存数据；
释放同步锁。

五、volatile变量的特性
1.保证可见性，不保证原子性
（1）当写一个volatile变量时，JMM会把该线程本地内存中的变量强制刷新到主内存中去；

（2）这个写会操作会导致其他线程中的volatile变量缓存无效。

2.禁止指令重排
重排序是指编译器和处理器为了优化程序性能而对指令序列进行排序的一种手段。重排序需要遵守一定规则：

（1）重排序操作不会对存在数据依赖关系的操作进行重排序。

　比如：a=1;b=a; 这个指令序列，由于第二个操作依赖于第一个操作，所以在编译时和处理器运行时这两个操作不会被重排序。

（2）重排序是为了优化性能，但是不管怎么重排序，单线程下程序的执行结果不能被改变

　比如：a=1;b=2;c=a+b这三个操作，第一步（a=1)和第二步(b=2)由于不存在数据依赖关系，所以可能会发生重排序，但是c=a+b这个操作是不会被重排序的，因为需要保证最终的结果一定是c=a+b=3。

重排序在单线程下一定能保证结果的正确性，但是在多线程环境下，可能发生重排序，影响结果，下例中的1和2由于不存在数据依赖关系，则有可能会被重排序，先执行status=true再执行a=2。而此时线程B会顺利到达4处，而线程A中a=2这个操作还未被执行，所以b=a+1的结果也有可能依然等于2。

public class TestVolatile{
    int a = 1;
    boolean status = false;//状态切换为true
    public void changeStatus{
        a = 2;   //1
        status = true;  //2
    }//若状态为true，则为running
    
    public void run(){
        if(status){   //3
        int b = a + 1;  //4
        System.out.println(b);
        }
    }
}

使用volatile关键字修饰共享变量便可以禁止这种重排序。若用volatile修饰共享变量，在编译时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序,volatile禁止指令重排序也有一些规则：

 a.当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行；

 b.在进行指令优化时，不能将对volatile变量访问的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。

 即执行到volatile变量时，其前面的所有语句都执行完，后面所有语句都未执行。且前面语句的结果对volatile变量及其后面语句可见。

六、volatile不适用的场景
1.volatile不适合复合操作
例如，int++不是一个原子性操作，可以由读取、加、赋值3步组成，所以结果并不能达到30000。.

2.解决方法
（1）采用synchronized

（2）采用Lock

（3）采用java并发包中的原子操作类，原子操作类是通过CAS循环的方式来保证其原子性的

七、volatile原理
volatile可以保证线程可见性且提供了一定的有序性，但是无法保证原子性。在JVM底层volatile是采用“内存屏障”来实现的。观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令，lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），内存屏障会提供3个功能：

（1）它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操作已经全部完成；

（2）它会强制将对缓存的修改操作立即写入主存；

（3）如果是写操作，它会导致其他CPU中对应的缓存行无效。

八、单例模式的双重锁为什么要加volatile

public class TestInstance{
    private volatile static TestInstance instance;
    
    public static TestInstance getInstance(){
        if(instance == null){
            synchronized(TestInstance.class){ 
                if(instance == null){
                    instance = new TestInstance();
                }
            }
        }return instance;
    }
}

需要volatile关键字的原因是，在并发情况下，如果没有volatile关键字，在第5行会出现问题。instance = new TestInstance();可以分解为3行伪代码

1
2
3

a. memory = allocate() //分配内存
b. ctorInstanc(memory) //初始化对象
c. instance = memory //设置instance指向刚分配的地址

上面的代码在编译运行时，可能会出现重排序从a-b-c排序为a-c-b。在多线程的情况下会出现以下问题。当线程A在执行第5行代码时，B线程进来执行到第2行代码。假设此时A执行的过程中发生了指令重排序，即先执行了a和c，没有执行b。那么由于A线程执行了c导致instance指向了一段地址，所以B线程判断instance不为null，会直接跳到第6行并返回一个未初始化的对象。

创建多线程的几种方式

继承Thread类创建线程

通过继承Thread类来创建并启动多线程的一般步骤如下：

1】定义Tread类的子类MyThread，并重写run()方法.run()方法的方法体（线程执行体）就是线程要执行的任务。

2】创建MyThread类的实例

3】调用子类实例的start()方法来启动线程

创建Thread1类


public class Thread1 extends Thread{
    @Override
    public void run() {
        while(true){
            System.out.println("a");
        }
    }
}

创建Thread2类

public class Thread2 extends Thread{
    @Override
    public void run() {
        while(true){
            System.out.println("b");
        }
    }
}

在主方法中：

public class Test {
    public static void main(String[] args) {
        Thread t1 =new Thread1();
        Thread t2 =new Thread2();
        t1.start();
        t2.start();
    }
}

实现 Runnable接口创建线程

通过实现Runnable接口创建并启动线程的一般步骤如下：

1】定义Runnable接口的实现类，必须重写run(）方法，这个run()方法和Thread中的run()方法一样，是线程的执行体

2】创建Runnable实现类的实例，并用这个实例作为Thread的target来创建Thread对象，这个Thread对象才是真正的线程对象

3】调用start()方法

public class RunnableTest implements Runnable{
    @Override
    public void run() {
        for (int i = 0; i < 5; i++) {
            System.out.println(Thread.currentThread().getName() + ": "+i);
        }
    }

    public static void main(String[] args) {
        RunnableTest r =new RunnableTest();
        Thread t1 =new Thread(r,"线程1");
        Thread t2 =new Thread(r,"线程2");
        t1.start();
        t2.start();
    }
}

输出：

线程2: 0
线程2: 1
线程1: 0
线程2: 2
线程1: 1
线程2: 3
线程1: 2
线程2: 4
线程1: 3
线程1: 4

继承Thread和实现Runnable接口的区别

实现Runnable接口避免单继承局限
当子类实现Runnable接口，此时子类

实现Callable接口配合FutureTask

实现

步骤：
1.创建一个实现Callable的实现类
2.实现call方法，将此线程需要执行的操作声明在call()中
3.创建Callable接口实现类的对象
4.将此Callable接口实现类的对象作为传递到FutureTask构造器中，创建FutureTask的对象
5.将FutureTask的对象作为参数传递到Thread类的构造器中，创建Thread对象，并调用start()
6.获取Callable中call方法的返回值

**实现Callable接口的方式创建线程的强大之处**
call()可以有返回值的
call()可以抛出异常，被外面的操作捕获，获取异常的信息
Callable是支持泛型的

public class ThreadNew {
    public static void main(String[] args) {
        //3.创建Callable接口实现类的对象
        NumThread numThread = new NumThread();

        //4.将此Callable接口实现类的对象作为传递到FutureTask构造器中，创建FutureTask的对象
        FutureTask futureTask = new FutureTask(numThread);

        //5.将FutureTask的对象作为参数传递到Thread类的构造器中，创建Thread对象，并调用start()
        new Thread(futureTask).start();

        try {
            //6.获取Callable中call方法的返回值
            //get()返回值即为FutureTask构造器参数Callable实现类重写的call()的返回值。
            Object sum = futureTask.get();
            System.out.println("总和为：" + sum);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (ExecutionException e) {
            e.printStackTrace();
        }
    }
}
class NumThread implements Callable {
    //2.实现call方法，将此线程需要执行的操作声明在call()中
    @Override
    public Object call() throws Exception {
        int sum = 0;
        //把100以内的偶数相加
        for (int i = 1; i <= 100; i++) {
            if (i % 2 == 0) {
                System.out.println(i);
                sum += i;
            }
        }
        return sum;
    }
}

线程池创建

来自项目中的代码
//定义一个线程池
    private static final ExecutorService CACHE_REBUILD_EXECUTOR = 			     Executors.newFixedThreadPool(10);
  .
  .
  .
  .
      		//6.3获取锁成功 ，开启独立线程进行缓存重建
  			CACHE_REBUILD_EXECUTOR.submit(()->{
                try {
                    //查询数据库
                    R r1 = dbFallback.apply(id);
                    //写入redis
                    this.setWithLogicExpire(key,r1,time,unit);
                } catch (Exception e) {
                    throw new RuntimeException(e);
                }finally {
                    //释放🔒
                    unlock(lockKey);
                }
            });

死锁

死锁的四个必要条件

互斥条件：资源是独占的且排他使用，进程互斥使用资源，即任意时刻一个资源只能给一个进程使用，其他进程若申请一个资源，而该资源被另一进程占有时，则申请者等待直到资源被占有者释放。
不可剥夺条件：进程所获得的资源在未使用完毕之前，不被其他进程强行剥夺，而只能由获得该资源的进程资源释放。
请求和保持条件：进程每次申请它所需要的一部分资源，在申请新的资源的同时，继续占用已分配到的资源。
循环等待条件：在发生死锁时必然存在一个进程等待队列{P1,P2,…,Pn},其中P1等待P2占有的资源，P2等待P3占有的资源，…，Pn等待P1占有的资源，形成一个进程等待环路，环路中每一个进程所占有的资源同时被另一个申请，也就是前一个进程占有后一个进程所深情地资源。

以上给出了导致死锁的四个必要条件，只要系统发生死锁则以上四个条件至少有一个成立。事实上循环等待的成立蕴含了前三个条件的成立，似乎没有必要列出然而考虑这些条件对死锁的预防是有利的，因为可以通过破坏四个条件中的任何一个来预防死锁的发生。

面试官：手写一个死锁demo~

public class deadLockDemo {
    public static void main(String[] args) {
        Object lock1 =new Object();
        Object lock2 =new Object();
        new Thread(new DeadLockTusk(lock1,lock2,true),"线程1").start();
        new Thread(new DeadLockTusk(lock1,lock2,false),"线程2").start();
    }
	public static class DeadLockTusk implements Runnable{
        private Object lock1;
        private Object lock2;
        private boolean flag;

        public DeadLockTusk(Object lock1, Object lock2, boolean flag) {
            this.lock1 = lock1;
            this.lock2 = lock2;
            this.flag = flag;
        }
        @Override
        public void run() {
            if(flag) {
                synchronized (lock1){
                    System.out.println(Thread.currentThread().getName()+"拿到了锁1");
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName()+"等待锁2释放");
                    synchronized (lock2){
                        System.out.println(Thread.currentThread().getName()+"拿到了锁2");
                    }
                }
            }
            if(!flag) {
                synchronized (lock2){
                    System.out.println(Thread.currentThread().getName()+"拿到了锁2");
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName()+"等待锁1释放");
                    synchronized (lock1){
                        System.out.println(Thread.currentThread().getName()+"拿到了锁1");
                    }
                }
            }
        }
    }
}

预防死锁

我们可以通过破坏死锁产生的4个必要条件来预防死锁，由于资源互斥是资源使用的固有特性是无法改变的。

破坏“不可剥夺”条件：一个进程不能获得所需要的全部资源时便处于等待状态，等待期间它占有的资源将被隐式的释放重新加入到系统的资源列表中，可以被其他的进程使用，而等待的进程只有重新获得自己原有的资源以及新申请的资源才可以重新启动，执行。
破坏”请求与保持条件“：第一种方法静态分配即每个进程在开始执行时就申请他所需要的全部资源。第二种是动态分配即每个进程在申请所需要的资源时他本身不占用系统资源。
破坏“循环等待”条件：采用资源有序分配其基本思想是将系统中的所有资源顺序编号，将紧缺的，稀少的采用较大的编号，在申请资源时必须按照编号的顺序进行，一个进程只有获得较小编号的进程才能申请较大编号的进程。

线程的状态

Java 线程在运行的生命周期中的指定时刻只可能处于下面 6 种不同状态的其中一个状态：

NEW: 初始状态，线程被创建出来但没有被调用 start() 。
RUNNABLE: 运行状态，线程被调用了 start()等待运行的状态。
BLOCKED ：阻塞状态，需要等待锁释放。
WAITING：等待状态，表示该线程需要等待其他线程做出一些特定动作（通知或中断）。(不见不散)
TIME_WAITING：超时等待状态，可以在指定的时间后自行返回而不是像 WAITING 那样一直等待。（过时不候）
TERMINATED：终止状态，表示该线程已经运行完毕。

由上图可以看出：

线程创建之后它将处于 NEW（新建） 状态，调用 start() 方法后开始运行，线程这时候处于 READY（可运行） 状态。可运行状态的线程获得了 CPU 时间片（timeslice）后就处于 RUNNING（运行） 状态。
当线程执行 wait()方法之后，线程进入 WAITING（等待） 状态。进入等待状态的线程需要依靠其他线程的通知才能够返回到运行状态。
TIMED_WAITING(超时等待) 状态相当于在等待状态的基础上增加了超时限制，比如通过 sleep（long millis）方法或 wait（long millis）方法可以将线程置于 TIMED_WAITING 状态。当超时时间结束后，线程将会返回到 RUNNABLE 状态。
当线程进入 synchronized 方法/块或者调用 wait 后（被 notify）重新进入 synchronized 方法/块，但是锁被其它线程占有，这个时候线程就会进入 BLOCKED（阻塞） 状态。
线程在执行完了 run()方法之后将会进入到 TERMINATED（终止） 状态。

同步与异步

需要等待结果返回才能继续运行就是同步
不需要等待结果返回就能继续运行就是异步

查看进程和线程的方法

Windows

任务管理器
tasklist查看进程 ( tasklist | findstr “xx”)
taskkill杀死进程

Linux

ps -ef查看所有进程(ps -ef | grep 关键字)
ps -fT -p 查看某个进程(PID)的所有线程
kill 杀死进程
top 按大写H切换是否显示线程
top -H -p 查看某个进程(PID)的所有线程

Java

jps命令查看所有Java进程
jstack 查看某个Java进程(PID)的所有线程状态
jconsole来查看某个Java进程中线程的运行情况(图像界面)

线程中的常见方法

start与run的区别

直接调用 run 是在主线程中执行了 run，没有启动新的线程
使用 start 是启动新的线程，通过新的线程间接执行 run 中的代码

Sleep

调用 sleep 会让当前线程从 Running 进入 Timed Waiting 状态（阻塞）
其它线程可以使用 interrupt 方法打断正在睡眠的线程，这时 sleep 方法会抛出 InterruptedException
睡眠结束后的线程未必会立刻得到执行
建议用 TimeUnit 的 sleep 代替 Thread 的 sleep 来获得更好的可读性

yield(让出，谦让)

调用 yield 会让当前线程从 Running 进入 Runnable 就绪状态，然后调度执行其它线程
具体的实现依赖于操作系统的任务调度器

join(重要)

下面的代码执行，打印 r 是什么？

static int r = 0;
public static void main(String[] args) throws InterruptedException {
 test1();
}
private static void test1() throws InterruptedException {
 log.debug("开始");
 Thread t1 = new Thread(() -> {
 log.debug("开始");
 sleep(1);
 log.debug("结束");
 r = 10;
 });
 t1.start();
 log.debug("结果为:{}", r);
 log.debug("结束");
}

分析

因为主线程和线程 t1 是并行执行的，t1 线程需要 1 秒之后才能算出 r=10
而主线程一开始就要打印 r 的结果，所以只能打印出 r=0

解决方法

用 sleep 行不行？为什么？
用 join，加在 t1.start() 之后即可

Eg: t1.join() == 主线程等待t1运行结束再运行后面的内容。

加了join，异步—>同步

interrupt

注意：interrupt只会给线程打个标记，不会真的打断线程，要打断线程还是得靠isInterrupted()方法判断再决定是否打断。

public static void main(String[] args) throws InterruptedException {
        Thread thread=new Thread(()->{
            while(true){
                System.out.println("正在运行。。。");
            }
        },"t1");

        thread.start();
        Thread.sleep(500);
        thread.interrupt();
    }

结果是不断得打印“正在运行。。。”

可以打断 sleep，wait，join 的线程

这几个方法都会让线程进入阻塞状态

打断sleep,wait,join的线程，会清空打断状态

private static void test1() throws InterruptedException {
 	Thread t1 = new Thread(()->{
 		sleep(1);
 	}, "t1");
 	t1.start();
 	sleep(0.5);
 	t1.interrupt();
 	log.debug(" 打断状态: {}", t1.isInterrupted());
}

输出:
java.lang.InterruptedException: sleep interrupted
 at java.lang.Thread.sleep(Native Method)
 at java.lang.Thread.sleep(Thread.java:340)
 at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
 at cn.itcast.n2.util.Sleeper.sleep(Sleeper.java:8)
 at cn.itcast.n4.TestInterrupt.lambda$test1$3(TestInterrupt.java:59)
 at java.lang.Thread.run(Thread.java:745)
21:18:10.374 [main] c.TestInterrupt - 打断状态: false

打断正常运行的线程, 不会清空打断状态

private static void test2() throws InterruptedException {
 Thread t2 = new Thread(()->{
 	while(true) {
 		Thread thread = Thread.currentThread();
 		boolean interrupted = thread.isInterrupted();
 		if(interrupted) {
 			log.debug(" 打断状态: {}", interrupted);
 			break;
 		}
 	}
 }, "t2");
 	t2.start();
 	sleep(0.5);
 	t2.interrupt();
}

1	`20:57:37.964 [t2] c.TestInterrupt - 打断状态: true`

两阶段终止模式

Two Phase Termination

在一个线程T1中如何‘优雅“终止线程T2？这里的”优雅“指的是给T2一个料理后事的机会

比如释放资源，避免不释放资源的情况

public class Test {
    public static void main(String[] args) throws InterruptedException {
        TwoPhaseTermination tpt = new TwoPhaseTermination();
        tpt.start();
        Thread.sleep(3500);
        tpt.stop();
    }
}
class TwoPhaseTermination {
    private Thread monitor;
    // 启动监控线程
    public void start() {
        monitor = new Thread(new Runnable() {
            @Override
            public void run() {
                while (true) {
                    Thread thread = Thread.currentThread();
                    if (thread.isInterrupted()) {//通过线程自带的是否被中断过标签
                        /*
                         *被打断后的操作，业务处理在这里处理
                        */
                        System.out.println("后置处理");
                        break;
                    }
                    try {
                        Thread.sleep(1000);					// 睡眠
                        System.out.println("执行监控记录");	// 在此被打断不会异常
                    } catch (InterruptedException e) {		// 在睡眠期间被打断，进入异常处理的逻辑
                        e.printStackTrace();
                        // 重新设置打断标记，打断 sleep 会清除打断状态
                        thread.interrupt();
                    }
                }
            }
        });
        monitor.start();
    }
    // 停止监控线程
    public void stop() {
        monitor.interrupt();
    }
}

park

使用park，线程会在该处停止，可以用interrupt方法打断使其继续运行，但是interrupt会使打断标记为true，park接下来会失效，不会阻塞，isInterruped方法不会清除打断标记，打断标记依然为ture，park依然失效，此时使用Interruped方法，会清除打断标记，此时打断标记为false，park又可以生效了，继续阻塞。

private static void test3() throws InterruptedException {
 Thread t1 = new Thread(() -> {
 	log.debug("park...");
 	LockSupport.park();
 	log.debug("unpark...");
 	log.debug("打断状态：{}", Thread.currentThread().isInterrupted());
 }, "t1");
 	t1.start();
 	sleep(0.5);
 	t1.interrupt();
}

1
2
3

21:11:52.795 [t1] c.TestInterrupt - park... 
21:11:53.295 [t1] c.TestInterrupt - unpark... 
21:11:53.295 [t1] c.TestInterrupt - 打断状态：true

打断标记为真时，park会失效

private static void test4() {
 Thread t1 = new Thread(() -> {
 	for (int i = 0; i < 5; i++) {
 	log.debug("park...");
 	LockSupport.park();
 	log.debug("打断状态：{}", Thread.currentThread().isInterrupted());
 }
 });
 	t1.start();
 	sleep(1);
 	t1.interrupt();
}

21:13:48.783 [Thread-0] c.TestInterrupt - park... 
21:13:49.809 [Thread-0] c.TestInterrupt - 打断状态：true 
21:13:49.812 [Thread-0] c.TestInterrupt - park... 
21:13:49.813 [Thread-0] c.TestInterrupt - 打断状态：true 
21:13:49.813 [Thread-0] c.TestInterrupt - park... 
21:13:49.813 [Thread-0] c.TestInterrupt - 打断状态：true 
21:13:49.813 [Thread-0] c.TestInterrupt - park... 
21:13:49.813 [Thread-0] c.TestInterrupt - 打断状态：true 
21:13:49.813 [Thread-0] c.TestInterrupt - park... 
21:13:49.813 [Thread-0] c.TestInterrupt - 打断状态：true

提示:

可以使用 Thread.interrupted() 清除打断状态

wait/notify用例

让我们先通过一个示例解析

wait()方法可以使线程进入等待状态，并且会释放synchronized锁,而notify()可以使等待的状态唤醒。这样的同步机制十分适合生产者、消费者模式：消费者消费某个资源，而生产者生产该资源。当该资源缺失时，消费者调用wait()方法进行自我阻塞，等待生产者的生产；生产者生产完毕后调用notify/notifyAll()唤醒消费者进行消费。

以下是代码示例，其中flag标志表示资源的有无。


public class ThreadTest {

    static final Object obj = new Object();  //对象锁

    private static boolean flag = false;

    public static void main(String[] args) throws Exception {

        Thread consume = new Thread(new Consume(), "Consume");
        Thread produce = new Thread(new Produce(), "Produce");
        consume.start();
        Thread.sleep(1000);
        produce.start();

        try {
            produce.join();
            consume.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    // 生产者线程
    static class Produce implements Runnable {

        @Override
        public void run() {
            synchronized (obj) {
                System.out.println("进入生产者线程");
                System.out.println("生产");
                try {
                    TimeUnit.MILLISECONDS.sleep(2000);  //模拟生产过程
                    flag = true;
                    obj.notify();  //通知消费者
                    TimeUnit.MILLISECONDS.sleep(1000);  //模拟其他耗时操作
                    System.out.println("退出生产者线程");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }

    //消费者线程
    static class Consume implements Runnable {

        @Override
        public void run() {
            synchronized (obj) {
                System.out.println("进入消费者线程");
                System.out.println("wait flag 1:" + flag);
                while (!flag) {  //判断条件是否满足，若不满足则等待
                    try {
                        System.out.println("还没生产，进入等待");
                        obj.wait();
                        System.out.println("结束等待");
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
                System.out.println("wait flag 2:" + flag);
                System.out.println("消费");
                System.out.println("退出消费者线程");
            }

        }
    }
}

输出结果为：

进入消费者线程

wait flag 1:false

还没生产，进入等待

进入生产者线程

生产

退出生产者线程

结束等待

wait flag 2:true

消费

退出消费者线程

理解了输出结果的顺序，也就明白了wait/notify的基本用法。有以下几点需要知道：

在示例中没有体现但很重要的是，wait/notify方法的调用必须处在该对象的锁（Monitor）中，也即，在调用这些方法时首先需要获得该对象的锁。否则会抛出IllegalMonitorStateException异常。
从输出结果来看，在生产者调用notify()后，消费者并没有立即被唤醒，而是等到生产者退出同步块后才唤醒执行。（这点其实也好理解，synchronized同步方法（块）同一时刻只允许一个线程在里面，生产者不退出，消费者也进不去）
注意，消费者被唤醒后是从wait()方法（被阻塞的地方）后面执行，而不是重新从同步块开始。

这一节我们探讨wait/notify与线程状态之间的关系。深入了解线程的生命周期。

由前面线程的状态转化图可知，当调用wait()方法后，线程会进入WAITING(等待状态)，后续被notify()后，并没有立即被执行，而是进入等待获取锁的阻塞队列。

对于每个对象来说，都有自己的等待队列和阻塞队列。以前面的生产者、消费者为例，我们拿obj对象作为对象锁，配合图示。内部流程如下

当线程A（消费者）调用wait()方法后，线程A让出锁，自己进入等待状态，同时加入锁对象的等待队列。
线程B（生产者）获取锁后，调用notify方法通知锁对象的等待队列，使得线程A从等待队列进入阻塞队列。
线程A进入阻塞队列后，直至线程B释放锁后，线程A竞争得到锁继续从wait()方法后执行。

主线程和守护线程

默认情况下，Java 进程需要等待所有线程都运行结束，才会结束。有一种特殊的线程叫做守护线程，只要其它非守护线程运行结束了，即使守护线程的代码没有执行完，也会强制结束。

log.debug("开始运行...");
	Thread t1 = new Thread(() -> {
 		log.debug("开始运行...");
 		sleep(2);
 		log.debug("运行结束...");
	}, "daemon");
// 设置该线程为守护线程
t1.setDaemon(true);
t1.start();
sleep(1);
log.debug("运行结束...");

1
2
3

08:26:38.123 [main] c.TestDaemon - 开始运行... 
08:26:38.213 [daemon] c.TestDaemon - 开始运行... 
08:26:39.215 [main] c.TestDaemon - 运行结束...

注意

垃圾回收器线程就是一种守护线程
Tomcat 中的 Acceptor 和 Poller 线程都是守护线程，所以 Tomcat 接收到 shutdown 命令后，不会等待它们处理完当前请求

线程的五种状态

这里的五种状态是从操作系统层面描述的

【初始状态】仅是在语言层面创建了线程对象，还未与操作系统线程关联
【可运行状态】（就绪状态）指该线程已经被创建（与操作系统线程关联），可以由 CPU 调度执行
【运行状态】指获取了 CPU 时间片运行中的状态当 CPU 时间片用完，会从【运行状态】转换至【可运行状态】，会导致线程的上下文切换
【阻塞状态】如果调用了阻塞 API，如 BIO 读写文件，这时该线程实际不会用到 CPU，会导致线程上下文切换，进入【阻塞状态】
- 等 BIO 操作完毕，会由操作系统唤醒阻塞的线程，转换至【可运行状态】
- 与【可运行状态】的区别是，对【阻塞状态】的线程来说只要它们一直不唤醒，调度器就一直不会考虑调度它们
【终止状态】表示线程已经执行完毕，生命周期已经结束，不会再转换为其它状态

线程的六种状态

这里从Java API层面描述的

根据Thread.State，分为六种状态

状态名称	说明
NEW	初始状态，线程被构建，但未调用start()方法
RUNNABLE	运行状态，调用start()方法后。在java线程中，将操作系统线程的就绪和运行统称运行状态
BLOCKED	阻塞状态，线程等待进入synchronized代码块或方法中，等待获取锁
WAITING	等待状态，线程可调用wait、join等操作使自己陷入等待状态，并等待其他线程做出特定操作（如notify或中断）
TIMED_WAITING	超时等待，线程调用sleep(timeout)、wait(timeout)等操作进入超时等待状态，超时后自行返回
TERMINATED	终止状态，线程运行结束

共享模型之管程

线程安全问题Java体现

两个线程对初始值为 0 的静态变量一个做自增，一个做自减，各做 5000 次，结果是 0 吗？

static int counter = 0;
public static void main(String[] args) throws InterruptedException {
 	Thread t1 = new Thread(() -> {
 		for (int i = 0; i < 5000; i++) {
 			counter++;
 		}
 		}, "t1");
 	Thread t2 = new Thread(() -> {
		 for (int i = 0; i < 5000; i++) {
 			counter--;
 		 }
 	}, "t2");
 	t1.start();
 	t2.start();
 	t1.join();
 	t2.join();
 	log.debug("{}",counter);
}

问题分析

以上的结果可能是正数、负数、零。为什么呢？因为 Java 中对静态变量的自增，自减并不是原子操作，要彻底理解，必须从字节码来进行分析

例如对于 i++ 而言（i 为静态变量），实际会产生如下的 JVM 字节码指令：

getstatic i // 获取静态变量i的值
iconst_1 // 准备常量1
iadd // 自增
putstatic i // 将修改后的值存入静态变量i

而对应 i– 也是类似：

getstatic i // 获取静态变量i的值
iconst_1 // 准备常量1
isub // 自减
putstatic i // 将修改后的值存入静态变量i

临界区 Critical Section

一个程序运行多个线程本身是没有问题的
问题出在多个线程访问共享资源
- 多个线程读共享资源其实也没有问题
- 在多个线程对共享资源读写操作时发生指令交错，就会出现问题
一段代码块内如果存在对共享资源的多线程读写操作，称这段代码块为临界区

例如，下面代码中的临界区

static int counter = 0;
static void increment() 
// 临界区
{ 
 counter++;
}
static void decrement() 
// 临界区
{ 
 counter--;
}

解决办法一：加synchronized锁对临界区进行保护

public static final Object lock =new Object();
    static int counter = 0;
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
                for (int i = 0; i < 5000; i++) {
                    synchronized (lock){
                        counter++;
                    }
                }
        }, "t1");
        Thread t2 = new Thread(() -> {
                for (int i = 0; i < 5000; i++) {
                    synchronized (lock){
                        counter--;
                    }
                }
        }, "t2");
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        log.debug("{}",counter);
    }

你可以做这样的类比：

synchronized(对象) 中的对象，可以想象为一个房间（room），有唯一入口（门）房间只能一次进入一人进行计算，线程 t1，t2 想象成两个人
当线程 t1 执行到 synchronized(room) 时就好比 t1 进入了这个房间，并锁住了门拿走了钥匙，在门内执行 count++ 代码
这时候如果 t2 也运行到了 synchronized(room) 时，它发现门被锁住了，只能在门外等待，发生了上下文切换，阻塞住了
这中间即使 t1 的 cpu 时间片不幸用完，被踢出了门外（不要错误理解为锁住了对象就能一直执行下去哦），这时门还是锁住的，t1 仍拿着钥匙，t2 线程还在阻塞状态进不来，只有下次轮到 t1 自己再次获得时间片时才能开门进入
当 t1 执行完 synchronized{} 块内的代码，这时候才会从 obj 房间出来并解开门上的锁，唤醒 t2 线程把钥匙给他。t2 线程这时才可以进入 obj 房间，锁住了门拿上钥匙，执行它的 count– 代码

synchronized 实际是用对象锁保证了临界区内代码的原子性，临界区内的代码对外是不可分割的，不会被线程切换所打断。确保了一个操作的原子性。

方法上的 synchronized

一：加在普通方法上

class Test{
 public synchronized void test() {
 
 }
}
等价于
class Test{
 	public void test() {
 		synchronized(this) {
 
 		}
 	}
}

相当于锁住this对象

二：加在静态方法上

class Test{
 	public synchronized static void test() {
 	
 	}
}
等价于
class Test{
 	public static void test() {
 		synchronized(Test.class) {
 
 		}
 	}
}

加在静态方法上相当于锁住类对象。

变量的线程安全分析

成员变量和静态变量是否线程安全？

如果它们没有共享，则线程安全
如果它们被共享了，根据它们的状态是否能够改变，又分两种情况
- 如果只有读操作，则线程安全
- 如果有读写操作，则这段代码是临界区，需要考虑线程安全

局部变量是否线程安全

局部变量是线程安全的
但局部变量引用的对象未必
- 如果该对象没有逃离方法的作用访问，它是线程安全的
- 如果该对象逃离方法的作用范围，需要考虑线程安全

局部变量线程安全分析

这里的static是加在方法上，test1()是一个静态方法，i还是局部变量
public static void test1() {
 	int i = 10;
 	i++;
}

每个线程调用 test1() 方法时局部变量 i，会在每个线程的栈帧内存中被创建多份，因此不存在共享

public static void test1();
 descriptor: ()V
 flags: ACC_PUBLIC, ACC_STATIC
 Code:
 stack=1, locals=1, args_size=0
 0: bipush 10
 2: istore_0
 3: iinc 0, 1
 6: return
 LineNumberTable:
 line 10: 0
 line 11: 3
 line 12: 6
 LocalVariableTable:
 Start Length Slot Name Signature
 3 4 0 i I

局部变量的引用

在类里，方法外的变量的成员变量。方法里的叫局部变量。

class ThreadUnsafe {
	//这里的list是成员变量
 	ArrayList<String> list = new ArrayList<>();
 	public void method1(int loopNumber) {
 		for (int i = 0; i < loopNumber; i++) {
 			// { 临界区, 会产生竞态条件
 			method2();
 			method3();
  			// } 临界区
 		}
 	}
 	private void method2() {
 		list.add("1");
 	}
 	private void method3() {
 		list.remove(0);
 	}
}

执行

static final int THREAD_NUMBER = 2;
static final int LOOP_NUMBER = 200;
public static void main(String[] args) {
 	ThreadUnsafe test = new ThreadUnsafe();
 	for (int i = 0; i < THREAD_NUMBER; i++) {
 		new Thread(() -> {
 			test.method1(LOOP_NUMBER);
 		}, "Thread" + i).start();
 	}
}

其中一种情况是，如果线程2 还未 add，线程1 remove 就会报错：

Exception in thread "Thread1" java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 
 at java.util.ArrayList.rangeCheck(ArrayList.java:657) 
 at java.util.ArrayList.remove(ArrayList.java:496) 
 at cn.itcast.n6.ThreadUnsafe.method3(TestThreadSafe.java:35) 
 at cn.itcast.n6.ThreadUnsafe.method1(TestThreadSafe.java:26) 
 at cn.itcast.n6.TestThreadSafe.lambda$main$0(TestThreadSafe.java:14) 
 at java.lang.Thread.run(Thread.java:748)

分析：

无论哪个线程中的 method2 引用的都是同一个对象中的 list 成员变量
method3 与 method2 分析相同

解决办法：将list修改为局部变量

class ThreadSafe {
 	public final void method1(int loopNumber) {
 		//这里的list就是局部变量
 		ArrayList<String> list = new ArrayList<>();
 		for (int i = 0; i < loopNumber; i++) {
 			method2(list);
 			method3(list);
 		}
 	}
 private void method2(ArrayList<String> list) {
 	list.add("1");
 }
 private void method3(ArrayList<String> list) {
 	list.remove(0);
 }
}

分析：

list 是局部变量，每个线程调用时会创建其不同实例，没有共享
而 method2 的参数是从 method1 中传递过来的，与 method1 中引用同一个对象
method3 的参数分析与 method2 相同

方法访问修饰符带来的思考，如果把 method2 和 method3 的方法修改为 public 会不会代理线程安全问题？

情况1：有其它线程调用 method2 和 method3

不会，因为method2 和 method3传进来的参数list只能是线程自己的。

情况2：在情况1 的基础上，为 ThreadSafe 类添加子类，子类覆盖 method2 或 method3 方法，即

class ThreadSafe {
 	public final void method1(int loopNumber) {
 		ArrayList<String> list = new ArrayList<>();
 		for (int i = 0; i < loopNumber; i++) {
 			method2(list);
 			method3(list);
 		}
 	}
 private void method2(ArrayList<String> list) {
 	list.add("1");
 }
 private void method3(ArrayList<String> list) {
 	list.remove(0);
 	}
}
class ThreadSafeSubClass extends ThreadSafe{
 	@Override
 	public void method3(ArrayList<String> list) {
 	new Thread(() -> {
 		list.remove(0);
 	}).start();
 	}
}
被子类继承的话，那么子类可以另外开启一个线程进行相应操作，可能会出现线程安全问题。所以做好开闭原则中的闭。

从这个例子可以看出 private 或 final 提供【安全】的意义所在，请体会开闭原则中的【闭】加上private 或 final 不然子类继承

常见的线程安全类

String
Integer
StringBuffer
Random
Vector
Hashtable(线程安全的Map实现)
java.util.concurrent 包下的类

Hashtable table = new Hashtable();

new Thread(()->{
 	table.put("key", "value1");
}).start();

new Thread(()->{
 	table.put("key", "value2");
}).start();

打开Put源码
	public synchronized V put(K key, V value) {
        // Make sure the value is not null
        if (value == null) {
            throw new NullPointerException();
        }
可见synchronized

ctrl+N查找类。

ctrl+F12查找类中的方法。

它们的每个方法是原子的
但注意它们多个方法的组合不是原子的，

线程安全类方法的组合

分析下面代码是否线程安全？

Hashtable table = new Hashtable();
// 线程1，线程2
if( table.get("key") == null) {
 	table.put("key", value);
}

不可变类线程安全性

String、Integer 等都是不可变类，因为其内部的状态不可以改变，因此它们的方法都是线程安全的有同学或许有疑问，String 有 replace，substring 等方法【可以】改变值啊，那么这些方法又是如何保证线程安全的呢？

比如substring(),其实没有修改，而是创建了一个新的String对象

1
2
3

String s = "123";
s = "456";
编译可以通过，看上去好像改变了字符串的值，实际上是创建了新的对象，可以使用hashcode()得出结论。

不可变性的好处

String类的不可变性带来的好处总结主要有两点：

因为String类的不可变性，才能使得JVM可以实现字符串常量池；字符串常量池可以在程序运行时节约很多内存空间，因为不同的字符串变量指向相同的字面量时，都是指向字符串常量池中的同一个对象。这样一方面能够节约内存，另一方面也提升了性能。
因为String类的不可变性，从而保证了字符串对象在多线程环境下是线程安全的。如果String类是可变的，那么会引起很严重的安全问题。我们在很多情况下都是直接通过字符串传递数据，比如数据库的用户名密码、网络编程中的ip和端口，因为字符串是不可变的，所以它的值不能被修改，如果字符串是可变的，那么可以通过改变引用地址指向的值去修改字符串的值，从而导致安全漏洞。
同时也非常适合作为HashMap的key，因为HashMap的工作原理是hashcode，如果String作为key可变，那么hashcode会发送改变，那么就找不到之前存储的数据了。

Monitor概念

一个对象主要由两部分组成：Java对象头+成员变量

Java对象头

以32位虚拟机为例：

普通对象

一个类是什么对象靠的就是Klass Word(是一个指针)，通过Klass Word找到对象的类型。

数组对象

其中Mark Word结构为

其中先看Normal,hashcode懂得都懂，age是JVM中新生代到老年代晋升的那个年龄，biased_lock是偏向锁(后面学习)，01是加锁状态。

64位虚拟机

synchronized

synchronized 底层原理(Monitor)

Monitor 被翻译为监视器或管程

每个 Java 对象都可以关联一个 Monitor 对象，如果使用 synchronized 给对象上锁（重量级）之后，该对象头的 Mark Word 中就被设置指向 Monitor 对象的指针

刚开始 Monitor 中 Owner 为 null
当 Thread-2 执行 synchronized(obj) 就会将 Monitor 的所有者 Owner 置为 Thread-2，Monitor中只能有一个 Owner
在 Thread-2 上锁的过程中，如果 Thread-3，Thread-4，Thread-5 也来执行 synchronized(obj)，就会进入 EntryList BLOCKED
Thread-2 执行完同步代码块的内容，然后唤醒 EntryList 中等待的线程来竞争锁，竞争的时是非公平的
图中 WaitSet 中的 Thread-0，Thread-1 是之前获得过锁，但条件不满足进入 WAITING 状态的线程，后面讲 wait-notify 时会分析

synchronized 底层原理字节码分析

static final Object lock = new Object();
static int counter = 0;
public static void main(String[] args) {
 	synchronized (lock) {
 		counter++;
 	}
}

public static void main(java.lang.String[]);
 	descriptor: ([Ljava/lang/String;)V
 	flags: ACC_PUBLIC, ACC_STATIC
  	Code:
 		stack=2, locals=3, args_size=1
 			0: getstatic #2 // <- lock引用 （synchronized开始）
 			3: dup
 			4: astore_1 // lock引用 -> slot 1
 			5: monitorenter // 将 lock对象 MarkWord 置为 Monitor 指针
 			6: getstatic #3 // <- i
 			9: iconst_1 // 准备常数 1
 			10: iadd // +1
 			11: putstatic #3 // -> i
 			14: aload_1 // <- lock引用
 			15: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList
 			16: goto 24
 			19: astore_2 // e -> slot 2 
 			20: aload_1 // <- lock引用
 			21: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList
 			22: aload_2 // <- slot 2 (e)
 			23: athrow // throw e
 			24: return
 		Exception table:
 			from to target type
 			6    16 19     any
 			19   22 19     any
 		LineNumberTable:
 			line 8: 0
 			line 9: 6
 			line 10: 14
 			line 11: 24
 		LocalVariableTable:
 		Start Length Slot Name Signature
 		 0     25      0   args [Ljava/lang/String;
 		StackMapTable: number_of_entries = 2
 			frame_type = 255 /* full_frame */
 			offset_delta = 19
 			locals = [ class "[Ljava/lang/String;", class java/lang/Object ]
 			stack = [ class java/lang/Throwable ]
 			frame_type = 250 /* chop */
 			offset_delta = 4

总结

synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。

synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法。

不过两者的本质都是对对象监视器 monitor 的获取。(Monitor是由操作系统提供的)。

synchronized升级之小故事

故事角色

老王 - JVM
小南 - 线程
小女 - 线程
房间 - 对象
房间门上 - 防盗锁 - Monitor
房间门上 - 小南书包 - 轻量级锁
房间门上 - 刻上小南大名 - 偏向锁
批量重刻名 - 一个类的偏向锁撤销到达 20 阈值
不能刻名字 - 批量撤销该类对象的偏向锁，设置该类不可偏向

小南要使用房间保证计算不被其它人干扰（原子性），最初，他用的是防盗锁，当上下文切换时，锁住门。这样，即使他离开了，别人也进不了门，他的工作就是安全的。

但是，很多情况下没人跟他来竞争房间的使用权。小女是要用房间，但使用的时间上是错开的，小南白天用，小女晚上用。每次上锁太麻烦了，有没有更简单的办法呢？

小南和小女商量了一下，约定不锁门了，而是谁用房间，谁把自己的书包挂在门口，但他们的书包样式都一样，因此每次进门前得翻翻书包(查看对象头的线程ID)，看课本是谁的，如果是自己的，那么就可以进门，这样省的上锁解锁了。万一书包不是自己的，那么就在门外等，并通知对方下次用锁门的方式(因为有了竞争，所以升级为重量级锁)。

后来，小女回老家了，很长一段时间都不会用这个房间。小南每次还是挂书包，翻书包，虽然比锁门省事了，但仍然觉得麻烦。

于是，小南干脆在门上刻上了自己的名字：【小南专属房间，其它人勿用】，下次来用房间时，只要名字还在，那么说明没人打扰，还是可以安全地使用房间。如果这期间有其它人要用这个房间，那么由使用者将小南刻的名字擦掉，升级为挂书包的方式。

同学们都放假回老家了，小南就膨胀了，在 20 个房间刻上了自己的名字，想进哪个进哪个。后来他自己放假回老家了，这时小女回来了（她也要用这些房间），结果就是得一个个地擦掉小南刻的名字，升级为挂书包的方式。老王觉得这成本有点高，提出了一种批量重刻名的方法，他让小女不用挂书包了，可以直接在门上刻上自己的名字

后来，刻名的现象越来越频繁，老王受不了了：算了，这些房间都不能刻名了，只能挂书包

轻量级锁

轻量级锁的使用场景：如果一个对象虽然有多线程要加锁，但加锁的时间是错开的（也就是没有竞争），那么可以使用轻量级锁来优化。轻量级锁对使用者是透明的，即语法仍然是 synchronized

假设有两个方法同步块，利用同一个对象加锁

static final Object obj = new Object();

public static void method1() {
 	synchronized( obj ) {
 		// 同步块 A
 		method2();
 	}
}

public static void method2() {
 	synchronized( obj ) {
 		// 同步块 B
 	}
}

创建锁记录（Lock Record）对象，每个线程都的每个栈帧都会包含一个锁记录的结构，内部可以存储锁定对象的 Mark Word

让锁记录中 Object reference 指向锁对象，并尝试用 cas 替换 Object 的 Mark Word，将对象的 Mark Word 的值存入锁记录

如果 cas 替换成功，对象头中存储了锁记录地址和状态 00 ，表示由该线程给对象加锁，这时图示如下

如果 cas 失败，有两种情况
- 如果是其它线程已经持有了该 Object 的轻量级锁，这时表明有竞争，进入锁膨胀过程
- 如果是自己执行了 synchronized 锁重入，那么再添加一条 Lock Record 作为重入的计数

当退出 synchronized 代码块（解锁时）如果有取值为 null 的锁记录，表示有重入，这时重置锁记录，表示重入计数减一

当退出 synchronized 代码块（解锁时）锁记录的值不为 null，这时使用 cas 将 Mark Word 的值恢复给对象头
- 成功，则解锁成功
- 失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程

锁膨胀

如果在尝试加轻量级锁的过程中，CAS 操作无法成功，这时一种情况就是有其它线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁。

static Object obj = new Object();
public static void method1() {
 	synchronized( obj ) {
 		// 同步块
 	}
}

当 Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁

这时 Thread-1 加轻量级锁失败，进入锁膨胀流程
- 即为 Object 对象申请 Monitor 锁，让 Object 指向重量级锁地址
- 然后自己进入 Monitor 的 EntryList BLOCKED

当 Thread-0 退出同步块解锁时，使用 cas 将 Mark Word 的值恢复给对象头，失败。这时会进入重量级解锁流程，即按照 Monitor 地址找到 Monitor 对象，设置 Owner 为 null，唤醒 EntryList 中 BLOCKED 线程

自旋优化

重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。(阻塞会发生上下文切换，上下文切换影响性能)。

自旋重试成功的情况

自旋重试失败的情况

自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。
在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。
Java 7 之后不能控制是否开启自旋功能

偏向锁

轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS（Compare And Swap）操作。

Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有

例如：

static final Object obj = new Object();

public static void m1() {
 	synchronized( obj ) {
 		// 同步块 A
 		m2();
 	}
}
public static void m2() {
 	synchronized( obj ) {
 		// 同步块 B
 		m3();
 	}
}
public static void m3() {
 	synchronized( obj ) {
 		// 同步块 C
 	}
}

偏向状态

回忆一下对象头格式

分别是：无锁，偏向锁，轻量级锁，重量级锁，已被GC回收

一个对象创建时：

如果开启了偏向锁（默认开启），那么对象创建后，markword 值为 0x05 即最后 3 位为 101，这时它的 thread、epoch、age 都为 0。
偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加 VM 参数 - XX:BiasedLockingStartupDelay=0 来禁用延迟。(偏向锁的延迟性)
如果没有开启偏向锁，那么对象创建后，markword 值为 0x01 即最后 3 位为 001，这时它的 hashcode、 age 都为 0，第一次用到 hashcode 时才会赋值。

1）测试偏向锁的延迟特性

2）测试偏向锁

1	`class Dog {}`

利用 jol 第三方工具来查看对象头信息（注意这里我扩展了 jol 让它输出更为简洁）

// 添加虚拟机参数 -XX:BiasedLockingStartupDelay=0 
public static void main(String[] args) throws IOException {
 	Dog d = new Dog();
 	ClassLayout classLayout = ClassLayout.parseInstance(d);
 	
 	new Thread(() -> {
 		log.debug("synchronized 前");
 		System.out.println(classLayout.toPrintableSimple(true));
 		synchronized (d) {
 			log.debug("synchronized 中");
 			System.out.println(classLayout.toPrintableSimple(true));
 		}
 		log.debug("synchronized 后");
 		System.out.println(classLayout.toPrintableSimple(true));
 }, "t1").start();
}

输出：

11:08:58.117 c.TestBiased [t1] - synchronized 前
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000101 
11:08:58.121 c.TestBiased [t1] - synchronized 中
00000000 00000000 00000000 00000000 00011111 11101011 11010000 00000101 
11:08:58.121 c.TestBiased [t1] - synchronized 后
00000000 00000000 00000000 00000000 00011111 11101011 11010000 00000101

注意处于偏向锁的对象解锁后，线程 id 仍存储于对象头中

3）测试禁用

在上面测试代码运行时在添加 VM 参数 -XX:-UseBiasedLocking 禁用偏向锁

输出

11:13:10.018 c.TestBiased [t1] - synchronized 前
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
11:13:10.021 c.TestBiased [t1] - synchronized 中
00000000 00000000 00000000 00000000 00100000 00010100 11110011 10001000 
11:13:10.021 c.TestBiased [t1] - synchronized 后
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

测试 hashCode

正常状态对象一开始是没有 hashCode 的，第一次调用才生成,注意。调用Hashcode()方法会使偏向锁失效

调用Hashcode()后生成31位hashCode ，这时候没有空间再存储thread(操作系统方面的线程ID)，所以偏向锁失效，但是为什么轻量级锁和重量级锁不失效呢？

因为对象在使用轻量级锁时把hashcode存储在线程栈帧的Lock Record(所记录)中。

而对象在使用重量级锁时把hashcode存储在Monitor对象中，释放锁时再还原给对象头中。

撤销 - 调用对象 hashCode

调用了对象的 hashCode，但偏向锁的对象 MarkWord 中存储的是线程 id，如果调用 hashCode 会导致偏向锁被撤销

轻量级锁会在锁记录中记录 hashCode
重量级锁会在 Monitor 中记录 hashCode

在调用 hashCode 后使用偏向锁，记得去掉 -XX:-UseBiasedLocking

输出

11:22:10.386 c.TestBiased [main] - 调用 hashCode:1778535015 
11:22:10.391 c.TestBiased [t1] - synchronized 前
00000000 00000000 00000000 01101010 00000010 01001010 01100111 00000001 
11:22:10.393 c.TestBiased [t1] - synchronized 中
00000000 00000000 00000000 00000000 00100000 11000011 11110011 01101000 
11:22:10.393 c.TestBiased [t1] - synchronized 后
00000000 00000000 00000000 01101010 00000010 01001010 01100111 00000001

撤销 - 其它线程使用对象

当有其它线程使用偏向锁对象时，会将偏向锁升级为轻量级锁

private static void test2() throws InterruptedException {
 	Dog d = new Dog();
 	Thread t1 = new Thread(() -> {
 		synchronized (d) {
 			log.debug(ClassLayout.parseInstance(d).toPrintableSimple(true));
 		}
	 synchronized (TestBiased.class) {
 		TestBiased.class.notify();
 	}
 	// 如果不用 wait/notify 使用 join 必须打开下面的注释
 	// 因为：t1 线程不能结束，否则底层线程可能被 jvm 重用作为 t2 线程，底层线程 id 是一样的
 	/*try {
 		System.in.read();
 	} catch (IOException e) {
 		e.printStackTrace();
 	}*/
 }, "t1");
 t1.start();
 
	 Thread t2 = new Thread(() -> {
 		synchronized (TestBiased.class) {
 			try {
 				TestBiased.class.wait();
 			} catch (InterruptedException e) {
 				e.printStackTrace();
 			}
 		}
	    log.debug(ClassLayout.parseInstance(d).toPrintableSimple(true));
		 synchronized (d) {
 			log.debug(ClassLayout.parseInstance(d).toPrintableSimple(true));
 		}
 		log.debug(ClassLayout.parseInstance(d).toPrintableSimple(true));
 	}, "t2");
 	t2.start();
}

输出

[t1] - 00000000 00000000 00000000 00000000 00011111 01000001 00010000 00000101 
[t2] - 00000000 00000000 00000000 00000000 00011111 01000001 00010000 00000101 
[t2] - 00000000 00000000 00000000 00000000 00011111 10110101 11110000 01000000 
[t2] - 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

撤销 - 调用 wait/notify

public static void main(String[] args) throws InterruptedException {
 	Dog d = new Dog();
 	Thread t1 = new Thread(() -> {
 		log.debug(ClassLayout.parseInstance(d).toPrintableSimple(true));
 		synchronized (d) {
 			log.debug(ClassLayout.parseInstance(d).toPrintableSimple(true));
 			try {
 				d.wait();
 			} catch (InterruptedException e) {
 				e.printStackTrace();
 		}
 		log.debug(ClassLayout.parseInstance(d).toPrintableSimple(true));
 		}
 	}, "t1");
 	t1.start();
 	
 	new Thread(() -> {
 		try {
			 Thread.sleep(6000);
		 } catch (InterruptedException e) {
 			e.printStackTrace();
		 }
 		synchronized (d) {
 			log.debug("notify");
 			d.notify();
 		}
 	}, "t2").start();
}

[t1] - 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000101 
[t1] - 00000000 00000000 00000000 00000000 00011111 10110011 11111000 00000101 
[t2] - notify 
[t1] - 00000000 00000000 00000000 00000000 00011100 11010100 00001101 11001010

因为wait/notify只有在重量锁(两个线程存在竞争)的情况下才能使用。

wait/notify方法的调用必须处在该对象的锁（Monitor）中，也即，在调用这些方法时首先需要获得该对象的锁。否则会抛出IllegalMonitorStateException异常。

批量重偏向

如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程 T1 的对象仍有机会重新偏向 T2，重偏向会重置对象的 Thread ID

当撤销偏向锁阈值超过 20 次后，jvm 会这样觉得，我是不是偏向错了呢，于是会在给这些对象加锁时重新偏向至加锁线程,并且这些对象在synchronized同步代码块之外的状态依然处于偏向T2的状态，而在20次之前这些对象被撤销锁处于不可偏向状态(normal).

private static void test3() throws InterruptedException {
 	Vector<Dog> list = new Vector<>();
 	Thread t1 = new Thread(() -> {
 		for (int i = 0; i < 30; i++) {
 			Dog d = new Dog();
 			list.add(d);
 			synchronized (d) {
 				log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
 			}
 		}
 			synchronized (list) {
 				list.notify();
 			} 
 		}, "t1");
 		t1.start();
 
 	Thread t2 = new Thread(() -> {
 		synchronized (list) {
 			try {
 				list.wait();
 			} catch (InterruptedException e) {
 				e.printStackTrace();
 			}
 	}
 	log.debug("===============> ");
 	for (int i = 0; i < 30; i++) {
 		Dog d = list.get(i);
 		log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
 		synchronized (d) {
 			log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
 		}
	 log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
 		}
 	}, "t2");
 		t2.start();
}

[t1] - 0 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 1 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 2 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 3 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 4 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 5 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 6 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 7 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 8 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 9 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 10 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 11 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 12 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 13 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 14 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 15 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 16 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 17 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 18 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 19 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 20 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 21 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 22 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 23 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 24 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 25 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 26 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 27 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 28 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t1] - 29 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - ===============> 
[t2] - 0 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 0 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 1 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 1 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 1 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 2 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 2 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 2 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 3 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 3 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 3 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 4 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 4 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 4 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 5 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 5 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 5 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 6 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 6 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 6 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 7 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 7 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 7 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 8 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 8 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 8 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 9 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 9 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 9 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 10 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 10 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 10 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 11 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 11 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 11 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 12 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 12 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 12 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 13 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 13 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 13 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 14 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 14 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 14 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 15 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 15 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 15 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 16 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 16 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 16 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 17 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 17 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 17 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 18 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 18 00000000 00000000 00000000 00000000 00100000 01011000 11110111 00000000 
[t2] - 18 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
[t2] - 19 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 19 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 19 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 20 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 20 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 20 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 21 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 21 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 21 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 22 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 22 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 22 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 23 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 23 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 23 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 24 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 24 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 24 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 25 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 25 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 25 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 26 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 26 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 26 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 27 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 27 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 27 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 28 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 28 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 28 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 29 00000000 00000000 00000000 00000000 00011111 11110011 11100000 00000101 
[t2] - 29 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101 
[t2] - 29 00000000 00000000 00000000 00000000 00011111 11110011 11110001 00000101

批量撤销

当撤销偏向锁阈值超过 40 次后，jvm 会这样觉得，自己确实偏向错了，根本就不该偏向。于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的。

static Thread t1,t2,t3;
   private static void test4() throws InterruptedException {
		 Vector<Dog> list = new Vector<>();
 		 int loopNumber = 39;
 		t1 = new Thread(() -> {
 			for (int i = 0; i < loopNumber; i++) {
 			Dog d = new Dog();
 			list.add(d);
 			synchronized (d) {
 				log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
 			}
 		}
 			LockSupport.unpark(t2);
 		}, "t1");
 		t1.start();
 	  t2 = new Thread(() -> {
 		LockSupport.park();
 		log.debug("===============> ");
 		for (int i = 0; i < loopNumber; i++) {
 			Dog d = list.get(i);
 			log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
 			synchronized (d) {
 				log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
 			}
			 log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
 		}
 		LockSupport.unpark(t3);
 		}, "t2");

5. 锁消除
锁消除
 		t2.start();
	    t3 = new Thread(() -> {
 			LockSupport.park();
 			log.debug("===============> ");
 			for (int i = 0; i < loopNumber; i++) {
 				Dog d = list.get(i);
 				log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
 				synchronized (d) {
 				log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
 			}
 			log.debug(i + "\t" + ClassLayout.parseInstance(d).toPrintableSimple(true));
 		}
	 }, "t3");
 t3.start();
 t3.join();
 log.debug(ClassLayout.parseInstance(new Dog()).toPrintableSimple(true));
}

Wait notify原理

Owner 线程发现条件不满足，调用 wait 方法，即可进入 WaitSet 变为 WAITING 状态
BLOCKED 和 WAITING 的线程都处于阻塞状态，不占用 CPU 时间片
BLOCKED 线程会在 Owner 线程释放锁时唤醒
WAITING 线程会在 Owner 线程调用 notify 或 notifyAll 时唤醒，但唤醒后并不意味者立刻获得锁，仍需进入 EntryList 重新竞争

API

obj.wait() 让进入 object 监视器的线程到 waitSet 等待
obj.notify() 在 object 上正在 waitSet 等待的线程中挑一个唤醒
obj.notifyAll() 让 object 上正在 waitSet 等待的线程全部唤醒

它们都是线程之间进行协作的手段，都属于 Object 对象的方法。必须获得此对象的锁，才能调用这几个方法,比如

new Thread(() -> {
 synchronized (obj) {
 log.debug("执行....");
 try {
 obj.wait(); // 让线程在obj上一直等待下去
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 log.debug("其它代码....");
 }
 }).start();

sleep(long n) 和 wait(long n) 的区别

sleep 是 Thread 方法，而 wait 是 Object 的方法
sleep 不需要强制和 synchronized 配合使用，但 wait 需要和 synchronized 一起用
sleep 在睡眠的同时，不会释放对象锁的，但 wait 在等待的时候会释放对象锁
它们状态都是 TIMED_WAITING(共同点)

Park & Unpark

基本使用

调用park的线程处于wait状态

它们是 LockSupport 类中的方法

// 暂停当前线程
LockSupport.park(); 
// 恢复某个线程的运行
LockSupport.unpark(暂停线程对象)

先 park 再 unpark

Thread t1 = new Thread(() -> {
 log.debug("start...");
 sleep(1);
 log.debug("park...");
 LockSupport.park();
 log.debug("resume...");
},"t1");
t1.start();
sleep(2);
log.debug("unpark...");
LockSupport.unpark(t1);

输出

18:42:52.585 c.TestParkUnpark [t1] - start... 
18:42:53.589 c.TestParkUnpark [t1] - park... 
18:42:54.583 c.TestParkUnpark [main] - unpark... 
18:42:54.583 c.TestParkUnpark [t1] - resume...

先 unpark 再 park

Thread t1 = new Thread(() -> {
 log.debug("start...");
 sleep(2);
 log.debug("park...");
 LockSupport.park();
 log.debug("resume...");
}, "t1");
t1.start();
sleep(1);
log.debug("unpark...");
LockSupport.unpark(t1);

输出

18:43:50.765 c.TestParkUnpark [t1] - start... 
18:43:51.764 c.TestParkUnpark [main] - unpark... 
18:43:52.769 c.TestParkUnpark [t1] - park... 
18:43:52.769 c.TestParkUnpark [t1] - resume...

可以看到不管unpark在park之前还是之后都可以成功唤醒park所在线程

特点

与 Object 的 wait & notify 相比

wait，notify 和 notifyAll 必须配合 Object Monitor 一起使用，而 park，unpark 不必
park & unpark 是以线程为单位来【阻塞】和【唤醒】线程，而 notify 只能随机唤醒一个等待线程，notifyAll 是唤醒所有等待线程，就不那么【精确】
park & unpark 可以先 unpark，而 wait & notify 不能先 notify

线程状态转换

(待详细分析)

ReentrantLock

相对于 synchronized 它具备如下特点

可打断(synchonized不可打断)，减少死锁发生的可能性
可以设置超时时间
可以设置为公平锁
支持多个条件变量

与 synchronized 一样，都支持可重入

// 获取锁
reentrantLock.lock();
try {
 // 临界区
} finally {
 // 释放锁
 reentrantLock.unlock();
}

可重入

可重入是指同一个线程如果首次获得了这把锁，那么因为它是这把锁的拥有者，因此有权利再次获取这把锁如果是不可重入锁，那么第二次获得锁时，自己也会被锁挡住

@Slf4j
public class ReentrantLockTest {
    public static ReentrantLock lock = new ReentrantLock();
    public static void main(String[] args) {
        lock.lock();
        try {
            log.debug("entry main");
            m1();
        }finally {
            lock.unlock();
        }
    }

    public static void m1(){
        lock.lock();
        try {
            log.debug("entry m1");
            m2();
        }finally {
            lock.unlock();
        }
    }
    public static void m2(){
        lock.lock();
        try {
            log.debug("entry m2");
        }finally {
            lock.unlock();
        }
    }
}

输出

1
2
3

16:01:24.390 [main] DEBUG lock.ReentrantLockTest - entry main
16:01:24.392 [main] DEBUG lock.ReentrantLockTest - entry m1
16:01:24.392 [main] DEBUG lock.ReentrantLockTest - entry m2

可打断

ReentrantLock lock = new ReentrantLock();
        Thread t1 = new Thread(()->{
            log.debug("启动...");
            try {
                //如果没有竞争那么将获得lock对象锁
                //如果有竞争就进入阻塞队列,可以被其他线程用interrupt()打断
                //主线程已经获取锁了，t1线程阻塞并在阻塞队列等待，主线程执行t1.interrupt()将t1等待打断
                lock.lockInterruptibly();
            } catch (InterruptedException e) {
                e.printStackTrace();
                log.debug("等锁的过程中被打断");
                return;
            }
            try {
                log.debug("获得了锁");
            } finally {
                lock.unlock();
            }
        },"t1");
        lock.lock();
        log.debug("获得了锁");
        t1.start();
        try {
            Thread.sleep(1000);
            t1.interrupt();
            log.debug("执行打断");
        } finally {
            lock.unlock();
        }

6:47:34.169 [main] DEBUG lock.ReentrantLockTest2 - 获得了锁
16:47:34.172 [Thread-0] DEBUG lock.ReentrantLockTest2 - 启动...
16:47:35.183 [main] DEBUG lock.ReentrantLockTest2 - 执行打断
16:47:35.183 [Thread-0] DEBUG lock.ReentrantLockTest2 - 等锁的过程中被打断
java.lang.InterruptedException
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:898)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222)
	at java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:335)
	at lock.ReentrantLockTest2.lambda$main$0(ReentrantLockTest2.java:20)
	at java.lang.Thread.run(Thread.java:750)

注意如果是不可中断模式，那么即使使用了 interrupt 也不会让等待中断

@Slf4j
public class ReentrantLockTest2 {
    public static void main(String[] args) throws InterruptedException {
        ReentrantLock lock = new ReentrantLock();
        Thread t1 = new Thread(() -> {
            log.debug("启动...");
            lock.lock();
            try {
                log.debug("获得了锁");
            } finally {
                lock.unlock();
            }
        }, "t1");
        lock.lock();
        log.debug("获得了锁");
        t1.start();
        try {
            sleep(1);
            t1.interrupt();
            log.debug("执行打断");
            sleep(1);
        } finally {
            log.debug("释放了锁");
            lock.unlock();
        }
    }
}

18:06:56.261 [main] c.TestInterrupt - 获得了锁
18:06:56.265 [t1] c.TestInterrupt - 启动... 
18:06:57.266 [main] c.TestInterrupt - 执行打断 // 这时 t1 并没有被真正打断, 而是仍继续等待锁
18:06:58.267 [main] c.TestInterrupt - 释放了锁
18:06:58.267 [t1] c.TestInterrupt - 获得了锁

这是一种被动打断，也就是被别的线程打断，所以接下来介绍主动打断->锁超时。

锁超时

立刻失败

ReentrantLock lock = new ReentrantLock();
Thread t1 = new Thread(() -> {
    log.debug("启动...");
    if (!lock.tryLock()) {
        log.debug("获取立刻失败，返回");
        return;
    }
    try {
        log.debug("获得了锁");
    } finally {
        lock.unlock();
    }
}, "t1");
//主线程获得到lock锁
lock.lock();
log.debug("获得了锁");
t1.start();
try {
    sleep(2);
} finally {
    lock.unlock();
}

1
2
3

17:05:08.957 [main] DEBUG reentrantlockTest.ReentrantLockTest3 - 获得了锁
17:05:08.960 [t1] DEBUG reentrantlockTest.ReentrantLockTest3 - 启动...
17:05:08.960 [t1] DEBUG reentrantlockTest.ReentrantLockTest3 - 获取立刻失败，返回

超时失败

ReentrantLock lock = new ReentrantLock();
Thread t1 = new Thread(() -> {
    log.debug("启动...");
    try {
        if (!lock.tryLock(1, TimeUnit.SECONDS)) {
            log.debug("获取等待 1s 后失败，返回");
            return;
        }
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    try {
        log.debug("获得了锁");
    } finally {
        lock.unlock();
    }
}, "t1");
lock.lock();
log.debug("获得了锁");
t1.start();
try {
    sleep(2);
} finally {
    lock.unlock();
}

1
2
3

17:07:37.062 [main] DEBUG reentrantlockTest.ReentrantLockTest3 - 获得了锁
17:07:37.064 [t1] DEBUG reentrantlockTest.ReentrantLockTest3 - 启动...
17:07:38.075 [t1] DEBUG reentrantlockTest.ReentrantLockTest3 - 获取等待 1s 后失败，返回

公平锁

ReentrantLock 默认是不公平的，什么是公平和不公平？在获取不到锁对象时，线程会进入阻塞队列，当执行线程完毕后，阻塞队列里的线程会一窝蜂来争抢锁对象，谁抢到就是谁的，而不是按进入队列的顺序先来后到。

条件变量

synchronized 中也有条件变量，就是我们讲原理时那个 waitSet 休息室，当条件不满足时进入 waitSet 等待。

ReentrantLock 的条件变量比 synchronized 强大之处在于，它是支持多个条件变量的，这就好比

synchronized 是那些不满足条件的线程都在一间休息室等消息
await 执行后，会释放锁，进入 conditionObject 等待
await 的线程被唤醒（或打断、或超时）取重新竞争 lock 锁
竞争 lock 锁成功后，从 await 后继续执行

例子：

static ReentrantLock lock = new ReentrantLock();
static Condition waitCigaretteQueue = lock.newCondition();
static Condition waitbreakfastQueue = lock.newCondition();
static volatile boolean hasCigrette = false;
static volatile boolean hasBreakfast = false;

public static void main(String[] args) throws InterruptedException {
    new Thread(() -> {
        try {
            lock.lock();
            while (!hasCigrette) {
                try {
                    log.debug("没烟抽，先等一会");
                    waitCigaretteQueue.await();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            log.debug("等到了它的烟");
        } finally {
            lock.unlock();
        }
    }).start();

    new Thread(() -> {
        try {
            lock.lock();
            while (!hasBreakfast) {
                try {
                    log.debug("没饭吃，先等一会");
                    waitbreakfastQueue.await();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            log.debug("等到了它的早餐");
        } finally {
            lock.unlock();
        }
    }).start();

    sleep(1000);
    sendBreakfast();
    sleep(1000);
    sendCigarette();
}
private static void sendCigarette() {
    //先获取锁才能使用
    lock.lock();
    try {
        log.debug("送烟来了");
        hasCigrette = true;
        waitCigaretteQueue.signal();
    } finally {
        lock.unlock();
    }
}

private static void sendBreakfast() {
    lock.lock();
    try {
        log.debug("送早餐来了");
        hasBreakfast = true;
        waitbreakfastQueue.signal();
    } finally {
        lock.unlock();
    }

19:12:46.838 [Thread-0] DEBUG reentrantlockTest.ReentrantLockTest4 - 没烟抽，先等一会
19:12:46.840 [Thread-1] DEBUG reentrantlockTest.ReentrantLockTest4 - 没饭吃，先等一会
19:12:47.838 [main] DEBUG reentrantlockTest.ReentrantLockTest4 - 送早餐来了
19:12:47.838 [Thread-1] DEBUG reentrantlockTest.ReentrantLockTest4 - 等到了它的早餐
19:12:48.852 [main] DEBUG reentrantlockTest.ReentrantLockTest4 - 送烟来了
19:12:48.852 [Thread-0] DEBUG reentrantlockTest.ReentrantLockTest4 - 等到了它的烟

同步模式之顺序控制

固定运行顺序打印

wait notify 版

static final Object lock = new Object();
static volatile boolean  t2runed = false;

Thread t1 = new Thread(() -> {
            synchronized (lock){
                while(t2runed){
                    try {
                        lock.wait();

                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }

                System.out.println("1");
            }
        }, "t1");

        Thread t2 = new Thread(() -> {
            System.out.println("2");
            synchronized (lock){
                t2runed = true;
                lock.notify();
            }
        }, "t2");

        t1.start();
        t2.start();

1
2

2
1

Park Unpark 版

可以看到，实现上很麻烦：

首先，需要保证先 wait 再 notify，否则 wait 线程永远得不到唤醒。因此使用了『运行标记』来判断该不该 wait，比如先notify再wait就出问题了。
第二，如果有些干扰线程错误地 notify 了 wait 线程，条件不满足时还要重新等待，使用了 while 循环来解决此问题
最后，唤醒对象上的 wait 线程需要使用 notifyAll，因为『同步对象』上的等待线程可能不止一个

可以使用 LockSupport 类的 park 和 unpark 来简化上面的题目：

Thread t1 = new Thread(() -> {
 try { Thread.sleep(1000); } catch (InterruptedException e) { }
 // 当没有『许可』时，当前线程暂停运行；有『许可』时，用掉这个『许可』，当前线程恢复运行
 LockSupport.park();
 System.out.println("1");
});
Thread t2 = new Thread(() -> {
 System.out.println("2");
 // 给线程 t1 发放『许可』（多次连续调用 unpark 只会发放一个『许可』）
 LockSupport.unpark(t1);
});
t1.start();
t2.start();

park 和 unpark 方法比较灵活，他俩谁先调用，谁后调用无所谓。并且是以线程为单位进行『暂停』和『恢复』，不需要『同步对象』和『运行标记』

交替输出

线程 1 输出 a 5 次，线程 2 输出 b 5 次，线程 3 输出 c 5 次。现在要求输出 abcabcabcabcabc 怎么实现

wait notify 版

public class OutPutTest3 {
    public static void main(String[] args) {
        SyncWaitNotify syncWaitNotify = new SyncWaitNotify(1, 5);

        new Thread(() -> {
            syncWaitNotify.print(1, 2, "a");
        }).start();
        new Thread(() -> {
            syncWaitNotify.print(2, 3, "b");
        }).start();
        new Thread(() -> {
            syncWaitNotify.print(3, 1, "c");
        }).start();
    }
}
class SyncWaitNotify {
    private int flag;
    private int loopNumber;

    public SyncWaitNotify(int flag, int loopNumber) {
        this.flag = flag;
        this.loopNumber = loopNumber;
    }

    public void print(int waitFlag, int nextFlag, String str) {
        for (int i = 0; i < loopNumber; i++) {
            synchronized (this){
                while(flag != waitFlag){
                    try {
                        this.wait();
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
                System.out.println(str);
                flag = nextFlag;
                this.notifyAll();
            }
        }
    }
}

ReentrantLock版

package output;

import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;

/**
 * @description: TODO(一句话描述该做什么)
 * @Author : 
 */
public class OutPutTest4 {
    public static void main(String[] args) throws InterruptedException {
        AwaitSignal awaitSignal = new AwaitSignal(5);
        Condition a = awaitSignal.newCondition();
        Condition b = awaitSignal.newCondition();
        Condition c = awaitSignal.newCondition();

        new Thread(()->{
            awaitSignal.print("a",a,b);
        },"t1").start();
        new Thread(()->{
            awaitSignal.print("b",b,c);
        },"t1").start();

        new Thread(()->{
            awaitSignal.print("c",c,a);
        },"t1").start();

        Thread.sleep(100);
        awaitSignal.lock();
        try {
            a.signal();
        }finally {
            awaitSignal.unlock();
        }
    }
}
class AwaitSignal extends ReentrantLock{
    private int loopNumber;

    public AwaitSignal(int loopNumber) {
        this.loopNumber = loopNumber;
    }

    public void print( String str,Condition cur,Condition next){

        for (int i = 0; i < loopNumber; i++) {
            lock();
            try {
                cur.await();
                System.out.println(str);
                next.signal();
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                unlock();
            }
        }
    }
}

park/unpark

package output;

import org.slf4j.Logger;

import java.util.concurrent.locks.LockSupport;

/**
 * @description: TODO(一句话描述该做什么)
 * @Author : 彭建飞
 */
public class OutPutTest5 {
    static Thread a;
    static Thread b;
    static Thread c;
    public static void main(String[] args) throws InterruptedException {
        SyncPark syncPark = new SyncPark(5);
        a = new Thread(()->{
            syncPark.print("a",b);
        });

        b = new Thread(()->{
            syncPark.print("b",c);
        });

        c = new Thread(()->{
            syncPark.print("c",a);
        });
        a.start();
        b.start();
        c.start();
        Thread.sleep(100);
        LockSupport.unpark(a);
    }
}
class SyncPark{
    private int loopNumber;

    public SyncPark(int loopNumber) {
        this.loopNumber = loopNumber;
    }

    public void print(String str , Thread next){
        for (int i = 0; i < loopNumber; i++) {
            LockSupport.park();
            System.out.println(str);
            LockSupport.unpark(next);
        }
    }
}

JMM

先聊几个问题

先来看操作系统中的一个架构

因为有那么多级的缓存(CPU和物理主内存的速度不一致的)，CPU的运行并不是直接操作内存而是先把内存里边的数据读取到缓存，而内存的读和写操作就会造成不一致的问题

JVM规范中试图定义一种Java内存模型(Java Memory Model,简称JMM)来屏蔽掉各种硬件和操作系统的内存访问差异以实现让Java程序在各种平台下都能达到一致的内存访问效果

概念

JMM(Java内存模型Java Memory Model，简称JMM)本身是一种抽象的概念并不真实存在它仅仅描述的是一组约定或规范，通过这组规范定义了程序中(尤其是多线程)各个变量的读写访问方式并决定一个线程对共享变量的写入何时以及如何变成对另一个线程可见，关键技术点都是围绕多线程的原子性、可见性和有序性展开的。

原则

JMM的关键技术点都是围绕多线程的原子性、可见性和有序性展开的

能干吗？

通过JMM来实现线程和主内存之间的抽象关系。
屏蔽各个硬件平台和操作系统的内存访问差异以实现让Java程序在各种平台下都能达到一致的内存访问效果。

JMM规范下的三大特性

可见性：是指当一个线程修改了某一个共享变量的值，其他线程是否能够立即知道该变更，JMM规定了所有的变量都存储在主内存中

系统主内存共享变量数据修改被写入的时机是不确定的，多线程并发下很可能出现”脏读”，所以每个线程都有自己的工作内存、线程自己的工作内存中保存了该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作（读取，赋值等）都必需在线程自己的工作内存中进行，而不能够直接读写主内存中的变量。不同线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成

线程脏读

原子性：指一个操作是不可打断的，即多线程环境下，操作是不能被其他线程干扰的

有序性：

JVM 会在不影响正确性的前提下，可以调整语句的执行顺序，思考下面一段代码

static int i;
static int j;
// 在某个线程内执行如下赋值操作
i = ...; 
j = ...;

可以看到，至于是先执行 i 还是先执行 j ，对最终的结果不会产生影响。所以，上面代码真正执行时，既可以是

1 2	`i = ...; j = ...;`

也可以是

1 2	`j = ...; i = ...;`

这种特性称之为『指令重排』，多线程下『指令重排』会影响正确性。为什么要有重排指令这项优化呢？从 CPU 执行指令的原理来理解一下吧

鱼罐头的故事

加工一条鱼需要 50 分钟，只能一条鱼、一条鱼顺序加工…

可以将每个鱼罐头的加工流程细分为 5 个步骤：

去鳞清洗 10分钟
蒸煮沥水 10分钟
加注汤料 10分钟
杀菌出锅 10分钟
真空封罐 10分钟

即使只有一个工人，最理想的情况是：他能够在 10 分钟内同时做好这 5 件事，因为对第一条鱼的真空装罐，不会影响对第二条鱼的杀菌出锅…

指令重排序

对于一个线程的执行代码而言，我们总是习惯性认为代码的执行总是从上到下，有序执行。但为了提升性能，编译器和处理器通常会对指令序列进行重新排序。Java规范规定JVM线程内部维持顺序化语义，即只要程序的最终结果与它顺序化执行的结果相等，那么指令的执行顺序可以与代码顺序不一致,此过程叫指令的重排序。

指令重排序优缺点：

JVM能根据处理器特性:(CPU多级缓存系统、多核处理器等）适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器性能。但是，

指令重排可以保证串行语义一致，但没有义务保证多线程间的语义也一致(即可能产生”脏读”)，简单说.

两行以上不相干的代码在执行的时候有可能先执行的不是第一条，不见得是从上到下顺序执行，执行顺序会被优化。

从源码到最终执行示例图：

单线程环境里面确保程序最终执行结果和代码顺序执行的结果一致。处理器在进行重排序时必须要考虑指令之间的数据依赖性。

多线程环境中线程交替执行,由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性是无法确定的,结果无法预测。

指令重排序优化

事实上，现代处理器会设计为一个时钟周期完成一条执行时间最长的 CPU 指令。为什么这么做呢？可以想到指令还可以再划分成一个个更小的阶段，例如，每条指令都可以分为：取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回这 5 个阶段

在不改变程序结果的前提下，这些指令的各个阶段可以通过重排序和组合来实现指令级并行，这一技术在 80’s 中叶到 90’s 中叶占据了计算架构的重要地位。

提示：分阶段，分工是提升效率的关键！

指令重排的前提是，重排指令不能影响结果，例如

// 可以重排的例子
int a = 10; // 指令1
int b = 20; // 指令2
System.out.println( a + b );
// 不能重排的例子
int a = 10; // 指令1
int b = a - 5; // 指令2

现代 CPU 支持多级指令流水线，例如支持同时执行取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回的处理器，就可以称之为五级指令流水线。这时 CPU 可以在一个时钟周期内，同时运行五条指令的不同阶段（相当于一条执行时间最长的复杂指令），IPC = 1，本质上，流水线技术并不能缩短单条指令的执行时间，但它变相地提高了指令地吞吐率。

诡异的结果

int num = 0;
boolean ready = false;
// 线程1 执行此方法
public void actor1(I_Result r) {
 if(ready) {
     r.r1 = num + num;
 } else {
     r.r1 = 1;
 }
}
// 线程2 执行此方法
public void actor2(I_Result r) { 
 num = 2;
 ready = true; 
}

I_Result 是一个对象，有一个属性 r1 用来保存结果，问，可能的结果有几种？

情况1：线程1 先执行，这时 ready = false，所以进入 else 分支结果为 1
情况2：线程2 先执行 num = 2，但没来得及执行 ready = true，线程1 执行，还是进入 else 分支，结果为1
情况3：线程2 执行到 ready = true，线程1 执行，这回进入 if 分支，结果为 4（因为 num 已经执行过了）

但我告诉你，结果还有可能是 0 😁😁😁，信不信吧！这种情况下是：线程2 执行 ready = true，切换到线程1，进入 if 分支，相加为 0，再切回线程2 执行 num = 2 相信很多人已经晕了 😵😵😵

这种现象叫做指令重排，是 JIT 编译器在运行时的一些优化，这个现象需要通过大量测试才能复现

那么怎么解决呢？

这里采取的是 volatile boolean ready = false;

在ready前加上volatile，意思是在ready之前的都不能重排列到ready之后去

内存屏障

内存屏障 Memory Barrier（Memory Fence）

可见性
- 写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中
- 而读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据
有序性
- 写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
- 读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

volatile原理

volatile 的底层实现原理是内存屏障，Memory Barrier（Memory Fence）

对 volatile 变量的写指令后会加入写屏障
对 volatile 变量的读指令前会加入读屏障

如何保证可见性

写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中

public void actor2(I_Result r) {
     num = 2;
     ready = true; // ready 是 volatile 赋值带写屏障
     // 加写屏障
}

而读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据

public void actor1(I_Result r) {
     // 读屏障
     // ready 是 volatile 读取值带读屏障
     if(ready) {
        r.r1 = num + num;
     } else {
        r.r1 = 1;
     }
}

如何保证有序性

写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后

public void actor2(I_Result r) {
    num = 2;
    ready = true; // ready 是 volatile 赋值带写屏障
    // 加写屏障
}

读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

public void actor1(I_Result r) {
    //加读屏障
    // ready 是 volatile 读取值带读屏障
    if(ready) {
       r.r1 = num + num;
    } else {
       r.r1 = 1;
    }
}

还是那句话，不能解决指令交错：

写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证读跑到它前面去
而有序性的保证也只是保证了本线程内相关代码不被重排序

volatile只能保证线程的可见性和有序性，不能保证原子性，如上图，而synchronized三者都可保证

单例模式double-checked locking 问题

以著名的 double-checked locking 单例模式为例

public final class Singleton {
    private Singleton() { }
    private static Singleton INSTANCE = null;
    public static Singleton getInstance() { 
        if(INSTANCE == null) { // t2
        // 首次访问会同步，而之后的使用没有 synchronized
            synchronized(Singleton.class) {
               if (INSTANCE == null) { // t1
                 INSTANCE = new Singleton();
               } 
             }
          }
          return INSTANCE;
     }
}

以上的实现特点是：

懒惰实例化
首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁
有隐含的，但很关键的一点：第一个 if 使用了 INSTANCE 变量，是在同步块之外

但在多线程环境下，上面的代码是有问题的，getInstance 方法对应的字节码为：

0: getstatic #2        // Field INSTANCE:Lcn/itcast/n5/Singleton;
3: ifnonnull 37
6: ldc #3              // class cn/itcast/n5/Singleton
8: dup
9: astore_0
10: monitorenter
11: getstatic #2       // Field INSTANCE:Lcn/itcast/n5/Singleton;
14: ifnonnull 27
17: new #3             // class cn/itcast/n5/Singleton
20: dup
21: invokespecial #4   // Method "<init>":()V
24: putstatic #2       // Field INSTANCE:Lcn/itcast/n5/Singleton;
27: aload_0
28: monitorexit
29: goto 37
32: astore_1
33: aload_0
34: monitorexit
35: aload_1
36: athrow
37: getstatic #2       // Field INSTANCE:Lcn/itcast/n5/Singleton;
40: areturn

其中

17 表示创建对象，将对象引用入栈 // new Singleton
20 表示复制一份对象引用 // 引用地址
21 表示利用一个对象引用，调用构造方法
24 表示利用一个对象引用，赋值给 static INSTANCE

也许 jvm 会优化为：先执行 24，再执行 21。如果两个线程 t1，t2 按如下时间序列执行：

关键在于 0: getstatic 这行代码在 monitor 控制之外，它就像之前举例中不守规则的人，可以越过 monitor 读取 INSTANCE 变量的值这时 t1 还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例 对 INSTANCE 使用 volatile 修饰即可，可以禁用指令重排，但要注意在 JDK 5 以上的版本的 volatile 才会真正有效

double-checked locking 解决

public final class Singleton {
    private Singleton() { }
    private static volatile Singleton INSTANCE = null;
    public static Singleton getInstance() {
        // 实例没创建，才会进入内部的 synchronized代码块
        if (INSTANCE == null) { 
           synchronized (Singleton.class) { // t2
              // 也许有其它线程已经创建实例，所以再判断一次
              if (INSTANCE == null) { // t1
                 INSTANCE = new Singleton();
              }
           }
        }
        return INSTANCE;
     }
}

字节码上看不出来 volatile 指令的效果

// -------------------------------------> 加入对 INSTANCE 变量的读屏障
0: getstatic #2     // Field INSTANCE:Lcn/itcast/n5/Singleton;
3: ifnonnull 37
6: ldc #3       // class cn/itcast/n5/Singleton
8: dup
9: astore_0
10: monitorenter -----------------------> 保证原子性、可见性
11: getstatic #2     // Field INSTANCE:Lcn/itcast/n5/Singleton;
14: ifnonnull 27
17: new #3     // class cn/itcast/n5/Singleton
20: dup
21: invokespecial #4     // Method "<init>":()V
24: putstatic #2     // Field INSTANCE:Lcn/itcast/n5/Singleton;
// -------------------------------------> 加入对 INSTANCE 变量的写屏障
27: aload_0
28: monitorexit ------------------------> 保证原子性、可见性
29: goto 37
32: astore_1
33: aload_0
34: monitorexit
35: aload_1
36: athrow
37: getstatic #2   // Field INSTANCE:Lcn/itcast/n5/Singleton;
40: areturn

如上面的注释内容所示，读写 volatile 变量时会加入内存屏障（Memory Barrier（Memory Fence）），保证下面两点：

可见性
- 写屏障（sfence）保证在该屏障之前的 t1 对共享变量的改动，都同步到主存当中
- 而读屏障（lfence）保证在该屏障之后 t2 对共享变量的读取，加载的是主存中最新数据
有序性
- 写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
- 读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前
更底层是读写变量时使用 lock 指令来多核 CPU 之间的可见性与有序性

读取过程

由于JVM运行程序的实体是线醒，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间)，工作内存是每个线程的私有数据区域，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝到的线程自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，各个线程中的工作内存中存储着主内存中的变量副本拷贝，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成，其简要访问过程如下图:

Happens-before(先行发生)原则

在JMM中，如果一个操作执行的结果需要对另一个操作可见性或者代码重排序，那么这两个操作之间必须存在Happens-before原则。

逻辑上的先后关系。

如果Java内存模型中所有的有序性都仅靠volatile和synchronized来完成，那么有很多操作都将会变得非常啰嗦，但是我们在编写Java并发代码的时候并没有察觉到这一点。

我们没有时时、处处、次次，添加volatile和synchronized来完成程序，这是因为Java语言中JMM原则下有一个“先行发生”(Happens-Before)的原则限制和规矩，给你立好了规矩!

这个原则非常重要:

它是判断数据是否存在竞争，线程是否安全的非常有用的手段。依赖这个原则，我们可以通过几条简单规则一揽子解决并发环境下两个操作之间是否可能存在冲突的所有问题，而不需要陷入Java内存模型苦涩难懂的底层编译原理之中

总原则

如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。
两个操作之间存在happens-before关系，并不意味着一定要按照happens-before原则制定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果一致，那么这种重排序并不非法

AQS

全称是 AbstractQueuedSynchronizer(抽象队列同步器)，是阻塞式锁和相关的同步器工具的框架

特点：

用 state 属性来表示资源的状态（分独占模式和共享模式），子类需要定义如何维护这个状态，控制如何获取锁和释放锁
- getState - 获取 state 状态
- setState - 设置 state 状态
- compareAndSetState - cas 机制设置 state 状态
- 独占模式是只有一个线程能够访问资源，而共享模式可以允许多个线程访问资源
提供了基于 FIFO 的等待队列，类似于 Monitor 的 EntryList
条件变量来实现等待、唤醒机制，支持多个条件变量，类似于 Monitor 的 WaitSet

子类主要实现这样一些方法（默认抛出 UnsupportedOperationException）

tryAcquire
tryRelease
tryAcquireShared
tryReleaseShared
isHeldExclusively

实现不可重入锁

创建同步器类

//同步器类
public class MySyn extends AbstractQueuedSynchronizer {
    @Override
    protected boolean tryAcquire(int arg) {
       if( compareAndSetState(0,1)){
           setExclusiveOwnerThread(Thread.currentThread());
           return true;
       }
       return false;
    }

    @Override
    protected boolean tryRelease(int arg) {
        setExclusiveOwnerThread(null);
        setState(0);
        return true;
    }

    @Override
    protected boolean isHeldExclusively() {
        return getState() == 1 ;
    }

    protected Condition newCondition(){
        return new ConditionObject();
    }
}

创建锁类

public class MyLock implements Lock {
    MySyn syn = new MySyn();
    @Override
    public void lock() {
        syn.acquire(1);
    }

    @Override
    public void lockInterruptibly() throws InterruptedException {
        syn.acquireInterruptibly(1);
    }

    @Override
    public boolean tryLock() {
        return syn.tryAcquire(1);
    }

    @Override
    public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {
        return syn.tryAcquireNanos(1, unit.toNanos(time));
    }

    @Override
    public void unlock() {
        syn.release(1);
    }

    @Override
    public Condition newCondition() {
        return syn.newCondition();
    }
}

测试

public static void main(String[] args) {
        MyLock lock = new MyLock();
        new Thread(() -> {
            lock.lock();
            try {
                log.debug("locking...");
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                log.debug("unlocking...");
                lock.unlock();
            }
        },"t1").start();
        new Thread(() -> {
            lock.lock();
            try {
                log.debug("locking...");
            } finally {
                log.debug("unlocking...");
                lock.unlock();
            }
        },"t2").start();
    }

20:24:43.861 [t1] DEBUG AQSTest.AQStest - locking...
20:24:44.875 [t1] DEBUG AQSTest.AQStest - unlocking...
20:24:44.875 [t2] DEBUG AQSTest.AQStest - locking...
20:24:44.875 [t2] DEBUG AQSTest.AQStest - unlocking...

ReentrantLock

非公平锁实现原理

加锁解锁流程

先从构造器开始看，默认为非公平锁实现

1
2
3

public ReentrantLock() {
   sync = new NonfairSync();
}

NonfairSync 继承自 AQS

没有竞争时

第一个竞争出现时

Thread-1 执行了

CAS 尝试将 state 由 0 改为 1，结果失败

进入 tryAcquire 逻辑，这时 state 已经是1，结果仍然失败

接下来进入 addWaiter 逻辑，构造 Node 队列
- 图中黄色三角表示该 Node 的 waitStatus 状态，其中 0 为默认正常状态
- Node 的创建是懒惰的
- 其中第一个 Node 称为 Dummy（哑元）或哨兵，用来占位，并不关联线程

当前线程进入 acquireQueued 逻辑

acquireQueued 会在一个死循环中不断尝试获得锁，失败后进入 park 阻塞
如果自己是紧邻着 head（排第二位），那么再次 tryAcquire 尝试获取锁，当然这时 state 仍为 1，失败
进入 shouldParkAfterFailedAcquire 逻辑，将前驱 node，即 head(Node(null)) 的 waitStatus 改为 -1，这次返回 false

shouldParkAfterFailedAcquire 执行完毕回到 acquireQueued ，再次 tryAcquire 尝试获取锁，当然这时 state 仍为 1，失败
当再次进入 shouldParkAfterFailedAcquire 时，这时因为其前驱 node 的 waitStatus 已经是 -1，这次返回 true
进入 parkAndCheckInterrupt， Thread-1 park（灰色表示）

再次有多个线程经历上述过程竞争失败，变成这个样子

Juc

http://example.com/2023/02/22/Juc/

Author

彭

Posted on

February 22, 2023

Licensed under

SpringMvc Previous

Jvm Next