B站黑马课程

文章目录

• 4. AQS
• • 4.1 锁的活跃性
  • • 死锁
    • 哲学家就餐问题
    • 活锁
    • 饥饿
  • 4.2 AQS
  • 4.3 ReentrantLock
  • • ReentrantLock原理
    • ReentrantLock基础
    • ReentrantLock解决哲学家就餐
  • 4.4 同步模式之顺序控制
  • • 固定顺序
    • *交替输出
• 5. 共享模式之内存
• • 5.1 可见性
  • • volatile
    • 可见性 vs 原子性
  • 5.2 终止模式之两阶段终止模式
  • 5.3 同步模式之犹豫模式
  • 5.4 有序性
  • • 指令重排序优化
  • 5.5 volatile原理
  • • 保障可见性
    • 保障有序性
  • 5.6 double-checked locking 问题
  • 5.7 happens-before
  • 5.8 习题
  • • balking 模式习题
    • 线程安全单例习题
    • • 实现1
      • 实现2
      • 实现3
      • 实现4
      • 实现5

4. AQS

只使用一把锁时，锁住整个对象

class BigRoom {public void sleep() {synchronized (this) {log.debug("sleeping 2 小时");Sleeper.sleep(2);}}public void study() {synchronized (this) {log.debug("study 1 小时");Sleeper.sleep(1);}}
}

可以设置多把细粒度锁，提高并发度，潜在风险是死锁

class BigRoom {private final Object studyRoom = new Object();private final Object bedRoom = new Object();public void sleep() {(bedRoom) {log.debug("sleeping 2 小时");Sleeper.sleep(2);}}public void study() {synchronized (studyRoom) {log.debug("study 1 小时");Sleeper.sleep(1);}}
}

4.1 锁的活跃性

死锁

示例

t1 线程获得 A对象 锁，接下来想获取 B对象的锁
t2 线程获得 B对象 锁，接下来想获取 A对象的锁

定位死锁

检测死锁可以使用 jconsole工具，或者使用 jps 定位进程 id，再用 jstack 定位死锁

jps	#查看java线程id
jstack 34628	#查看指定id的线程

最终观察其中有如下内容

"t2" #23 prio=5 os_prio=0 tid=0x0000016d4ec3b000 nid=0x5bb0 waiting for monitor entry [0x0000000decffe000]java.lang.Thread.State: BLOCKED (on object monitor)at com.example.ConcurrentApplication.lambda$main$1(ConcurrentApplication.java:33)- waiting to lock <0x000000076ff202f0> (a java.lang.Object)- locked <0x000000076ff20300> (a java.lang.Object)at com.example.ConcurrentApplication$$Lambda$4/1590550415.run(Unknown Source)at java.lang.Thread.run(Thread.java:748)"t1" #22 prio=5 os_prio=0 tid=0x0000016d4ec3a000 nid=0x87a4 waiting for monitor entry [0x0000000deceff000]java.lang.Thread.State: BLOCKED (on object monitor)at com.example.ConcurrentApplication.lambda$main$0(ConcurrentApplication.java:23)- waiting to lock <0x000000076ff20300> (a java.lang.Object)- locked <0x000000076ff202f0> (a java.lang.Object)at com.example.ConcurrentApplication$$Lambda$3/392292416.run(Unknown Source)at java.lang.Thread.run(Thread.java:748)
..."t2":at com.example.ConcurrentApplication.lambda$main$0(ConcurrentApplication.java:23)- waiting to lock <0x000000076ff20300> (a java.lang.Object)- locked <0x000000076ff202f0> (a java.lang.Object)at com.example.ConcurrentApplication$$Lambda$3/392292416.run(Unknown Source)at java.lang.Thread.run(Thread.java:748)Found 1 deadlock.

解决方法之一：顺序加锁

哲学家就餐问题

演示

class Chopstick {String name;public Chopstick(String name) {this.name = name;}@Overridepublic String toString() {return "筷子{" + name + '}';}
}
class Philosopher extends Thread {Chopstick left;Chopstick right;public Philosopher(String name, Chopstick left, Chopstick right) {super(name);this.left = left;this.right = right;}private void eat() {log.debug("eating...");Sleeper.sleep(1);}@Overridepublic void run() {while (true) {// 获得左手筷子synchronized (left) {// 获得右手筷子synchronized (right) {// 吃饭eat();}// 放下右手筷子}// 放下左手筷子}}
}
Chopstick c1 = new Chopstick("1");
Chopstick c2 = new Chopstick("2");
Chopstick c3 = new Chopstick("3");
Chopstick c4 = new Chopstick("4");
Chopstick c5 = new Chopstick("5");
new Philosopher("苏格拉底", c1, c2).start();
new Philosopher("柏拉图", c2, c3).start();
new Philosopher("亚里士多德", c3, c4).start();
new Philosopher("赫拉克利特", c4, c5).start();
new Philosopher("阿基米德", c5, c1).start();

活锁

活锁出现在两个线程互相改变对方的结束条件，最后谁也无法结束

演示

public 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) {sleep(0.2);count--;log.debug("count: {}", count);}}, "t1").start();new Thread(() -> {// 期望超过 20 退出循环while (count < 20) {sleep(0.2);count++;log.debug("count: {}", count);}}, "t2").start();}
}

饥饿

常定义为，一个线程由于优先级太低，始终得不到 CPU 调度执行，也不能够结束

4.2 AQS

源码没看明白，总结一下大概流程

• AQS 就是一个抽象类，可用来在多线程环境下构建锁，比如ReentranctLock就是基于它的独占锁。我对它的了解不是非常深入，只能大概说一下。它有两个非常重要的组件，一个表示锁状态的state，在构建锁时可以根据自己的需要定义state的含义，比如ReentrantLock里面就是state=0时表示没有加锁，state=1表示加锁，state>1表示被冲入了。另外一个重要组件就是一个双向队列，用来存储等待锁的线程。当第一个线程来获取锁时，非公平条件下它会尝试通过CAS操作去改变state的值，如果成功说明锁空闲，失败就以CAS操作加入到队列的尾部，等待它的前一个线程结点来唤醒它。

• AQS可以实现独享锁和共享锁。比如ReentrantLock就是独占锁，它又可以分为公平锁和非公平锁，公平锁按照队列的顺序获取锁，非公平锁就是当新的线程来到时，它先去尝试获取一下，获取不到再入队。共享锁有countDownLatch之类的，会定义一个初始计数器，表示可共享的个数，具体不是很了解

4.3 ReentrantLock

ReentrantLock主要基于CAS和AQS实现,支持公平锁和非公平锁

ReentrantLock原理

ReentrantLock 类内部总共存在Sync、NonfairSync、FairSync三个类，NonfairSync与 FairSync类继承自 Sync类，Sync类继承自 AbstractQueuedSynchronizer (AQS) 抽象类

详见：https://blog.csdn.net/weixin_42039228/article/details/123135122

ReentrantLock基础

基本语法

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

相对于 synchronized 它具备如下特点

• 可中断

  • synchronized是不可中断的，也就是说锁除了自身放弃，是不能被其他线程夺走的

  private static ReentrantLock lock = new ReentrantLock();
  try {//如果没有竞争那么此方法就会获取lock对象锁//如果有竞争就进入阻塞队列，可以被其他线程使用 interrupt 方法打断lock.lockInterruptibly();
  } catch (InterruptedException e) {e.printStackTrace();return;
  }
  

• 可以设置超时时间

  tryLock：在规定时间内获取锁

  private static ReentrantLock lock = new ReentrantLock();
  public static void main(String[] agrs) {Thread t1 = new Thread(()->{log.debug("尝试获取锁");try {//tryLock()无参表示获取一次if(!lock.tryLock(2, TimeUnit.SECONDS)) {//在2秒内尝试获取锁log.debug("获取锁失败");return;}} catch (InterruptedException e) {e.printStackTrace();}try{//临界区log.debug("获取锁成功");}finally{lock.unlock();}}, "t1");lock.lock();t1.start();sleep(1);lock.unlock();
  }
  

• 可以设置为公平锁

  • 很少设置，因为会降低并发度

• 支持多个条件变量 (await / signal)

  • synchronized 中也有条件变量，当条件不满足时进入 waitSet 等待
    ReentrantLock 的条件变量比 synchronized 强大之处在于，它是支持多个条件变量的

    static ReentrantLock lock = new ReentrantLock();
    public static void main(String[] agrs) {//创建一个新的条件变量Condition condition1 = lock.newCondition();Condition condition2 = lock.newCondition();lock.lock();//先加锁//进入条件变量condition1中等待condition1.await();//叫醒阻塞在condition1中的线程condition1.signal();
    }
    

  • 使用要点

    • await 前需要获得锁
    • await 执行后，会释放锁，进入 conditionObject 等待
    • await 的线程被唤醒（或打断、或超时）后重新竞争 lock 锁
    • 竞争 lock 锁成功后，从 await 后继续执行

ReentrantLock 与 synchronized 一样，都支持可重入

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

ReentrantLock解决哲学家就餐

使用tryLock()，先获取左筷子，再获取右筷子。如果右筷子获取失败，会释放左筷子

package com.example;@Slf4j(topic = "c.Test")
public class ConcurrentApplication{public static void main(String[] agrs) {Chopstick c1 = new Chopstick("1");Chopstick c2 = new Chopstick("2");Chopstick c3 = new Chopstick("3");Chopstick c4 = new Chopstick("4");Chopstick c5 = new Chopstick("5");new Philosopher("苏格拉底", c1, c2).start();new Philosopher("柏拉图", c2, c3).start();new Philosopher("亚里士多德", c3, c4).start();new Philosopher("赫拉克利特", c4, c5).start();new Philosopher("阿基米德", c5, c1).start();}
}class Chopstick extends ReentrantLock{String name;public Chopstick(String name){this.name=name;}@Overridepublic String toString() {return "筷子{" + name + '}';}
}@Slf4j(topic = "c.Philosopher")
class Philosopher extends Thread{Chopstick left;Chopstick right;public Philosopher(String name, Chopstick left, Chopstick right){super(name);this.left=left; this.right=right;}private void eat(){log.debug("eating ...");try {Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}}@Overridepublic void run() {while(true){if(left.tryLock()){try{if(right.tryLock()){eat();right.unlock();}}finally {left.unlock();}}}}
}

4.4 同步模式之顺序控制

固定顺序

需求：要求先运行线程2，再运行线程1

1. wait/notify方案

static final Object lock = new Object();
static boolean t2runned = false;//判断t2是否运行过public static void main(String[] agrs) {Thread t1 = new Thread(() -> {synchronized (lock){while(!t2runned){try{lock.wait();}catch (InterruptedException e){e.printStackTrace();}}log.debug("1");}}, "t1");Thread t2 = new Thread(() -> {synchronized (lock){log.debug("2");t2runned = true;lock.notify();}}, "t2");t1.start();t2.start();
}

2. pack/unpack方案

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

*交替输出

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

1. wait/notify方案

• 使用一个整型变量 flag 标识当前该谁执行了

@Slf4j(topic = "c.Test")
public class ConcurrentApplication {public static void main(String[] agrs) {WaitNotify waitNotify = new WaitNotify(1, 5);new Thread(() -> {waitNotify.print("a", 1, 2);}, "t1").start();new Thread(() -> {waitNotify.print("b", 2, 3);}, "t2").start();new Thread(() -> {waitNotify.print("c", 3, 1);}, "t3").start();}
}class WaitNotify{private int flag;//等待标记，1，2，3表示不同线程private int loopNumber;//循环次数public WaitNotify(int flag, int loopNumber) {this.flag = flag;this.loopNumber = loopNumber;}public void print(String str, int waitFlag, int nextFlag){for(int i=0; isynchronized (this){while (flag != waitFlag){try {this.wait();} catch (InterruptedException e) {e.printStackTrace();}}System.out.print(str);flag = nextFlag;this.notifyAll();}}}
}

2. await/signal方案

@Slf4j(topic = "c.Test")
public class ConcurrentApplication {public static void main(String[] agrs) {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);}, "t2").start();new Thread(() ->{awaitSignal.print("c", c, a);}, "t3").start();Thread.sleep(1000);awaitSignal.lock();try{System.out.println("开始！");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 current, Condition next){for(int i=0; ilock();try{current.await();System.out.print(str);next.signal();}catch (InterruptedException e){e.printStackTrace();}finally {unlock();}}}
}

3. park/unpark方案

@Slf4j(topic = "c.Test")
public class ConcurrentApplication {static Thread t1, t2, t3;public static void main(String[] agrs) {ParkUnpack pu = new ParkUnpack(5);t1 = new Thread(() ->{pu.print("a", t2);}, "t1");t2 = new Thread(() ->{pu.print("b", t3);}, "t2");t3 = new Thread(() ->{pu.print("c", t1);}, "t3");t1.start();t2.start();t3.start();LockSupport.unpark(t1);}
}class ParkUnpack{private int loopNumber;public ParkUnpack(int loopNumber){this.loopNumber = loopNumber;}public void print(String str, Thread next){for (int i=0; iLockSupport.park();System.out.print(str);LockSupport.unpark(next);}}
}

5. 共享模式之内存

Monitor 主要关注的是访问共享变量时，保证临界区代码的原子性
除此之外，共享变量还有可见性和有序性的问题

JMM（Java Memory Model，Java内存模型） 体现在以下几个方面

• 原子性 - 保证指令不会受到线程上下文切换的影响
• 可见性 - 保证指令不会受 cpu 缓存的影响
• 有序性 - 保证指令不会受 cpu 指令并行优化的影响

重点注意

JVM内存模型和Java内存模型是不一样的

• Java内存模型
  • 规定所有的变量都是存在主存中，每个线程都有自己的工作内存
  • 线程堆变量的操作都必须在工作内存进行，不能直接堆主存进行操作，并且每个线程不能访问其他线程的工作内存
  • Java内存模型重点在，Volatile`关键字，原子性、可见性、有序性
• JVM内存模型
  • 和Java虚拟机的运行时区域有关

5.1 可见性

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不会如预想的停下来
}

JVM优化时，会将循环超过1w次的代码作为热点代码
JVM会把热点代码的字节码编译成机器码放到方法区,下次执行时直接执行对应的机器码来提高执行效率
因此这里修改为false无用

在while中加入 log.debug(“d”); 即可停止下来
另外：println是synchronized修饰的

可见性的产生原因

• t 线程频繁从主内存中读取 run 的值，JIT 编译器于是将 run 值缓存至自己工作内存（CPU缓存）中的高速缓存中，以提高效率
• main修改了主存中的 run 值，然而t线程不去主存中读取，因此感知不到 run 值的修改

解决方案：volatile

volatile

volatile static boolean run = true

可以用来修饰成员变量和静态成员变量，避免线程从自己的工作缓存中查找变量的值，强制到主存中获取它的值

• 加锁synchronized也可以避免可见性的问题

  static boolean run = true;
  final static Object lock = new Object();
  public static void main(String[] args) throws InterruptedException {Thread t = new Thread(()->{while(true){synchronized (lock){if(!run){break;}}}});t.start();sleep(1);synchronized (lock){run = false;}
  }
  

可见性 vs 原子性

• violate只保证可见性，并不保证原子性

• synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性
  但缺点是synchronized 是属于重量级操作，性能相对更低

5.2 终止模式之两阶段终止模式

之前的两阶段终止模式是通过 interrupt 实现的
这里使用violate改进

@Slf4j(topic = "c.test")
public class ConcurrentApplication {public static void main(String[] args) throws InterruptedException {TwoPhaseTermination tpt = new TwoPhaseTermination();tpt.start();Thread.sleep(3500);tpt.stop();}
}@Slf4j(topic = "c.TwoPhaseTermination")
class TwoPhaseTermination {private Thread monitor;private volatile boolean stop = false;public void start(){monitor = new Thread(()->{while(true){Thread current = Thread.currentThread();if(stop){log.debug("料理后事");break;}try {Thread.sleep(1000);//如果在这里sleep被打断，将进入catch里面log.debug("执行监控记录");}catch (InterruptedException e){}}});monitor.start();}public void stop(){stop = true;monitor.interrupt();//使得stop后立即停止}
}

5.3 同步模式之犹豫模式

Balking （犹豫）模式

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

上面监控线程存在的问题：如果创建2个监控线程，那么这两个线程将在同时刻打印监控信息，导致重复
需求：使得监控方法 start() 只执行一次

@Slf4j(topic = "c.test")
public class ConcurrentApplication {public static void main(String[] args) throws InterruptedException {TwoPhaseTermination tpt = new TwoPhaseTermination();tpt.start();tpt.start();}
}@Slf4j(topic = "c.TwoPhaseTermination")
class TwoPhaseTermination {private Thread monitor;private volatile boolean stop = false;//判断是否执行过 start()private boolean starting = false;public void start(){//犹豫模式：Balkingsynchronized (this){if(starting) return;starting = true;}monitor = new Thread(()->{...});monitor.start();}public void stop(){stop = true;monitor.interrupt();//使得stop后立即停止}
}

常用在web开发中，这样前端即便点击多次start按钮，也能保证仅有一个监控程序

此外还可以用在实现单例模式

public final class Singleton {private Singleton() {}private static Singleton INSTANCE = null;public static synchronized Singleton getInstance() {if (INSTANCE != null) {return INSTANCE;}INSTANCE = new Singleton();return INSTANCE;}
}

5.4 有序性

指令重排序优化

指令重排：JVM 会在不影响正确性的前提下，调整语句的执行顺序

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

此时无论是先执行 i 还是先执行 j，对结果没有影响
这种情况下，JVM可能对上面代码的执行顺序进行重排

指令重排的原因和原理

• 现代处理器会设计为一个时钟周期完成一条执行时间最长的 CPU 指令

• 每条指令都可以分为： 取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回 这 5 个阶段

  

• 在不改变程序结果的前提下，这些指令的各个阶段可以通过重排序和组合来实现指令级并行

  

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

指令重排举例

int num = 0;
boolean ready = false;
// 线程1 执行此方法
public void actor1(I_Result r) {if(ready) {r.r1 = num + num;//r是一个只有r1成员变量的对象} else {r.r1 = 1;}
}
// 线程2 执行此方法
public void actor2(I_Result r) {num = 2;ready = true;
}

问：最终 r1 的结果为多少？这里分析一种奇怪的结果

• r1 = 0

  线程2中进行指令重排，使得 ready = true 在 num = 2 之前执行，就会导致 r1 = 0

禁止指令重排 - volatile

volatile boolean ready = false;

5.5 volatile原理

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

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

保障可见性

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

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

保障有序性

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

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

5.6 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// 首次访问会同步，而之后的使用没有 synchronizedsynchronized(Singleton.class) {if (INSTANCE == null) { // t1INSTANCE = new Singleton();}}}return INSTANCE;}
}

以上的实现特点是：

• 懒惰实例化
• 首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁

问题：第一次 if(INSTANCE == null) 在 synchronized 之外，有指令重排的危险性

原理：

0: getstatic 		#2 				// 获得静态变量INSTANCE
3: ifnonnull 		37				// 判断是否null，不为null，跳转到37行
6: ldc		 		#3 				// 获取类对象Singleton.class
8: dup								// 复制引用地址
9: astore_0							// 将复制的引用地址存入寄存器
10: monitorenter					// 进入同步代码块
11: getstatic 		#2			 	// 获得静态变量INSTANCE
14: ifnonnull 27					// 判断是否null，不为null，跳转到27行（拿出类对象，用于解锁）
17: new 			#3				// new Singleton();
20: dup								// 复制一份新创建对象的地址
21: invokespecial 	#4 				// 调用构造方法
24: putstatic 		#2 				// 将创建的对象赋值给静态变量
27: aload_0							// 类对象解锁
28: monitorexit
29: goto 			37
32: astore_1
33: aload_0
34: monitorexit
35: aload_1
36: athrow
37: getstatic 		#2
40: areturn

其中

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

也许 jvm 会优化为：先执行 24，再执行 21，即先赋值再构造。此时可能出现
线程t1执行同步代码块，线程t2在INSTANCE未被构造的情况下获取到了它，然后正常使用。结果是使用了一个未构造的对象，导致报错

synchronized保护的共享变量是可以保障原子性、可见性、有序性的，但是这里的INSTANCE因为有部分在synchronized之外，因此可能出问题

解决方案

private static volatile Singleton INSTANCE = null;

是通过读写屏障阻止了重排序而实现的

5.7 happens-before

参考：https://www.jianshu.com/p/b9186dbebe8e

happens-before原则

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

如何判断是否为 happens-before？

• 线程解锁 lock 之前对变量的写，对于接下来对 lock 加锁的其它线程的读可见
• 线程对 volatile 变量的写，对接下来其它线程对该变量的读可见
• 线程 start 前对变量的写，对该线程开始后对该变量的读可见
• 线程结束前对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或 t1.join()等待
  它结束）
• 线程 t1 打断 t2（interrupt）前对变量的写，在打断之后对其他线程读可见（通过t2.interrupted 或 t2.isInterrupted）
• 对变量默认值（0，false，null）的写，对其它线程对该变量的读可见
• 具有传递性，如果 x -> y 并且 y -> z 那么有 x -> z ，

5.8 习题

balking 模式习题

希望 doInit() 方法仅被调用一次，下面的实现是否有问题，为什么？

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

有问题：只能保障可见性，不能保障原子性，可以改用synchronized

线程安全单例习题

实现1

饿汉式：类加载就会导致该单实例对象被创建
懒汉式：类加载不会导致该单实例对象被创建，而是首次使用该对象时才会创建

public final class Singleton implements Serializable {private Singleton() {}private static final Singleton INSTANCE = new Singleton(); public static Singleton getInstance() {return INSTANCE;}public Object readResolve() {return INSTANCE;}
}

问题1：类为什么加 final？

• 表明此类不能被继承，可以防止子类重写其中的方法导致单例被破坏

问题2：如果实现了序列化接口（implements Serializable）, 还要做什么来防止反序列化破坏单例？

关于序列化和反序列化：https://zhuanlan.zhihu.com/p/340258358

• 增加 readResovle() 方法

  //固定名称的方法，在反序列化中如果发现readResolve()返回了一个对象，就会使用这个对象，而非反序列化后生成的对象
  public Object readResolve(){return INSTANCE;
  }
  

问题3：构造方法为什么设置为私有? 是否能防止反射创建新的实例?

• 防止对象创建破坏单例；
• 不能，反射可以获取Constructor，通过set方法暴力修改

问题4：这里INSTANCE的初始化是否能保证单例对象创建时的线程安全?

• 是线程安全的
• 静态变量是在类加载阶段初始化的，类加载阶段会由JVM保障线程安全

问题5：为什么提供静态方法getInstance而不是直接将 INSTANCE 设置为 public, 说出你知道的理由

• 方法可以提供更好的封装性
• 可以实现一些懒惰的初始化，有更多的控制
• 可以提供一些泛型的支持

实现2

枚举方式实现的单例

enum Singleton {INSTANCE;
}

问题1：枚举单例是如何限制实例个数的

• 反编译后可以看到，实际上INSTANCE也是一个 public final static 类型，是单实例的

问题2：枚举单例在创建时是否有并发问题

• 无并发问题。同样由于是静态变量，会在初始化时由JVM保障线程安全性

问题3：枚举单例能否被反射破坏单例

• 不能

问题4：枚举单例能否被反序列化破坏单例

• 不能。默认继承了Serializable接口，在实现时考虑到了这个问题，做了相应措施

问题5：枚举单例属于懒汉式还是饿汉式

• 饿汉式

问题6：枚举单例如果希望加入一些单例创建时的初始化逻辑该如何做

• 编写一个构造方法

实现3

懒汉式的单例

public final class Singleton {private Singleton() { }private static Singleton INSTANCE = null;public static synchronized Singleton getInstance() {if( INSTANCE != null ){return INSTANCE;}INSTANCE = new Singleton();return INSTANCE;}
}

注意 synchronized 不要加在 INSTANCE 上，一个是因为它是null，另外synchronized需要加在不变的对象上，即final

分析这里的线程安全, 并说明有什么缺点

• 锁范围大，性能低

实现4

DCL

public final class Singleton {private Singleton() { }private static volatile Singleton INSTANCE = null;public static Singleton getInstance() {if (INSTANCE != null) {return INSTANCE;}synchronized (Singleton.class) {if (INSTANCE != null) {return INSTANCE;}INSTANCE = new Singleton();return INSTANCE;}}
}

问题1：解释为什么要加 volatile ?

• 防止重排序

问题2：对比实现3, 实现4的写法的意义

• 性能更优，非第一次调用可直接返回

问题3：为什么要第二次加空判断, 之前不是判断过了吗

• 首次创建对象时，两个线程同时锁住了Singleton.class，不加第二次判断就可能创建多个INSTANCE

实现5

public final class Singleton {private Singleton() { }private static class LazyHolder {static final Singleton INSTANCE = new Singleton();}public static Singleton getInstance() {return LazyHolder.INSTANCE;}
}

问题：属于懒汉式还是饿汉式

• 懒汉式。类加载本身就是懒惰的，如果不调用 getInstance()，是不会触发静态内部类的

问题：在创建时是否有并发问题

• 无并发问题，JVM保障了其线程安全