JUC_1

进程

概述

进程：程序是静止的，进程实体的运行过程就是进程，是系统进行资源分配的基本单位 进程的特征：并发性、异步性、动态性、独立性、结构性线程：线程是属于进程的，是一个基本的 CPU 执行单元，是程序执行流的最小单元。线程是进程中的一个实体，是系统独立调度的基本单位，线程本身不拥有系统资源，只拥有一点在运行中必不可少的资源，与同属一个进程的其他线程共享进程所拥有的全部资源关系：一个进程可以包含多个线程，这就是多线程，比如看视频是进程，图画、声音、广告等就是多个线程线程的作用：使多道程序更好的并发执行，提高资源利用率和系统吞吐量，增强操作系统的并发性能并发并行：

并行：在同一时刻，有多个指令在多个 CPU 上同时执行
并发：在同一时刻，有多个指令在单个 CPU 上交替执行同步异步：
需要等待结果返回，才能继续运行就是同步
不需要等待结果返回，就能继续运行就是异步参考视频：黑马程序员深入学习Java并发编程，JUC并发编程全套教程_哔哩哔哩_bilibili 笔记的整体结构依据视频编写，并随着学习的深入补充了很多知识

对比

线程进程对比：

进程基本上相互独立的，而线程存在于进程内，是进程的一个子集
进程拥有共享的资源，如内存空间等，供其内部的线程共享
进程间通信较为复杂同一台计算机的进程通信称为 IPC（Inter-process communication）

- 信号量：信号量是一个计数器，用于多进程对共享数据的访问，解决同步相关的问题并避免竞争条件
- 共享存储：多个进程可以访问同一块内存空间，需要使用信号量用来同步对共享存储的访问
- 管道通信：管道是用于连接一个读进程和一个写进程以实现它们之间通信的一个共享文件 pipe 文件，该文件同一时间只允许一个进程访问，所以只支持半双工通信

- - 匿名管道（Pipes）：用于具有亲缘关系的父子进程间或者兄弟进程之间的通信
  - 命名管道（Names Pipes）：以磁盘文件的方式存在，可以实现本机任意两个进程通信，遵循 FIFO

- 消息队列：内核中存储消息的链表，由消息队列标识符标识，能在不同进程之间提供全双工通信，对比管道：

- - 匿名管道存在于内存中的文件；命名管道存在于实际的磁盘介质或者文件系统；消息队列存放在内核中，只有在内核重启（操作系统重启）或者显示地删除一个消息队列时，该消息队列才被真正删除
  - 读进程可以根据消息类型有选择地接收消息，而不像 FIFO 那样只能默认地接收不同计算机之间的进程通信，需要通过网络，并遵守共同的协议，例如 HTTP

- 套接字：与其它通信机制不同的是，可用于不同机器间的互相通信

线程通信相对简单，因为线程之间共享进程内的内存，一个例子是多个线程可以访问同一个共享变量 Java 中的通信机制：volatile、等待/通知机制、join 方式、InheritableThreadLocal、MappedByteBuffer
线程更轻量，线程上下文切换成本一般上要比进程上下文切换低

线程

创建线程

Thread

Thread 创建线程方式：创建线程类，匿名内部类方式

start() 方法底层其实是给 CPU 注册当前线程，并且触发 run() 方法执行
线程的启动必须调用 start() 方法，如果线程直接调用 run() 方法，相当于变成了普通类的执行，此时主线程将只有执行该线程
建议线程先创建子线程，主线程的任务放在之后，否则主线程（main）永远是先执行完 Thread 构造器：
public Thread()
public Thread(String name)

public class ThreadDemo {public static void main(String[] args) {Thread t = new MyThread();t.start();for(int i = 0 ; i < 100 ; i++ ){System.out.println("main线程" + i)}// main线程输出放在上面 就变成有先后顺序了，因为是 main 线程驱动的子线程运行}
}
class MyThread extends Thread {@Overridepublic void run() {for(int i = 0 ; i < 100 ; i++ ) {System.out.println("子线程输出："+i)}}
}

继承 Thread 类的优缺点：

优点：编码简单
缺点：线程类已经继承了 Thread 类无法继承其他类了，功能不能通过继承拓展（单继承的局限性）

Runnable

Runnable 创建线程方式：创建线程类，匿名内部类方式 Thread 的构造器：

public Thread(Runnable target)
public Thread(Runnable target, String name)

public class ThreadDemo {public static void main(String[] args) {Runnable target = new MyRunnable();Thread t1 = new Thread(target,"1号线程");t1.start();Thread t2 = new Thread(target);//Thread-0}
}
public class MyRunnable implements Runnable{@Overridepublic void run() {for(int i = 0 ; i < 10 ; i++ ){System.out.println(Thread.currentThread().getName() + "->" + i);}}
}

Thread 类本身也是实现了 Runnable 接口，Thread 类中持有 Runnable 的属性，执行线程 run 方法底层是调用 Runnable#run：

public class Thread implements Runnable {private Runnable target;public void run() {if (target != null) {// 底层调用的是 Runnable 的 run 方法target.run();}}
}

Runnable 方式的优缺点：

缺点：代码复杂一点。
优点：

1. 线程任务类只是实现了 Runnable 接口，可以继续继承其他类，避免了单继承的局限性
2. 同一个线程任务对象可以被包装成多个线程对象
3. 适合多个多个线程去共享同一个资源
4. 实现解耦操作，线程任务代码可以被多个线程共享，线程任务代码和线程独立
5. 线程池可以放入实现 Runnable 或 Callable 线程任务对象

Callable

实现 Callable 接口：

定义一个线程任务类实现 Callable 接口，申明线程执行的结果类型
重写线程任务类的 call 方法，这个方法可以直接返回执行的结果
创建一个 Callable 的线程任务对象
把 Callable 的线程任务对象包装成一个未来任务对象
把未来任务对象包装成线程对象
调用线程的 start() 方法启动线程 public FutureTask(Callable<V> callable)：未来任务对象，在线程执行完后得到线程的执行结果

FutureTask 就是 Runnable 对象，因为 Thread 类只能执行 Runnable 实例的任务对象，所以把 Callable 包装成未来任务对象
线程池部分详解了 FutureTask 的源码 public V get()：同步等待 task 执行完毕的结果，如果在线程中获取另一个线程执行结果，会阻塞等待，用于线程同步
get() 线程会阻塞等待任务执行完成
run() 执行完后会把结果设置到 FutureTask 的一个成员变量，get() 线程可以获取到该变量的值优缺点：
优点：同 Runnable，并且能得到线程执行的结果
缺点：编码复杂

public class ThreadDemo {public static void main(String[] args) {Callable call = new MyCallable();FutureTask<String> task = new FutureTask<>(call);Thread t = new Thread(task);t.start();try {String s = task.get(); // 获取call方法返回的结果（正常/异常结果）System.out.println(s);}  catch (Exception e) {e.printStackTrace();}}
public class MyCallable implements Callable<String> {@Override//重写线程任务类方法public String call() throws Exception {return Thread.currentThread().getName() + "->" + "Hello World";}
}

线程方法

API

Thread 类 API：

方法	说明
public void start()	启动一个新线程，Java虚拟机调用此线程的 run 方法
public void run()	线程启动后调用该方法
public void setName(String name)	给当前线程取名字
public void getName()	获取当前线程的名字线程存在默认名称：子线程是 Thread-索引，主线程是 main
public static Thread currentThread()	获取当前线程对象，代码在哪个线程中执行
public static void sleep(long time)	让当前线程休眠多少毫秒再继续执行 Thread.sleep(0) : 让操作系统立刻重新进行一次 CPU 竞争
public static native void yield()	提示线程调度器让出当前线程对 CPU 的使用
public final int getPriority()	返回此线程的优先级
public final void setPriority(int priority)	更改此线程的优先级，常用 1 5 10
public void interrupt()	中断这个线程，异常处理机制
public static boolean interrupted()	判断当前线程是否被打断，清除打断标记
public boolean isInterrupted()	判断当前线程是否被打断，不清除打断标记
public final void join()	等待这个线程结束
public final void join(long millis)	等待这个线程死亡 millis 毫秒，0 意味着永远等待
public final native boolean isAlive()	线程是否存活（还没有运行完毕）
public final void setDaemon(boolean on)	将此线程标记为守护线程或用户线程

run start

run：称为线程体，包含了要执行的这个线程的内容，方法运行结束，此线程随即终止。直接调用 run 是在主线程中执行了 run，没有启动新的线程，需要顺序执行 start：使用 start 是启动新的线程，此线程处于就绪（可运行）状态，通过新的线程间接执行 run 中的代码说明：线程控制资源类 run() 方法中的异常不能抛出，只能 try/catch

因为父类中没有抛出任何异常，子类不能比父类抛出更多的异常
异常不能跨线程传播回 main() 中，因此必须在本地进行处理

sleep yield

sleep：

调用 sleep 会让当前线程从 Running 进入 Timed Waiting 状态（阻塞）
sleep() 方法的过程中，线程不会释放对象锁
其它线程可以使用 interrupt 方法打断正在睡眠的线程，这时 sleep 方法会抛出 InterruptedException
睡眠结束后的线程未必会立刻得到执行，需要抢占 CPU
建议用 TimeUnit 的 sleep 代替 Thread 的 sleep 来获得更好的可读性 yield：
调用 yield 会让提示线程调度器让出当前线程对 CPU 的使用
具体的实现依赖于操作系统的任务调度器
会放弃 CPU 资源，锁资源不会释放

join

public final void join()：等待这个线程结束原理：调用者轮询检查线程 alive 状态，t1.join() 等价于：

public final synchronized void join(long millis) throws InterruptedException {// 调用者线程进入 thread 的 waitSet 等待, 直到当前线程运行结束while (isAlive()) {wait(0);}
}

join 方法是被 synchronized 修饰的，本质上是一个对象锁，其内部的 wait 方法调用也是释放锁的，但是释放的是当前的线程对象锁，而不是外面的锁
当调用某个线程（t1）的 join 方法后，该线程（t1）抢占到 CPU 资源，就不再释放，直到线程执行完毕线程同步：
join 实现线程同步，因为会阻塞等待另一个线程的结束，才能继续向下运行

- 需要外部共享变量，不符合面向对象封装的思想
- 必须等待线程结束，不能配合线程池使用

Future 实现（同步）：get() 方法阻塞等待执行结果

- main 线程接收结果
- get 方法是让调用线程同步等待

public class Test {static int r = 0;public static void main(String[] args) throws InterruptedException {test1();}private static void test1() throws InterruptedException {Thread t1 = new Thread(() -> {try {Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}r = 10;});t1.start();t1.join();//不等待线程执行结束，输出的10System.out.println(r);}
}

interrupt

打断线程

public void interrupt()：打断这个线程，异常处理机制 public static boolean interrupted()：判断当前线程是否被打断，打断返回 true，清除打断标记，连续调用两次一定返回 false public boolean isInterrupted()：判断当前线程是否被打断，不清除打断标记打断的线程会发生上下文切换，操作系统会保存线程信息，抢占到 CPU 后会从中断的地方接着运行（打断不是停止）

sleep、wait、join 方法都会让线程进入阻塞状态，打断线程会清空打断状态（false）

public static void main(String[] args) throws InterruptedException {Thread t1 = new Thread(()->{try {Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}}, "t1");t1.start();Thread.sleep(500);t1.interrupt();System.out.println(" 打断状态: {}" + t1.isInterrupted());// 打断状态: {}false
}

打断正常运行的线程：不会清空打断状态（true）

public static void main(String[] args) throws Exception {Thread t2 = new Thread(()->{while(true) {Thread current = Thread.currentThread();boolean interrupted = current.isInterrupted();if(interrupted) {System.out.println(" 打断状态: {}" + interrupted);//打断状态: {}truebreak;}}}, "t2");t2.start();Thread.sleep(500);t2.interrupt();
}

打断 park

park 作用类似 sleep，打断 park 线程，不会清空打断状态（true）

public static void main(String[] args) throws Exception {Thread t1 = new Thread(() -> {System.out.println("park...");LockSupport.park();System.out.println("unpark...");System.out.println("打断状态：" + Thread.currentThread().isInterrupted());//打断状态：true}, "t1");t1.start();Thread.sleep(2000);t1.interrupt();
}

如果打断标记已经是 true, 则 park 会失效

LockSupport.park();
System.out.println("unpark...");
LockSupport.park();//失效，不会阻塞
System.out.println("unpark...");//和上一个unpark同时执行

可以修改获取打断状态方法，使用 Thread.interrupted()，清除打断标记 LockSupport 类在同步 → park-un 详解

终止模式

终止模式之两阶段终止模式：Two Phase Termination 目标：在一个线程 T1 中如何优雅终止线程 T2？优雅指的是给 T2 一个后置处理器错误思想：

使用线程对象的 stop() 方法停止线程：stop 方法会真正杀死线程，如果这时线程锁住了共享资源，当它被杀死后就再也没有机会释放锁，其它线程将永远无法获取锁
使用 System.exit(int) 方法停止线程：目的仅是停止一个线程，但这种做法会让整个程序都停止两阶段终止模式图示：
打断线程可能在任何时间，所以需要考虑在任何时刻被打断的处理方法：

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() {@Overridepublic 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();}
}

daemon

public final void setDaemon(boolean on)：如果是 true ，将此线程标记为守护线程线程启动前调用此方法：

Thread t = new Thread() {@Overridepublic void run() {System.out.println("running");}
};
// 设置该线程为守护线程
t.setDaemon(true);
t.start();

用户线程：平常创建的普通线程守护线程：服务于用户线程，只要其它非守护线程运行结束了，即使守护线程代码没有执行完，也会强制结束。守护进程是脱离于终端并且在后台运行的进程，脱离终端是为了避免在执行的过程中的信息在终端上显示说明：当运行的线程都是守护线程，Java 虚拟机将退出，因为普通线程执行完后，JVM 是守护线程，不会继续运行下去常见的守护线程：

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

不推荐

不推荐使用的方法，这些方法已过时，容易破坏同步代码块，造成线程死锁：

public final void stop()：停止线程运行废弃原因：方法粗暴，除非可能执行 finally 代码块以及释放 synchronized 外，线程将直接被终止，如果线程持有 JUC 的互斥锁可能导致锁来不及释放，造成其他线程永远等待的局面
public final void suspend()：挂起（暂停）线程运行 废弃原因：如果目标线程在暂停时对系统资源持有锁，则在目标线程恢复之前没有线程可以访问该资源，如果恢复目标线程的线程在调用 resume 之前会尝试访问此共享资源，则会导致死锁
public final void resume()：恢复线程运行

线程原理

运行机制

Java Virtual Machine Stacks（Java 虚拟机栈）：每个线程启动后，虚拟机就会为其分配一块栈内存

每个栈由多个栈帧（Frame）组成，对应着每次方法调用时所占用的内存
每个线程只能有一个活动栈帧，对应着当前正在执行的那个方法线程上下文切换（Thread Context Switch）：一些原因导致 CPU 不再执行当前线程，转而执行另一个线程
线程的 CPU 时间片用完
垃圾回收
有更高优先级的线程需要运行
线程自己调用了 sleep、yield、wait、join、park 等方法程序计数器（Program Counter Register）：记住下一条 JVM 指令的执行地址，是线程私有的当 Context Switch 发生时，需要由操作系统保存当前线程的状态（PCB 中），并恢复另一个线程的状态，包括程序计数器、虚拟机栈中每个栈帧的信息，如局部变量、操作数栈、返回地址等 JVM 规范并没有限定线程模型，以 HotSopot 为例：
Java 的线程是内核级线程（1:1 线程模型），每个 Java 线程都映射到一个操作系统原生线程，需要消耗一定的内核资源（堆栈）
线程的调度是在内核态运行的，而线程中的代码是在用户态运行，所以线程切换（状态改变）会导致用户与内核态转换进行系统调用，这是非常消耗性能 Java 中 main 方法启动的是一个进程也是一个主线程，main 方法里面的其他线程均为子线程，main 线程是这些线程的父线程

线程调度

线程调度指系统为线程分配处理器使用权的过程，方式有两种：协同式线程调度、抢占式线程调度（Java 选择）协同式线程调度：线程的执行时间由线程本身控制

优点：线程做完任务才通知系统切换到其他线程，相当于所有线程串行执行，不会出现线程同步问题
缺点：线程执行时间不可控，如果代码编写出现问题，可能导致程序一直阻塞，引起系统的奔溃抢占式线程调度：线程的执行时间由系统分配
优点：线程执行时间可控，不会因为一个线程的问题而导致整体系统不可用
缺点：无法主动为某个线程多分配时间 Java 提供了线程优先级的机制，优先级会提示（hint）调度器优先调度该线程，但这仅仅是一个提示，调度器可以忽略它。在线程的就绪状态时，如果 CPU 比较忙，那么优先级高的线程会获得更多的时间片，但 CPU 闲时，优先级几乎没作用说明：并不能通过优先级来判断线程执行的先后顺序

未来优化

内核级线程调度的成本较大，所以引入了更轻量级的协程。用户线程的调度由用户自己实现（多对一的线程模型，多个用户线程映射到一个内核级线程），被设计为协同式调度，所以叫协程

有栈协程：协程会完整的做调用栈的保护、恢复工作，所以叫有栈协程
无栈协程：本质上是一种有限状态机，状态保存在闭包里，比有栈协程更轻量，但是功能有限有栈协程中有一种特例叫纤程，在新并发模型中，一段纤程的代码被分为两部分，执行过程和调度器：
执行过程：用于维护执行现场，保护、恢复上下文状态
调度器：负责编排所有要执行的代码顺序

线程状态

进程的状态参考操作系统：创建态、就绪态、运行态、阻塞态、终止态线程由生到死的完整过程（生命周期）：当线程被创建并启动以后，既不是一启动就进入了执行状态，也不是一直处于执行状态，在 API 中 java.lang.Thread.State 这个枚举中给出了六种线程状态： | 线程状态 | 导致状态发生条件 | | -------------------------- | ------------------------------------------------------------ | | NEW（新建） | 线程刚被创建，但是并未启动，还没调用 start 方法，只有线程对象，没有线程特征 | | Runnable（可运行） | 线程可以在 Java 虚拟机中运行的状态，可能正在运行自己代码，也可能没有，这取决于操作系统处理器，调用了 t.start() 方法：就绪（经典叫法） | | Blocked（阻塞） | 当一个线程试图获取一个对象锁，而该对象锁被其他的线程持有，则该线程进入 Blocked 状态；当该线程持有锁时，该线程将变成 Runnable 状态 | | Waiting（无限等待） | 一个线程在等待另一个线程执行一个（唤醒）动作时，该线程进入 Waiting 状态，进入这个状态后不能自动唤醒，必须等待另一个线程调用 notify 或者 notifyAll 方法才能唤醒 | | Timed Waiting （限期等待） | 有几个方法有超时参数，调用将进入 Timed Waiting 状态，这一状态将一直保持到超时期满或者接收到唤醒通知。带有超时参数的常用方法有 Thread.sleep 、Object.wait | | Teminated（结束） | run 方法正常退出而死亡，或者因为没有捕获的异常终止了 run 方法而死亡 |

NEW → RUNNABLE：当调用 t.start() 方法时，由 NEW → RUNNABLE
RUNNABLE <--> WAITING：

- 调用 obj.wait() 方法时调用 obj.notify()、obj.notifyAll()、t.interrupt()：

- - 竞争锁成功，t 线程从 WAITING → RUNNABLE
  - 竞争锁失败，t 线程从 WAITING → BLOCKED

- 当前线程调用 t.join() 方法，注意是当前线程在 t 线程对象的监视器上等待
- 当前线程调用 LockSupport.park() 方法

RUNNABLE <--> TIMED_WAITING：调用 obj.wait(long n) 方法、当前线程调用 t.join(long n) 方法、当前线程调用 Thread.sleep(long n)
RUNNABLE <--> BLOCKED：t 线程用 synchronized(obj) 获取了对象锁时竞争失败

查看线程

Windows：

任务管理器可以查看进程和线程数，也可以用来杀死进程
tasklist 查看进程
taskkill 杀死进程 Linux：
ps -ef 查看所有进程
ps -fT -p 查看某个进程（PID）的所有线程
kill 杀死进程
top 按大写 H 切换是否显示线程
top -H -p 查看某个进程（PID）的所有线程 Java：
jps 命令查看所有 Java 进程
jstack 查看某个 Java 进程（PID）的所有线程状态
jconsole 来查看某个 Java 进程中线程的运行情况（图形界面）

同步

临界区

临界资源：一次仅允许一个进程使用的资源成为临界资源临界区：访问临界资源的代码块竞态条件：多个线程在临界区内执行，由于代码的执行序列不同而导致结果无法预测，称之为发生了竞态条件一个程序运行多个线程是没有问题，多个线程读共享资源也没有问题，在多个线程对共享资源读写操作时发生指令交错，就会出现问题为了避免临界区的竞态条件发生（解决线程安全问题）：

阻塞式的解决方案：synchronized，lock
非阻塞式的解决方案：原子变量管程（monitor）：由局部于自己的若干公共变量和所有访问这些公共变量的过程所组成的软件模块，保证同一时刻只有一个进程在管程内活动，即管程内定义的操作在同一时刻只被一个进程调用（由编译器实现） synchronized：对象锁，保证了临界区内代码的原子性，采用互斥的方式让同一时刻至多只有一个线程能持有对象锁，其它线程获取这个对象锁时会阻塞，保证拥有锁的线程可以安全的执行临界区内的代码，不用担心线程上下文切换互斥和同步都可以采用 synchronized 关键字来完成，区别：
互斥是保证临界区的竞态条件发生，同一时刻只能有一个线程执行临界区代码
同步是由于线程执行的先后、顺序不同、需要一个线程等待其它线程运行到某个点性能：
线程安全，性能差
线程不安全性能好，假如开发中不会存在多线程安全问题，建议使用线程不安全的设计类

syn-ed

使用锁

同步块

锁对象：理论上可以是任意的唯一对象 synchronized 是可重入、不公平的重量级锁原则上：

锁对象建议使用共享资源
在实例方法中使用 this 作为锁对象，锁住的 this 正好是共享资源
在静态方法中使用类名 .class 字节码作为锁对象，因为静态成员属于类，被所有实例对象共享，所以需要锁住类同步代码块格式：

synchronized(锁对象){// 访问共享资源的核心代码
}

实例：

public class demo {static int counter = 0;//static修饰，则元素是属于类本身的，不属于对象  ，与类一起加载一次，只有一个static final Object room = new Object();public static void main(String[] args) throws InterruptedException {Thread t1 = new Thread(() -> {for (int i = 0; i < 5000; i++) {synchronized (room) {counter++;}}}, "t1");Thread t2 = new Thread(() -> {for (int i = 0; i < 5000; i++) {synchronized (room) {counter--;}}}, "t2");t1.start();t2.start();t1.join();t2.join();System.out.println(counter);}
}

同步方法

把出现线程安全问题的核心方法锁起来，每次只能一个线程进入访问 synchronized 修饰的方法的不具备继承性，所以子类是线程不安全的，如果子类的方法也被 synchronized 修饰，两个锁对象其实是一把锁，而且是子类对象作为锁 用法：直接给方法加上一个修饰符 synchronized

//同步方法
修饰符 synchronized 返回值类型 方法名(方法参数) { 方法体；
}
//同步静态方法
修饰符 static synchronized 返回值类型 方法名(方法参数) { 方法体；
}

同步方法底层也是有锁对象的：

如果方法是实例方法：同步方法默认用 this 作为的锁对象

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

如果方法是静态方法：同步方法默认用类名 .class 作为的锁对象

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

线程八锁

线程八锁就是考察 synchronized 锁住的是哪个对象，直接百度搜索相关的实例说明：主要关注锁住的对象是不是同一个

锁住类对象，所有类的实例的方法都是安全的，类的所有实例都相当于同一把锁
锁住 this 对象，只有在当前实例对象的线程内是安全的，如果有多个实例就不安全线程不安全：因为锁住的不是同一个对象，线程 1 调用 a 方法锁住的类对象，线程 2 调用 b 方法锁住的 n2 对象，不是同一个对象

class Number{public static synchronized void a(){Thread.sleep(1000);System.out.println("1");}public synchronized void b() {System.out.println("2");}
}
public static void main(String[] args) {Number n1 = new Number();Number n2 = new Number();new Thread(()->{ n1.a(); }).start();new Thread(()->{ n2.b(); }).start();
}

线程安全：因为 n1 调用 a() 方法，锁住的是类对象，n2 调用 b() 方法，锁住的也是类对象，所以线程安全

class Number{public static synchronized void a(){Thread.sleep(1000);System.out.println("1");}public static synchronized void b() {System.out.println("2");}
}
public static void main(String[] args) {Number n1 = new Number();Number n2 = new Number();new Thread(()->{ n1.a(); }).start();new Thread(()->{ n2.b(); }).start();
}

锁原理

Monitor

Monitor 被翻译为监视器或管程每个 Java 对象都可以关联一个 Monitor 对象，Monitor 也是 class，其实例存储在堆中，如果使用 synchronized 给对象上锁（重量级）之后，该对象头的 Mark Word 中就被设置指向 Monitor 对象的指针，这就是重量级锁

Mark Word 结构：最后两位是锁标志位
64 位虚拟机 Mark Word：
工作流程：
开始时 Monitor 中 Owner 为 null
当 Thread-2 执行 synchronized(obj) 就会将 Monitor 的所有者 Owner 置为 Thread-2，Monitor 中只能有一个 Owner，obj 对象的 Mark Word 指向 Monitor，把对象原有的 MarkWord 存入线程栈中的锁记录中（轻量级锁部分详解）
在 Thread-2 上锁的过程，Thread-3、Thread-4、Thread-5 也执行 synchronized(obj)，就会进入 EntryList BLOCKED（双向链表）
Thread-2 执行完同步代码块的内容，根据 obj 对象头中 Monitor 地址寻找，设置 Owner 为空，把线程栈的锁记录中的对象头的值设置回 MarkWord
唤醒 EntryList 中等待的线程来竞争锁，竞争是非公平的，如果这时有新的线程想要获取锁，可能直接就抢占到了，阻塞队列的线程就会继续阻塞
WaitSet 中的 Thread-0，是以前获得过锁，但条件不满足进入 WAITING 状态的线程（wait-notify 机制）
注意：
synchronized 必须是进入同一个对象的 Monitor 才有上述的效果
不加 synchronized 的对象不会关联监视器，不遵从以上规则

字节码

代码：

public static void main(String[] args) {Object lock = new Object();synchronized (lock) {System.out.println("ok");}
}

0: 	new				#2		// new Object
3: 	dup
4: 	invokespecial 	#1 		// invokespecial <init>:()V，非虚方法
7: 	astore_1 				// lock引用 -> lock
8: 	aload_1					// lock （synchronized开始）
9: 	dup						// 一份用来初始化，一份用来引用
10: astore_2 				// lock引用 -> slot 2
11: monitorenter 			// 【将 lock对象 MarkWord 置为 Monitor 指针】
12: getstatic 		#3		// System.out
15: ldc 			#4		// "ok"
17: invokevirtual 	#5 		// invokevirtual println:(Ljava/lang/String;)V
20: aload_2 				// slot 2(lock引用)
21: monitorexit 			// 【将 lock对象 MarkWord 重置, 唤醒 EntryList】
22: goto 30
25: astore_3 				// any -> slot 3
26: aload_2 				// slot 2(lock引用)
27: monitorexit 			// 【将 lock对象 MarkWord 重置, 唤醒 EntryList】
28: aload_3
29: athrow
30: return
Exception table:from to target type12 22 25 		any25 28 25 		any
LineNumberTable: ...
LocalVariableTable:Start Length Slot Name Signature0 	31 		0 args [Ljava/lang/String;8 	23 		1 lock Ljava/lang/Object;

说明：

通过异常 try-catch 机制，确保一定会被解锁
方法级别的 synchronized 不会在字节码指令中有所体现

锁升级

升级过程

synchronized 是可重入、不公平的重量级锁，所以可以对其进行优化

无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁	// 随着竞争的增加，只能锁升级，不能降级

偏向锁

偏向锁的思想是偏向于让第一个获取锁对象的线程，这个线程之后重新获取该锁不再需要同步操作：

当锁对象第一次被线程获得的时候进入偏向状态，标记为 101，同时使用 CAS 操作将线程 ID 记录到 Mark Word。如果 CAS 操作成功，这个线程以后进入这个锁相关的同步块，查看这个线程 ID 是自己的就表示没有竞争，就不需要再进行任何同步操作
当有另外一个线程去尝试获取这个锁对象时，偏向状态就宣告结束，此时撤销偏向（Revoke Bias）后恢复到未锁定或轻量级锁状态
一个对象创建时：
如果开启了偏向锁（默认开启），那么对象创建后，MarkWord 值为 0x05 即最后 3 位为 101，thread、epoch、age 都为 0
偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加 VM 参数 -XX:BiasedLockingStartupDelay=0 来禁用延迟。JDK 8 延迟 4s 开启偏向锁原因：在刚开始执行代码时，会有好多线程来抢锁，如果开偏向锁效率反而降低
当一个对象已经计算过 hashCode，就再也无法进入偏向状态了
添加 VM 参数 -XX:-UseBiasedLocking 禁用偏向锁撤销偏向锁的状态：
调用对象的 hashCode：偏向锁的对象 MarkWord 中存储的是线程 id，调用 hashCode 导致偏向锁被撤销
当有其它线程使用偏向锁对象时，会将偏向锁升级为轻量级锁
调用 wait/notify，需要申请 Monitor，进入 WaitSet 批量撤销：如果对象被多个线程访问，但没有竞争，这时偏向了线程 T1 的对象仍有机会重新偏向 T2，重偏向会重置对象的 Thread ID
批量重偏向：当撤销偏向锁阈值超过 20 次后，JVM 会觉得是不是偏向错了，于是在给这些对象加锁时重新偏向至加锁线程
批量撤销：当撤销偏向锁阈值超过 40 次后，JVM 会觉得自己确实偏向错了，根本就不该偏向，于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的

轻量级锁

一个对象有多个线程要加锁，但加锁的时间是错开的（没有竞争），可以使用轻量级锁来优化，轻量级锁对使用者是透明的（不可见）可重入锁：线程可以进入任何一个它已经拥有的锁所同步着的代码块，可重入锁最大的作用是避免死锁 轻量级锁在没有竞争时（锁重入时），每次重入仍然需要执行 CAS 操作，Java 6 才引入的偏向锁来优化锁重入实例：

static final Object obj = new Object();
public static void method1() {synchronized( obj ) {// 同步块 Amethod2();}
}
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 的锁记录，表示有重入，这时重置锁记录，表示重入计数减 1
- 如果锁记录的值不为 null，这时使用 CAS 将 Mark Word 的值恢复给对象头

- - 成功，则解锁成功
  - 失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程

锁膨胀

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

当 Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁
Thread-1 加轻量级锁失败，进入锁膨胀流程：为 Object 对象申请 Monitor 锁，通过 Object 对象头获取到持锁线程，将 Monitor 的 Owner 置为 Thread-0，将 Object 的对象头指向重量级锁地址，然后自己进入 Monitor 的 EntryList BLOCKED
当 Thread-0 退出同步块解锁时，使用 CAS 将 Mark Word 的值恢复给对象头失败，这时进入重量级解锁流程，即按照 Monitor 地址找到 Monitor 对象，设置 Owner 为 null，唤醒 EntryList 中 BLOCKED 线程

锁优化

自旋锁

重量级锁竞争时，尝试获取锁的线程不会立即阻塞，可以使用自旋（默认 10 次）来进行优化，采用循环的方式去尝试获取锁注意：

自旋占用 CPU 时间，单核 CPU 自旋就是浪费时间，因为同一时刻只能运行一个线程，多核 CPU 自旋才能发挥优势
自旋失败的线程会进入阻塞状态优点：不会进入阻塞状态，减少线程上下文切换的消耗 缺点：当自旋的线程越来越多时，会不断的消耗 CPU 资源自旋锁情况：
自旋成功的情况：
自旋失败的情况：
自旋锁说明：
在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，比较智能
Java 7 之后不能控制是否开启自旋功能，由 JVM 控制

//手写自旋锁
public class SpinLock {// 泛型装的是Thread，原子引用线程AtomicReference<Thread> atomicReference = new AtomicReference<>();public void lock() {Thread thread = Thread.currentThread();System.out.println(thread.getName() + " come in");//开始自旋，期望值为null，更新值是当前线程while (!atomicReference.compareAndSet(null, thread)) {Thread.sleep(1000);System.out.println(thread.getName() + " 正在自旋");}System.out.println(thread.getName() + " 自旋成功");}public void unlock() {Thread thread = Thread.currentThread();//线程使用完锁把引用变为nullatomicReference.compareAndSet(thread, null);System.out.println(thread.getName() + " invoke unlock");}public static void main(String[] args) throws InterruptedException {SpinLock lock = new SpinLock();new Thread(() -> {//占有锁lock.lock();Thread.sleep(10000); //释放锁lock.unlock();},"t1").start();// 让main线程暂停1秒，使得t1线程，先执行Thread.sleep(1000);new Thread(() -> {lock.lock();lock.unlock();},"t2").start();}
}

锁消除

锁消除是指对于被检测出不可能存在竞争的共享数据的锁进行消除，这是 JVM 即时编译器的优化 锁消除主要是通过逃逸分析来支持，如果堆上的共享数据不可能逃逸出去被其它线程访问到，那么就可以把它们当成私有数据对待，也就可以将它们的锁进行消除（同步消除：JVM 逃逸分析）

锁粗化

对相同对象多次加锁，导致线程发生多次重入，频繁的加锁操作就会导致性能损耗，可以使用锁粗化方式优化如果虚拟机探测到一串的操作都对同一个对象加锁，将会把加锁的范围扩展（粗化）到整个操作序列的外部

一些看起来没有加锁的代码，其实隐式的加了很多锁：

public static String concatString(String s1, String s2, String s3) {return s1 + s2 + s3;
}

String 是一个不可变的类，编译器会对 String 的拼接自动优化。在 JDK 1.5 之前，转化为 StringBuffer 对象的连续 append() 操作，每个 append() 方法中都有一个同步块

public static String concatString(String s1, String s2, String s3) {StringBuffer sb = new StringBuffer();sb.append(s1);sb.append(s2);sb.append(s3);return sb.toString();
}

扩展到第一个 append() 操作之前直至最后一个 append() 操作之后，只需要加锁一次就可以

多把锁

多把不相干的锁：一间大屋子有两个功能睡觉、学习，互不相干。现在一人要学习，一人要睡觉，如果只用一间屋子（一个对象锁）的话，那么并发度很低将锁的粒度细分：

好处，是可以增强并发度
坏处，如果一个线程需要同时获得多把锁，就容易发生死锁解决方法：准备多个对象锁

public static void main(String[] args) {BigRoom bigRoom = new BigRoom();new Thread(() -> { bigRoom.study(); }).start();new Thread(() -> { bigRoom.sleep(); }).start();
}
class BigRoom {private final Object studyRoom = new Object();private final Object sleepRoom = new Object();public void sleep() throws InterruptedException {synchronized (sleepRoom) {System.out.println("sleeping 2 小时");Thread.sleep(2000);}}public void study() throws InterruptedException {synchronized (studyRoom) {System.out.println("study 1 小时");Thread.sleep(1000);}}
}

活跃性

死锁

形成

死锁：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放，由于线程被无限期地阻塞，因此程序不可能正常终止 Java 死锁产生的四个必要条件：

互斥条件，即当资源被一个线程使用（占有）时，别的线程不能使用
不可剥夺条件，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放
请求和保持条件，即当资源请求者在请求其他的资源的同时保持对原有资源的占有
循环等待条件，即存在一个等待循环队列：p1 要 p2 的资源，p2 要 p1 的资源，形成了一个等待环路四个条件都成立的时候，便形成死锁。死锁情况下打破上述任何一个条件，便可让死锁消失

public class Dead {public static Object resources1 = new Object();public static Object resources2 = new Object();public static void main(String[] args) {new Thread(() -> {// 线程1：占用资源1 ，请求资源2synchronized(resources1){System.out.println("线程1已经占用了资源1，开始请求资源2");Thread.sleep(2000);//休息两秒，防止线程1直接运行完成。//2秒内线程2肯定可以锁住资源2synchronized (resources2){System.out.println("线程1已经占用了资源2");}}).start();new Thread(() -> {// 线程2：占用资源2 ，请求资源1synchronized(resources2){System.out.println("线程2已经占用了资源2，开始请求资源1");Thread.sleep(2000);synchronized (resources1){System.out.println("线程2已经占用了资源1");}}}}).start();}
}

定位

定位死锁的方法：

使用 jps 定位进程 id，再用 jstack id 定位死锁，找到死锁的线程去查看源码，解决优化

"Thread-1" #12 prio=5 os_prio=0 tid=0x000000001eb69000 nid=0xd40 waiting formonitor entry [0x000000001f54f000]java.lang.Thread.State: BLOCKED (on object monitor)
#省略    
"Thread-1" #12 prio=5 os_prio=0 tid=0x000000001eb69000 nid=0xd40 waiting for monitor entry [0x000000001f54f000]java.lang.Thread.State: BLOCKED (on object monitor)
#省略
Found one Java-level deadlock:
===================================================
"Thread-1":waiting to lock monitor 0x000000000361d378 (object 0x000000076b5bf1c0, a java.lang.Object),which is held by "Thread-0"
"Thread-0":waiting to lock monitor 0x000000000361e768 (object 0x000000076b5bf1d0, a java.lang.Object),which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":at thread.TestDeadLock.lambda$main$1(TestDeadLock.java:28)- waiting to lock <0x000000076b5bf1c0> (a java.lang.Object)- locked <0x000000076b5bf1d0> (a java.lang.Object)at thread.TestDeadLock$$Lambda$2/883049899.run(Unknown Source)at java.lang.Thread.run(Thread.java:745)
"Thread-0":at thread.TestDeadLock.lambda$main$0(TestDeadLock.java:15)- waiting to lock <0x000000076b5bf1d0> (a java.lang.Object)- locked <0x000000076b5bf1c0> (a java.lang.Object)at thread.TestDeadLock$$Lambda$1/495053715

Linux 下可以通过 top 先定位到 CPU 占用高的 Java 进程，再利用 top -Hp 进程id 来定位是哪个线程，最后再用 jstack 的输出来看各个线程栈
避免死锁：避免死锁要注意加锁顺序
可以使用 jconsole 工具，在 jdk\bin 目录下

活锁

活锁：指的是任务或者执行者没有被阻塞，由于某些条件没有满足，导致一直重复尝试—失败—尝试—失败的过程两个线程互相改变对方的结束条件，最后谁也无法结束：

class TestLiveLock {static volatile int count = 10;static final Object lock = new Object();public static void main(String[] args) {new Thread(() -> {// 期望减到 0 退出循环while (count > 0) {Thread.sleep(200);count--;System.out.println("线程一count:" + count);}}, "t1").start();new Thread(() -> {// 期望超过 20 退出循环while (count < 20) {Thread.sleep(200);count++;System.out.println("线程二count:"+ count);}}, "t2").start();}
}

饥饿

饥饿：一个线程由于优先级太低，始终得不到 CPU 调度执行，也不能够结束

wait-ify

基本使用

需要获取对象锁后才可以调用锁对象.wait()，notify 随机唤醒一个线程，notifyAll 唤醒所有线程去竞争 CPU Object 类 API：

public final void notify():唤醒正在等待对象监视器的单个线程。
public final void notifyAll():唤醒正在等待对象监视器的所有线程。
public final void wait():导致当前线程等待，直到另一个线程调用该对象的 notify() 方法或 notifyAll()方法。
public final native void wait(long timeout):有时限的等待, 到n毫秒后结束等待，或是被唤醒

说明：wait 是挂起线程，需要唤醒的都是挂起操作，阻塞线程可以自己去争抢锁，挂起的线程需要唤醒后去争抢锁对比 sleep()：

原理不同：sleep() 方法是属于 Thread 类，是线程用来控制自身流程的，使此线程暂停执行一段时间而把执行机会让给其他线程；wait() 方法属于 Object 类，用于线程间通信
对锁的处理机制不同：调用 sleep() 方法的过程中，线程不会释放对象锁，当调用 wait() 方法的时候，线程会放弃对象锁，进入等待此对象的等待锁定池（不释放锁其他线程怎么抢占到锁执行唤醒操作），但是都会释放 CPU
使用区域不同：wait() 方法必须放在**同步控制方法和同步代码块（先获取锁）**中使用，sleep() 方法则可以放在任何地方使用底层原理：
Owner 线程发现条件不满足，调用 wait 方法，即可进入 WaitSet 变为 WAITING 状态
BLOCKED 和 WAITING 的线程都处于阻塞状态，不占用 CPU 时间片
BLOCKED 线程会在 Owner 线程释放锁时唤醒
WAITING 线程会在 Owner 线程调用 notify 或 notifyAll 时唤醒，唤醒后并不意味者立刻获得锁，需要进入 EntryList 重新竞争

代码优化

虚假唤醒：notify 只能随机唤醒一个 WaitSet 中的线程，这时如果有其它线程也在等待，那么就可能唤醒不了正确的线程解决方法：采用 notifyAll notifyAll 仅解决某个线程的唤醒问题，使用 if + wait 判断仅有一次机会，一旦条件不成立，无法重新判断解决方法：用 while + wait，当条件不成立，再次 wait

@Slf4j(topic = "c.demo")
public class demo {static final Object room = new Object();static boolean hasCigarette = false;    //有没有烟static boolean hasTakeout = false;public static void main(String[] args) throws InterruptedException {new Thread(() -> {synchronized (room) {log.debug("有烟没？[{}]", hasCigarette);while (!hasCigarette) {//while防止虚假唤醒log.debug("没烟，先歇会！");try {room.wait();} catch (InterruptedException e) {e.printStackTrace();}}log.debug("有烟没？[{}]", hasCigarette);if (hasCigarette) {log.debug("可以开始干活了");} else {log.debug("没干成活...");}}}, "小南").start();new Thread(() -> {synchronized (room) {Thread thread = Thread.currentThread();log.debug("外卖送到没？[{}]", hasTakeout);if (!hasTakeout) {log.debug("没外卖，先歇会！");try {room.wait();} catch (InterruptedException e) {e.printStackTrace();}}log.debug("外卖送到没？[{}]", hasTakeout);if (hasTakeout) {log.debug("可以开始干活了");} else {log.debug("没干成活...");}}}, "小女").start();Thread.sleep(1000);new Thread(() -> {// 这里能不能加 synchronized (room)？synchronized (room) {hasTakeout = true;//log.debug("烟到了噢！");log.debug("外卖到了噢！");room.notifyAll();}}, "送外卖的").start();}
}

park-un

LockSupport 是用来创建锁和其他同步类的线程原语 LockSupport 类方法：

LockSupport.park()：暂停当前线程，挂起原语
LockSupport.unpark(暂停的线程对象)：恢复某个线程的运行

public static void main(String[] args) {Thread t1 = new Thread(() -> {System.out.println("start...");	//1Thread.sleep(1000);// Thread.sleep(3000)// 先 park 再 unpark 和先 unpark 再 park 效果一样，都会直接恢复线程的运行System.out.println("park...");	//2LockSupport.park();System.out.println("resume...");//4},"t1");t1.start();Thread.sleep(2000);System.out.println("unpark...");	//3LockSupport.unpark(t1);
}

LockSupport 出现就是为了增强 wait & notify 的功能：

wait，notify 和 notifyAll 必须配合 Object Monitor 一起使用，而 park、unpark 不需要
park & unpark 以线程为单位来阻塞和唤醒线程，而 notify 只能随机唤醒一个等待线程，notifyAll 是唤醒所有等待线程
park & unpark 可以先 unpark，而 wait & notify 不能先 notify。类比生产消费，先消费发现有产品就消费，没有就等待；先生产就直接产生商品，然后线程直接消费
wait 会释放锁资源进入等待队列，park 不会释放锁资源，只负责阻塞当前线程，会释放 CPU 原理：类似生产者消费者
先 park：

1. 当前线程调用 Unsafe.park() 方法
2. 检查 _counter ，本情况为 0，这时获得 _mutex 互斥锁
3. 线程进入 _cond 条件变量挂起
4. 调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1
5. 唤醒 _cond 条件变量中的 Thread_0，Thread_0 恢复运行，设置 _counter 为 0

先 unpark：

1. 调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1
2. 当前线程调用 Unsafe.park() 方法
3. 检查 _counter ，本情况为 1，这时线程无需挂起，继续运行，设置 _counter 为 0

安全分析

成员变量和静态变量：

如果它们没有共享，则线程安全
如果它们被共享了，根据它们的状态是否能够改变，分两种情况：

- 如果只有读操作，则线程安全
- 如果有读写操作，则这段代码是临界区，需要考虑线程安全问题局部变量：

局部变量是线程安全的
局部变量引用的对象不一定线程安全（逃逸分析）：

- 如果该对象没有逃离方法的作用访问，它是线程安全的（每一个方法有一个栈帧）
- 如果该对象逃离方法的作用范围，需要考虑线程安全问题（暴露引用）常见线程安全类：String、Integer、StringBuffer、Random、Vector、Hashtable、java.util.concurrent 包

线程安全的是指，多个线程调用它们同一个实例的某个方法时，是线程安全的
每个方法是原子的，但多个方法的组合不是原子的，只能保证调用的方法内部安全：

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

无状态类线程安全，就是没有成员变量的类不可变类线程安全：String、Integer 等都是不可变类，内部的状态不可以改变，所以方法是线程安全

replace 等方法底层是新建一个对象，复制过去

Map<String,Object> map = new HashMap<>();	// 线程不安全
String S1 = "...";							// 线程安全
final String S2 = "...";					// 线程安全
Date D1 = new Date();						// 线程不安全
final Date D2 = new Date();					// 线程不安全，final让D2引用的对象不能变，但对象的内容可以变

抽象方法如果有参数，被重写后行为不确定可能造成线程不安全，被称之为外星方法：public abstract foo(Student s);

同步模式

保护性暂停

单任务版

Guarded Suspension，用在一个线程等待另一个线程的执行结果

有一个结果需要从一个线程传递到另一个线程，让它们关联同一个 GuardedObject
如果有结果不断从一个线程到另一个线程那么可以使用消息队列（见生产者/消费者）
JDK 中，join 的实现、Future 的实现，采用的就是此模式

public static void main(String[] args) {GuardedObject object = new GuardedObjectV2();new Thread(() -> {sleep(1);object.complete(Arrays.asList("a", "b", "c"));}).start();Object response = object.get(2500);if (response != null) {log.debug("get response: [{}] lines", ((List<String>) response).size());} else {log.debug("can't get response");}
}
class GuardedObject {private Object response;private final Object lock = new Object();//获取结果//timeout :最大等待时间public Object get(long millis) {synchronized (lock) {// 1) 记录最初时间long begin = System.currentTimeMillis();// 2) 已经经历的时间long timePassed = 0;while (response == null) {// 4) 假设 millis 是 1000，结果在 400 时唤醒了，那么还有 600 要等long waitTime = millis - timePassed;log.debug("waitTime: {}", waitTime);//经历时间超过最大等待时间退出循环if (waitTime <= 0) {log.debug("break...");break;}try {lock.wait(waitTime);} catch (InterruptedException e) {e.printStackTrace();}// 3) 如果提前被唤醒，这时已经经历的时间假设为 400timePassed = System.currentTimeMillis() - begin;log.debug("timePassed: {}, object is null {}",timePassed, response == null);}return response;}}//产生结果public void complete(Object response) {synchronized (lock) {// 条件满足，通知等待线程this.response = response;log.debug("notify...");lock.notifyAll();}}
}

多任务版

多任务版保护性暂停：

public static void main(String[] args) throws InterruptedException {for (int i = 0; i < 3; i++) {new People().start();}Thread.sleep(1000);for (Integer id : Mailboxes.getIds()) {new Postman(id, id + "号快递到了").start();}
}
@Slf4j(topic = "c.People")
class People extends Thread{@Overridepublic void run() {// 收信GuardedObject guardedObject = Mailboxes.createGuardedObject();log.debug("开始收信i d:{}", guardedObject.getId());Object mail = guardedObject.get(5000);log.debug("收到信id:{}，内容:{}", guardedObject.getId(),mail);}
}
class Postman extends Thread{private int id;private String mail;//构造方法@Overridepublic void run() {GuardedObject guardedObject = Mailboxes.getGuardedObject(id);log.debug("开始送信i d:{}，内容:{}", guardedObject.getId(),mail);guardedObject.complete(mail);}
}
class  Mailboxes {private static Map<Integer, GuardedObject> boxes = new Hashtable<>();private static int id = 1;//产生唯一的idprivate static synchronized int generateId() {return id++;}public static GuardedObject getGuardedObject(int id) {return boxes.remove(id);}public static GuardedObject createGuardedObject() {GuardedObject go = new GuardedObject(generateId());boxes.put(go.getId(), go);return go;}public static Set<Integer> getIds() {return boxes.keySet();}
}
class GuardedObject {//标识，Guarded Objectprivate int id;//添加get set方法
}

顺序输出

顺序输出 2 1

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

交替输出

连续输出 5 次 abc

public class day2_14 {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);}).start();new Thread(() -> {awaitSignal.print("b", b, c);}).start();new Thread(() -> {awaitSignal.print("c", c, a);}).start();Thread.sleep(1000);awaitSignal.lock();try {a.signal();} finally {awaitSignal.unlock();}}
}
class AwaitSignal extends ReentrantLock {private int loopNumber;public AwaitSignal(int loopNumber) {this.loopNumber = loopNumber;}//参数1：打印内容  参数二：条件变量  参数二：唤醒下一个public void print(String str, Condition condition, Condition next) {for (int i = 0; i < loopNumber; i++) {lock();try {condition.await();System.out.print(str);next.signal();} catch (InterruptedException e) {e.printStackTrace();} finally {unlock();}}}
}

异步模式

传统版

异步模式之生产者/消费者：

class ShareData {private int number = 0;private Lock lock = new ReentrantLock();private Condition condition = lock.newCondition();public void increment() throws Exception{// 同步代码块，加锁lock.lock();try {// 判断  防止虚假唤醒while(number != 0) {// 等待不能生产condition.await();}// 干活number++;System.out.println(Thread.currentThread().getName() + "\t " + number);// 通知 唤醒condition.signalAll();} catch (Exception e) {e.printStackTrace();} finally {lock.unlock();}}public void decrement() throws Exception{// 同步代码块，加锁lock.lock();try {// 判断 防止虚假唤醒while(number == 0) {// 等待不能消费condition.await();}// 干活number--;System.out.println(Thread.currentThread().getName() + "\t " + number);// 通知 唤醒condition.signalAll();} catch (Exception e) {e.printStackTrace();} finally {lock.unlock();}}
}
public class TraditionalProducerConsumer {public static void main(String[] args) {ShareData shareData = new ShareData();// t1线程，生产new Thread(() -> {for (int i = 0; i < 5; i++) {shareData.increment();}}, "t1").start();// t2线程，消费new Thread(() -> {for (int i = 0; i < 5; i++) {shareData.decrement();}}, "t2").start(); }
}

改进版

异步模式之生产者/消费者：

消费队列可以用来平衡生产和消费的线程资源，不需要产生结果和消费结果的线程一一对应
生产者仅负责产生结果数据，不关心数据该如何处理，而消费者专心处理结果数据
消息队列是有容量限制的，满时不会再加入数据，空时不会再消耗数据
JDK 中各种阻塞队列，采用的就是这种模式

public class demo {public static void main(String[] args) {MessageQueue queue = new MessageQueue(2);for (int i = 0; i < 3; i++) {int id = i;new Thread(() -> {queue.put(new Message(id,"值"+id));}, "生产者" + i).start();}new Thread(() -> {while (true) {try {Thread.sleep(1000);Message message = queue.take();} catch (InterruptedException e) {e.printStackTrace();}}},"消费者").start();}
}
//消息队列类，Java间线程之间通信
class MessageQueue {private LinkedList<Message> list = new LinkedList<>();//消息的队列集合private int capacity;//队列容量public MessageQueue(int capacity) {this.capacity = capacity;}//获取消息public Message take() {//检查队列是否为空synchronized (list) {while (list.isEmpty()) {try {sout(Thread.currentThread().getName() + ":队列为空，消费者线程等待");list.wait();} catch (InterruptedException e) {e.printStackTrace();}}//从队列的头部获取消息返回Message message = list.removeFirst();sout(Thread.currentThread().getName() + "：已消费消息--" + message);list.notifyAll();return message;}}//存入消息public void put(Message message) {synchronized (list) {//检查队列是否满while (list.size() == capacity) {try {sout(Thread.currentThread().getName()+":队列为已满，生产者线程等待");list.wait();} catch (InterruptedException e) {e.printStackTrace();}}//将消息加入队列尾部list.addLast(message);sout(Thread.currentThread().getName() + ":已生产消息--" + message);list.notifyAll();}}
}
final class Message {private int id;private Object value;//get set
}

阻塞队列

public static void main(String[] args) {ExecutorService consumer = Executors.newFixedThreadPool(1);ExecutorService producer = Executors.newFixedThreadPool(1);BlockingQueue<Integer> queue = new SynchronousQueue<>();producer.submit(() -> {try {System.out.println("生产...");Thread.sleep(1000);queue.put(10);} catch (InterruptedException e) {e.printStackTrace();}});consumer.submit(() -> {try {System.out.println("等待消费...");Integer result = queue.take();System.out.println("结果为:" + result);} catch (InterruptedException e) {e.printStackTrace();}});
}

内存

JMM

内存模型

Java 内存模型是 Java Memory Model（JMM），本身是一种抽象的概念，实际上并不存在，描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式 JMM 作用：

屏蔽各种硬件和操作系统的内存访问差异，实现让 Java 程序在各种平台下都能达到一致的内存访问效果
规定了线程和内存之间的一些关系根据 JMM 的设计，系统存在一个主内存（Main Memory），Java 中所有变量都存储在主存中，对于所有线程都是共享的；每条线程都有自己的工作内存（Working Memory），工作内存中保存的是主存中某些变量的拷贝，线程对所有变量的操作都是先对变量进行拷贝，然后在工作内存中进行，不能直接操作主内存中的变量；线程之间无法相互直接访问，线程间的通信（传递）必须通过主内存来完成
主内存和工作内存：
主内存：计算机的内存，也就是经常提到的 8G 内存，16G 内存，存储所有共享变量的值
工作内存：存储该线程使用到的共享变量在主内存的的值的副本拷贝 JVM 和 JMM 之间的关系：JMM 中的主内存、工作内存与 JVM 中的 Java 堆、栈、方法区等并不是同一个层次的内存划分，这两者基本上是没有关系的，如果两者一定要勉强对应起来：
主内存主要对应于 Java 堆中的对象实例数据部分，而工作内存则对应于虚拟机栈中的部分区域
从更低层次上说，主内存直接对应于物理硬件的内存，工作内存对应寄存器和高速缓存

内存交互

Java 内存模型定义了 8 个操作来完成主内存和工作内存的交互操作，每个操作都是原子的非原子协定：没有被 volatile 修饰的 long、double 外，默认按照两次 32 位的操作

lock：作用于主内存，将一个变量标识为被一个线程独占状态（对应 monitorenter）
unclock：作用于主内存，将一个变量从独占状态释放出来，释放后的变量才可以被其他线程锁定（对应 monitorexit）
read：作用于主内存，把一个变量的值从主内存传输到工作内存中
load：作用于工作内存，在 read 之后执行，把 read 得到的值放入工作内存的变量副本中
use：作用于工作内存，把工作内存中一个变量的值传递给执行引擎，每当遇到一个使用到变量的操作时都要使用该指令
assign：作用于工作内存，把从执行引擎接收到的一个值赋给工作内存的变量
store：作用于工作内存，把工作内存的一个变量的值传送到主内存中
write：作用于主内存，在 store 之后执行，把 store 得到的值放入主内存的变量中参考文章：CS-Notes/notes/Java 并发.md at master · CyC2018/CS-Notes · GitHub

三大特性

可见性

可见性：是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值存在不可见问题的根本原因是由于缓存的存在，线程持有的是共享变量的副本，无法感知其他线程对于共享变量的更改，导致读取的值不是最新的。但是 final 修饰的变量是不可变的，就算有缓存，也不会存在不可见的问题 main 线程对 run 变量的修改对于 t 线程不可见，导致了 t 线程无法停止：

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

原因：

初始状态， t 线程刚开始从主内存读取了 run 的值到工作内存
因为 t 线程要频繁从主内存中读取 run 的值，JIT 编译器会将 run 的值缓存至自己工作内存中的高速缓存中，减少对主存中 run 的访问，提高效率
1 秒之后，main 线程修改了 run 的值，并同步至主存，而 t 是从自己工作内存中的高速缓存中读取这个变量的值，结果永远是旧值

原子性

原子性：不可分割，完整性，也就是说某个线程正在做某个具体业务时，中间不可以被分割，需要具体完成，要么同时成功，要么同时失败，保证指令不会受到线程上下文切换的影响定义原子操作的使用规则：

不允许 read 和 load、store 和 write 操作之一单独出现，必须顺序执行，但是不要求连续
不允许一个线程丢弃 assign 操作，必须同步回主存
不允许一个线程无原因地（没有发生过任何 assign 操作）把数据从工作内存同步会主内存中
一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（assign 或者 load）的变量，即对一个变量实施 use 和 store 操作之前，必须先自行 assign 和 load 操作
一个变量在同一时刻只允许一条线程对其进行 lock 操作，但 lock 操作可以被同一线程重复执行多次，多次执行 lock 后，只有执行相同次数的 unlock 操作，变量才会被解锁，lock 和 unlock 必须成对出现
如果对一个变量执行 lock 操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量之前需要重新从主存加载
如果一个变量事先没有被 lock 操作锁定，则不允许执行 unlock 操作，也不允许去 unlock 一个被其他线程锁定的变量
对一个变量执行 unlock 操作之前，必须先把此变量同步到主内存中（执行 store 和 write 操作）

有序性

有序性：在本线程内观察，所有操作都是有序的；在一个线程观察另一个线程，所有操作都是无序的，无序是因为发生了指令重排序 CPU 的基本工作是执行存储的指令序列，即程序，程序的执行过程实际上是不断地取出指令、分析指令、执行指令的过程，为了提高性能，编译器和处理器会对指令重排，一般分为以下三种：

源代码 -> 编译器优化的重排 -> 指令并行的重排 -> 内存系统的重排 -> 最终执行指令

现代 CPU 支持多级指令流水线，几乎所有的冯•诺伊曼型计算机的 CPU，其工作都可以分为 5 个阶段：取指令、指令译码、执行指令、访存取数和结果写回，可以称之为五级指令流水线。CPU 可以在一个时钟周期内，同时运行五条指令的不同阶段（每个线程不同的阶段），本质上流水线技术并不能缩短单条指令的执行时间，但变相地提高了指令地吞吐率处理器在进行重排序时，必须要考虑指令之间的数据依赖性

单线程环境也存在指令重排，由于存在依赖性，最终执行结果和代码顺序的结果一致
多线程环境中线程交替执行，由于编译器优化重排，会获取其他线程处在不同阶段的指令同时执行补充知识：
指令周期是取出一条指令并执行这条指令的时间，一般由若干个机器周期组成
机器周期也称为 CPU 周期，一条指令的执行过程划分为若干个阶段（如取指、译码、执行等），每一阶段完成一个基本操作，完成一个基本操作所需要的时间称为机器周期
振荡周期指周期性信号作周期性重复变化的时间间隔

cache

缓存机制

缓存结构

在计算机系统中，CPU 高速缓存（CPU Cache，简称缓存）是用于减少处理器访问内存所需平均时间的部件；在存储体系中位于自顶向下的第二层，仅次于 CPU 寄存器；其容量远小于内存，但速度却可以接近处理器的频率 CPU 处理器速度远远大于在主内存中的，为了解决速度差异，在它们之间架设了多级缓存，如 L1、L2、L3 级别的缓存，这些缓存离 CPU 越近就越快，将频繁操作的数据缓存到这里，加快访问速度

| 从 CPU 到 | 大约需要的时钟周期 | | --------- | --------------------------------- | | 寄存器 | 1 cycle (4GHz 的 CPU 约为 0.25ns) | | L1 | 3~4 cycle | | L2 | 10~20 cycle | | L3 | 40~45 cycle | | 内存 | 120~240 cycle |

缓存使用

当处理器发出内存访问请求时，会先查看缓存内是否有请求数据，如果存在（命中），则不用访问内存直接返回该数据；如果不存在（失效），则要先把内存中的相应数据载入缓存，再将其返回处理器缓存之所以有效，主要因为程序运行时对内存的访问呈现局部性（Locality）特征。既包括空间局部性（Spatial Locality），也包括时间局部性（Temporal Locality），有效利用这种局部性，缓存可以达到极高的命中率

伪共享

缓存以缓存行 cache line 为单位，每个缓存行对应着一块内存，一般是 64 byte（8 个 long），在 CPU 从主存获取数据时，以 cache line 为单位加载，于是相邻的数据会一并加载到缓存中缓存会造成数据副本的产生，即同一份数据会缓存在不同核心的缓存行中，CPU 要保证数据的一致性，需要做到某个 CPU 核心更改了数据，其它 CPU 核心对应的整个缓存行必须失效，这就是伪共享

解决方法：

padding：通过填充，让数据落在不同的 cache line 中
@Contended：原理参考无锁 → Adder → 优化机制 → 伪共享 Linux 查看 CPU 缓存行：
命令：cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size64
内存地址格式：[高位组标记] [低位索引] [偏移量]

缓存一致

缓存一致性：当多个处理器运算任务都涉及到同一块主内存区域的时候，将可能导致各自的缓存数据不一样

MESI（Modified Exclusive Shared Or Invalid）是一种广泛使用的支持写回策略的缓存一致性协议，CPU 中每个缓存行（caceh line）使用 4 种状态进行标记（使用额外的两位 bit 表示)：

M：被修改（Modified）该缓存行只被缓存在该 CPU 的缓存中，并且是被修改过的，与主存中的数据不一致 (dirty)，该缓存行中的内存需要写回 (write back) 主存。该状态的数据再次被修改不会发送广播，因为其他核心的数据已经在第一次修改时失效一次当被写回主存之后，该缓存行的状态会变成独享 (exclusive) 状态
E：独享的（Exclusive）该缓存行只被缓存在该 CPU 的缓存中，是未被修改过的 (clear)，与主存中数据一致，修改数据不需要通知其他 CPU 核心，该状态可以在任何时刻有其它 CPU 读取该内存时变成共享状态 (shared) 当 CPU 修改该缓存行中内容时，该状态可以变成 Modified 状态
S：共享的（Shared）该状态意味着该缓存行可能被多个 CPU 缓存，并且各个缓存中的数据与主存数据一致，当 CPU 修改该缓存行中，会向其它 CPU 核心广播一个请求，使该缓存行变成无效状态 (Invalid)，然后再更新当前 Cache 里的数据
I：无效的（Invalid）该缓存是无效的，可能有其它 CPU 修改了该缓存行解决方法：各个处理器访问缓存时都遵循一些协议，在读写时要根据协议进行操作，协议主要有 MSI、MESI 等

处理机制

单核 CPU 处理器会自动保证基本内存操作的原子性多核 CPU 处理器，每个 CPU 处理器内维护了一块内存，每个内核内部维护着一块缓存，当多线程并发读写时，就会出现缓存数据不一致的情况。处理器提供：

总线锁定：当处理器要操作共享变量时，在 BUS 总线上发出一个 LOCK 信号，其他处理器就无法操作这个共享变量，该操作会导致大量阻塞，从而增加系统的性能开销（平台级别的加锁）
缓存锁定：当处理器对缓存中的共享变量进行了操作，其他处理器有嗅探机制，将各自缓存中的该共享变量的失效，读取时会重新从主内存中读取最新的数据，基于 MESI 缓存一致性协议来实现有如下两种情况处理器不会使用缓存锁定：
当操作的数据跨多个缓存行，或没被缓存在处理器内部，则处理器会使用总线锁定
有些处理器不支持缓存锁定，比如：Intel 486 和 Pentium 处理器也会调用总线锁定总线机制：
总线嗅探：每个处理器通过嗅探在总线上传播的数据来检查自己缓存值是否过期了，当处理器发现自己的缓存对应的内存地址的数据被修改，就将当前处理器的缓存行设置为无效状态，当处理器对这个数据进行操作时，会重新从内存中把数据读取到处理器缓存中
总线风暴：当某个 CPU 核心更新了 Cache 中的数据，要把该事件广播通知到其他核心（写传播），CPU 需要每时每刻监听总线上的一切活动，但是不管别的核心的 Cache 是否缓存相同的数据，都需要发出一个广播事件，不断的从主内存嗅探和 CAS 循环，无效的交互会导致总线带宽达到峰值；因此不要大量使用 volatile 关键字，使用 volatile、syschonized 都需要根据实际场景

volatile

同步机制

volatile 是 Java 虚拟机提供的轻量级的同步机制（三大特性）

保证可见性
不保证原子性
保证有序性（禁止指令重排）性能：volatile 修饰的变量进行读操作与普通变量几乎没什么差别，但是写操作相对慢一些，因为需要在本地代码中插入很多内存屏障来保证指令不会发生乱序执行，但是开销比锁要小 synchronized 无法禁止指令重排和处理器优化，为什么可以保证有序性可见性
加了锁之后，只能有一个线程获得到了锁，获得不到锁的线程就要阻塞，所以同一时间只有一个线程执行，相当于单线程，由于数据依赖性的存在，单线程的指令重排是没有问题的
线程加锁前，将清空工作内存中共享变量的值，使用共享变量时需要从主内存中重新读取最新的值；线程解锁前，必须把共享变量的最新值刷新到主内存中（JMM 内存交互章节有讲）

指令重排

volatile 修饰的变量，可以禁用指令重排指令重排实例：

example 1：

public void mySort() {int x = 11;	//语句1int y = 12;	//语句2  谁先执行效果一样x = x + 5;	//语句3y = x * x;	//语句4
}

执行顺序是：1 2 3 4、2 1 3 4、1 3 2 4 指令重排也有限制不会出现：4321，语句 4 需要依赖于 y 以及 x 的申明，因为存在数据依赖，无法首先执行

example 2：

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;
}

情况一：线程 1 先执行，ready = false，结果为 r.r1 = 1 情况二：线程 2 先执行 num = 2，但还没执行 ready = true，线程 1 执行，结果为 r.r1 = 1 情况三：线程 2 先执行 ready = true，线程 1 执行，进入 if 分支结果为 r.r1 = 4 情况四：线程 2 执行 ready = true，切换到线程 1，进入 if 分支为 r.r1 = 0，再切回线程 2 执行 num = 2，发生指令重排

底层原理

缓存一致

使用 volatile 修饰的共享变量，底层通过汇编 lock 前缀指令进行缓存锁定，在线程修改完共享变量后写回主存，其他的 CPU 核心上运行的线程通过 CPU 总线嗅探机制会修改其共享变量为失效状态，读取时会重新从主内存中读取最新的数据 lock 前缀指令就相当于内存屏障，Memory Barrier（Memory Fence）

对 volatile 变量的写指令后会加入写屏障
对 volatile 变量的读指令前会加入读屏障内存屏障有三个作用：
确保对内存的读-改-写操作原子执行
阻止屏障两侧的指令重排序
强制把缓存中的脏数据写回主内存，让缓存行中相应的数据失效

内存屏障

保证可见性：

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

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

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

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

全能屏障：mfence（modify/mix Barrier），兼具 sfence 和 lfence 的功能保证有序性：
写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前不能解决指令交错：
写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证其他线程的读跑到写屏障之前
有序性的保证也只是保证了本线程内相关代码不被重排序

volatile i = 0;
new Thread(() -> {i++});
new Thread(() -> {i--});

i++ 反编译后的指令：

0: iconst_1			// 当int取值 -1~5 时，JVM采用iconst指令将常量压入栈中
1: istore_1			// 将操作数栈顶数据弹出，存入局部变量表的 slot 1
2: iinc		1, 1

交互规则

对于 volatile 修饰的变量：

线程对变量的 use 与 load、read 操作是相关联的，所以变量使用前必须先从主存加载
线程对变量的 assign 与 store、write 操作是相关联的，所以变量使用后必须同步至主存
线程 1 和线程 2 谁先对变量执行 read 操作，就会先进行 write 操作，防止指令重排

双端检锁

检锁机制

Double-Checked Locking：双端检锁机制 DCL（双端检锁）机制不一定是线程安全的，原因是有指令重排的存在，加入 volatile 可以禁止指令重排

public final class Singleton {private Singleton() { }private static Singleton INSTANCE = null;public static Singleton getInstance() {if(INSTANCE == null) { // t2，这里的判断不是线程安全的// 首次访问会同步，而之后的使用没有 synchronizedsynchronized(Singleton.class) {// 这里是线程安全的判断，防止其他线程在当前线程等待锁的期间完成了初始化if (INSTANCE == null) { INSTANCE = new Singleton();}}}return INSTANCE;}
}

不锁 INSTANCE 的原因：

INSTANCE 要重新赋值
INSTANCE 是 null，线程加锁之前需要获取对象的引用，设置对象头，null 没有引用实现特点：
懒惰初始化
首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁
第一个 if 使用了 INSTANCE 变量，是在同步块之外，但在多线程环境下会产生问题

DCL问题

getInstance 方法对应的字节码为：

0: 	getstatic 		#2 		// Field INSTANCE:Ltest/Singleton;
3: 	ifnonnull 		37
6: 	ldc 			#3 		// class test/Singleton
8: 	dup
9: 	astore_0
10: monitorenter
11: getstatic 		#2 		// Field INSTANCE:Ltest/Singleton;
14: ifnonnull 27
17: new 			#3 		// class test/Singleton
20: dup
21: invokespecial 	#4 		// Method "<init>":()V
24: putstatic 		#2 		// Field INSTANCE:Ltest/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:Ltest/Singleton;
40: areturn

17 表示创建对象，将对象引用入栈
20 表示复制一份对象引用，引用地址
21 表示利用一个对象引用，调用构造方法初始化对象
24 表示利用一个对象引用，赋值给 static INSTANCE 步骤 21 和 24 之间不存在数据依赖关系，而且无论重排前后，程序的执行结果在单线程中并没有改变，因此这种重排优化是允许的
关键在于 0:getstatic 这行代码在 monitor 控制之外，可以越过 monitor 读取 INSTANCE 变量的值
当其他线程访问 INSTANCE 不为 null 时，由于 INSTANCE 实例未必已初始化，那么 t2 拿到的是将是一个未初始化完毕的单例返回，这就造成了线程安全的问题

解决方法

指令重排只会保证串行语义的执行一致性（单线程），但并不会关系多线程间的语义一致性引入 volatile，来保证出现指令重排的问题，从而保证单例模式的线程安全性：

private static volatile SingletonDemo INSTANCE = null;

ha-be

happens-before 先行发生 Java 内存模型具备一些先天的“有序性”，即不需要通过任何同步手段（volatile、synchronized 等）就能够得到保证的安全，这个通常也称为 happens-before 原则，它是可见性与有序性的一套规则总结不符合 happens-before 规则，JMM 并不能保证一个线程的可见性和有序性

程序次序规则 (Program Order Rule)：一个线程内，逻辑上书写在前面的操作先行发生于书写在后面的操作，因为多个操作之间有先后依赖关系，则不允许对这些操作进行重排序
锁定规则 (Monitor Lock Rule)：一个 unlock 操作先行发生于后面（时间的先后）对同一个锁的 lock 操作，所以线程解锁 m 之前对变量的写（解锁前会刷新到主内存中），对于接下来对 m 加锁的其它线程对该变量的读可见
volatile 变量规则 (Volatile Variable Rule)：对 volatile 变量的写操作先行发生于后面对这个变量的读
传递规则 (Transitivity)：具有传递性，如果操作 A 先行发生于操作 B，而操作 B 又先行发生于操作 C，则可以得出操作 A 先行发生于操作 C
线程启动规则 (Thread Start Rule)：Thread 对象的 start()方法先行发生于此线程中的每一个操作

static int x = 10;//线程 start 前对变量的写，对该线程开始后对该变量的读可见
new Thread(()->{	System.out.println(x);	},"t1").start();

线程中断规则 (Thread Interruption Rule)：对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生
线程终止规则 (Thread Termination Rule)：线程中所有的操作都先行发生于线程的终止检测，可以通过 Thread.join() 方法结束、Thread.isAlive() 的返回值手段检测到线程已经终止执行
对象终结规则（Finaizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的 finalize() 方法的开始

设计模式

终止模式

终止模式之两阶段终止模式：停止标记用 volatile 是为了保证该变量在多个线程之间的可见性

class TwoPhaseTermination {// 监控线程private Thread monitor;// 停止标记private volatile boolean stop = false;;// 启动监控线程public void start() {monitor = new Thread(() -> {while (true) {Thread thread = Thread.currentThread();if (stop) {System.out.println("后置处理");break;}try {Thread.sleep(1000);// 睡眠System.out.println(thread.getName() + "执行监控记录");} catch (InterruptedException e) {System.out.println("被打断，退出睡眠");}}});monitor.start();}// 停止监控线程public void stop() {stop = true;monitor.interrupt();// 让线程尽快退出Timed Waiting}
}
// 测试
public static void main(String[] args) throws InterruptedException {TwoPhaseTermination tpt = new TwoPhaseTermination();tpt.start();Thread.sleep(3500);System.out.println("停止监控");tpt.stop();
}

Balking

Balking （犹豫）模式用在一个线程发现另一个线程或本线程已经做了某一件相同的事，那么本线程就无需再做了，直接结束返回

public class MonitorService {// 用来表示是否已经有线程已经在执行启动了private volatile boolean starting = false;public void start() {System.out.println("尝试启动监控线程...");synchronized (this) {if (starting) {return;}starting = true;}// 真正启动监控线程...}
}

对比保护性暂停模式：保护性暂停模式用在一个线程等待另一个线程的执行结果，当条件不满足时线程等待例子：希望 doInit() 方法仅被调用一次，下面的实现出现的问题：

当 t1 线程进入 init() 准备 doInit()，t2 线程进来，initialized 还为f alse，则 t2 就又初始化一次
volatile 适合一个线程写，其他线程读的情况，这个代码需要加锁

public class TestVolatile {volatile boolean initialized = false;void init() {if (initialized) {return;}doInit();initialized = true;}private void doInit() {}
}