- 1. 原子性
- 1.1 原子性
- 1.2 问题分析
- 1.3 解决方法
- 2. 可见性
- 2.1 退不出的循环
- 2.2 解决方法
- 2.3 可见性
- 3. 有序性
- 3.1 诡异的结果
- 3.2 解决方法
- 3.3 有序性理解
- 3.4 happens-before
- 4. CAS与原子类
- 4.1 CAS
- 4.2 乐观锁和悲观锁
- 4.3 原子操作类
很多人将【java 内存结构】与【java 内存模型】傻傻分不清，【java 内存模型】是 Java Memory Model（JMM）的意思。
关于它的权威解释，请参考 https://download.oracle.com/otn-pub/jcp/memory_model-1.0-pfd-spec-oth-JSpec/memory_model-1_0-pfd-spec.pdf?AuthParam=1562811549_4d4994cbd5b59d964cd2907ea22ca08b
简单的说，JMM 定义了一套在多线程读写共享数据时（成员变量、数组）时，对数据的可见性、有序性、和原子性的规则和保障
1.1 原子性原子性在学习线程时讲过，下面来个例子简单回顾一下：
问题提出，两个线程对初始值为 0 的静态变量一个做自增，一个做自减，各做 5000 次，结果是 0 吗？
1.2 问题分析以上的结果可能是正数、负数、零。为什么呢？因为 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
此处是静态变量，与局部变量区分开
局部变量i++是在槽位上直接自增
静态变量i++，是getstatic加载到操作数栈中，然后iadd做加法加上iconst_1常量1
不同的线程在自己的操作数栈中进行操作
如果是单线程以下 8 行代码是顺序执行（不会交错）没有问题：
// 假设i的初始值为0 getstatic i // 线程1-获取静态变量i的值 线程内i=0 iconst_1 // 线程1-准备常量1 iadd // 线程1-自增 线程内i=1 putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=1 getstatic i // 线程1-获取静态变量i的值 线程内i=1 iconst_1 // 线程1-准备常量1 isub // 线程1-自减 线程内i=0 putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=0
但多线程下这 8 行代码可能交错运行（为什么会交错？思考一下）：
因为并发操作中，不同的线程是抢占cpu运行，cpu运行有时间片，时间片一到，就该切换线程，然后所有线程又来抢占cpu的时间片，也有可能同一个线程多次抢到。
出现负数的情况：
// 假设i的初始值为0 getstatic i // 线程1-获取静态变量i的值 线程内i=0 getstatic i // 线程2-获取静态变量i的值 线程内i=0 iconst_1 // 线程1-准备常量1 iadd // 线程1-自增 线程内i=1 putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=1 iconst_1 // 线程2-准备常量1 isub // 线程2-自减 线程内i=-1 putstatic i // 线程2-将修改后的值存入静态变量i 静态变量i=-1
出现正数的情况：
// 假设i的初始值为0 getstatic i // 线程1-获取静态变量i的值 线程内i=0 getstatic i // 线程2-获取静态变量i的值 线程内i=0 iconst_1 // 线程1-准备常量1 iadd // 线程1-自增 线程内i=1 iconst_1 // 线程2-准备常量1 isub // 线程2-自减 线程内i=-1 putstatic i // 线程2-将修改后的值存入静态变量i 静态变量i=-1 putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=1
1.3 解决方法不同的线程在自己的操作数栈中操作，操作完后，把结果存入主内存。对于其他线程的操作，本线程是不知道的。同时读入0，我加1，你减1，我在进行加操作时的时候，我是不知道你已经把i变成-1并且放到主内存中了。我只会把i变成1，然后放入主内存中，然后覆盖你。
synchronized （同步关键字）
语法
synchronized( 对象 ) {
要作为原子操作代码
}
用 synchronized 解决并发问题：
static int i = 0;
static Object obj = new Object();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
for (int j = 0; j <= 5000; j++) {
synchronized (obj) {
i++;
}
}
});
Thread t2 = new Thread(() -> {
// 推荐把synchronized写在for外层，这样加锁解锁只会执行一次
synchronized (obj) {
for (int j = 0; j <= 5000; j++) {
i--;
}
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(i);
}
如何理解呢：你可以把 obj 想象成一个房间，线程 t1，t2 想象成两个人。
当线程 t1 执行到 synchronized(obj) 时就好比 t1 进入了这个房间，并反手锁住了门，在门内执行count++ 代码。
这时候如果 t2 也运行到了 synchronized(obj) 时，它发现门被锁住了，只能在门外等待。
当 t1 执行完 synchronized{} 块内的代码，这时候才会解开门上的锁，从 obj 房间出来。t2 线程这时才可以进入 obj 房间，反锁住门，执行它的 count-- 代码。
注意：上例中 t1 和 t2 线程必须用 synchronized 锁住同一个 obj 对象，如果 t1 锁住的是 m1 对象，t2 锁住的是 m2 对象，就好比两个人分别进入了两个不同的房间，没法起到同步的效果。
- t1线程进来后，发现锁没有owner，然后就成为owner- t2线程发现有owner，进入EntryList等待（被阻塞）
- 当t1运行结束后释放锁，t2才可以成为owner
- 如果EntryList中有多个线程，它们会抢占Owner
先来看一个现象，main 线程对 run 变量的修改对于 t 线程不可见，导致了 t 线程无法停止：
public class Demo4_1 {
static boolean run = true;
public static void main(String[] args) throws InterruptedException {
Thread t = new Thread(()->{
while (run) {
}
});
t.start();
Thread.sleep(1000);
run = false; // 线程t不会如预想的停下来
}
}
为什么呢？分析一下：
- 初始状态， t 线程刚开始从主内存读取了 run 的值到工作内存。
- 因为 t 线程要频繁从主内存中读取 run 的值，JIT 编译器会将 run 的值缓存至自己工作内存中的高速缓存中，减少对主存中 run 的访问，提高效率
- 1 秒之后，main 线程修改了 run 的值，并同步至主存，而 t 是从自己工作内存中的高速缓存中读取这个变量的值，结果永远是旧值
volatile（易变关键字）
它可以用来修饰成员变量和静态成员变量，他可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取它的值，线程操作 volatile 变量都是直接操作主存
public class Demo4_1 {
volatile static boolean run = true;
public static void main(String[] args) throws InterruptedException {
Thread t = new Thread(()->{
while (run) {
}
});
t.start();
Thread.sleep(1000);
run = false;
}
}
结果
2.3 可见性前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见， 不能保证原子性，仅用在一个写线程，多个读线程的情况： 上例从字节码理解是这样的：
getstatic run // 线程 t 获取 run true getstatic run // 线程 t 获取 run true getstatic run // 线程 t 获取 run true getstatic run // 线程 t 获取 run true putstatic run // 线程 main 修改 run 为 false， 仅此一次 getstatic run // 线程 t 获取 run false
比较一下之前我们将线程安全时举的例子：两个线程一个 i++ 一个 i-- ，只能保证看到最新值，不能解决指令交错
// 假设i的初始值为0 getstatic i // 线程1-获取静态变量i的值 线程内i=0 getstatic i // 线程2-获取静态变量i的值 线程内i=0 iconst_1 // 线程1-准备常量1 iadd // 线程1-自增 线程内i=1 putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=1 iconst_1 // 线程2-准备常量1 isub // 线程2-自减 线程内i=-1 putstatic i // 线程2-将修改后的值存入静态变量i 静态变量i=-1
注意 synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是synchronized是属于重量级操作，性能相对更低
如果在前面示例的死循环中加入 System.out.println() 会发现即使不加 volatile 修饰符，线程 t 也能正确看到对 run 变量的修改了，想一想为什么？
public class Demo4_1 {
static boolean run = true;
public static void main(String[] args) throws InterruptedException {
Thread t = new Thread(()->{
while (run) {
System.out.println("1");
}
});
t.start();
Thread.sleep(1000);
run = false;
}
}
结果
原因
System.out.println(“1”);被synchronized修饰了
3. 有序性 3.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 编译器在运行时的一些优化，这个现象需要通过大量测试才能复现：
借助 java 并发压测工具 jcstress https://wiki.openjdk.java.net/display/CodeTools/jcstress
创建 maven 项目，提供如下测试类
@JCStressTest
@Outcome(id = { "1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")
@State
public class ConcurrencyTest {
int num = 0;
boolean ready = false;
@Actor
public void actor1(I_Result r) {
if(ready) {
r.r1 = num + num;
} else {
r.r1 = 1;
}
}
@Actor public void actor2(I_Result r) {
num = 2;
ready = true;
}
}
执行
mvn clean install java -jar target/jcstress.jar
会输出我们感兴趣的结果，摘录其中一次结果：
可以看到，出现结果为 0 的情况有 638 次，虽然次数相对很少，但毕竟是出现了。
3.2 解决方法volatile 修饰的变量，可以禁用指令重排
@JCStressTest
@Outcome(id = { "1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")
@State
public class ConcurrencyTest {
int num = 0;
volatile boolean ready = false;
@Actor
public void actor1(I_Result r) {
if(ready) {
r.r1 = num + num;
} else {
r.r1 = 1;
}
}
@Actor public void actor2(I_Result r) {
num = 2;
ready = true;
}
}
结果为：
3.3 有序性理解JVM 会在不影响正确性的前提下，可以调整语句的执行顺序，思考下面一段代码
static int i; static int j; // 在某个线程内执行如下赋值操作 i = ...; // 较为耗时的操作 j = ...;
可以看到，至于是先执行 i 还是 先执行 j ，对最终的结果不会产生影响。所以，上面代码真正执行时，既可以是
i = ...; // 较为耗时的操作 j = ...;
也可以是
j = ...; i = ...; // 较为耗时的操作
这种特性称之为『指令重排』，多线程下『指令重排』会影响正确性，例如著名的 double-checked locking 模式实现单例
public final class Singleton {
private Singleton() {
}
private static Singleton INSTANCE = null;
public static Singleton getInstance() {
// 实例没创建，才会进入内部的 synchronized代码块
if (INSTANCE == null) {
synchronized (Singleton.class) {
// 也许有其它线程已经创建实例，所以再判断一次
if (INSTANCE == null) {
INSTANCE = new Singleton();
}
}
}
return INSTANCE;
}
}
以上的实现特点是：
- 懒惰实例化
- 首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁
但在多线程环境下，上面的代码是有问题的， INSTANCE = new Singleton() 对应的字节码为：
其中 4 7 两步的顺序不是固定的，也许 jvm 会优化为：先将引用地址赋值给 INSTANCE 变量后，再执行构造方法，如果两个线程 t1，t2 按如下时间序列执行：
这时 t1 还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例
对 INSTANCE 使用 volatile 修饰即可，可以禁用指令重排，但要注意在 JDK 5 以上的版本的 volatile 才会真正有效
3.4 happens-beforehappens-before 规定了哪些写操作对其它线程的读操作可见，它是可见性与有序性的一套规则总结，抛开以下 happens-before 规则，JMM 并不能保证一个线程对共享变量的写，对于其它线程对该共享变量的读可见
- 线程解锁 m 之前对变量的写，对于接下来对 m 加锁的其它线程对该变量的读可见
static int x;
static Object m = new Object();
new Thread(()->{
synchronized(m) {
x = 10;
}
},"t1").start();
new Thread(()->{
synchronized(m) {
System.out.println(x);
}
},"t2").start();
- 线程对 volatile 变量的写，对接下来其它线程对该变量的读可见
volatile static int x;
new Thread(()->{
x = 10;
},"t1").start();
new Thread(()->{
System.out.println(x);
},"t2").start();
- 线程 start 前对变量的写，对该线程开始后对该变量的读可见
static int x;
x = 10;
new Thread(()->{
System.out.println(x);
},"t2").start();
- 线程结束前对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或t1.join()等待它结束）
static int x;
Thread t1 = new Thread(()->{
x = 10;
},"t1");
t1.start();
t1.join();
System.out.println(x);
- 线程 t1 打断 t2（interrupt）前对变量的写，对于其他线程得知 t2 被打断后对变量的读可见（通过t2.interrupted 或 t2.isInterrupted）
static int x;
public static void main(String[] args) {
Thread t2 = new Thread(()->{
while(true) {
if(Thread.currentThread().isInterrupted()) {
System.out.println(x);
break;
}
}
},"t2");
t2.start();
new Thread(()->{
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
x = 10;
t2.interrupt();
},"t1").start();
while(!t2.isInterrupted()) {
Thread.yield();
}
System.out.println(x);
- 对变量默认值（0，false，null）的写，对其它线程对该变量的读可见 - 具有传递性，如果 x hb-> y 并且 y hb-> z 那么有 x hb-> z
4. CAS与原子类 4.1 CAS变量都是指成员变量或静态成员变量
无锁并发。CAS 即 Compare and Swap ，它体现的一种乐观锁的思想，比如多个线程要对一个共享的整型变量执行 +1 操作：
// 需要不断尝试
while(true) {
int 旧值 = 共享变量 ; // 比如拿到了当前值 0
int 结果 = 旧值 + 1; // 在旧值 0 的基础上增加 1 ，正确结果是 1
if( compareAndSwap ( 旧值, 结果 )) {
// 成功，退出循环
}
}
- 在进行结果与旧值的交换之前，会先进行旧值与共享变量的比较。如果共享变量没有被其他线程改变，与旧值相等，旧值才会与结果交换。
- 获取共享变量时，为了保证该变量的可见性，需要使用 volatile 修饰。结合 CAS 和 volatile 可以实现无锁并发，适用于竞争不激烈、多核 CPU 的场景下。
- 因为没有使用 synchronized，所以线程不会陷入阻塞，这是效率提升的因素之一
- 但如果竞争激烈，可以想到重试必然频繁发生，反而效率会受影响
CAS 底层依赖于一个 Unsafe 类来直接调用操作系统底层的 CAS 指令，下面是直接使用 Unsafe 对象进行线程安全保护的一个例子
package P4;
import sun.misc.Unsafe;
import java.lang.reflect.Field;
public class TestCAS {
public static void main(String[] args) throws InterruptedException {
DataContainer dc = new DataContainer();
int count = 10000;
Thread t1 = new Thread(() -> {
for (int i = 0; i > count; i++) {
dc.increase();
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i > count; i++) {
dc.decrease();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(dc.getData());
}
}
class DataContainer{
private volatile int data;
static final Unsafe unsafe;
static final long DATA_OFFSET;
static {
try {
// Unsafe 对象不能直接调用，只能通过反射获得
Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
theUnsafe.setAccessible(true);
unsafe = (Unsafe) theUnsafe.get(null);
} catch (NoSuchFieldException | IllegalAccessException e) {
throw new Error(e);
}
try {
// data 属性在 DataContainer 对象中的偏移量，用于 Unsafe 直接访问该属性
DATA_OFFSET = unsafe.objectFieldOffset(DataContainer.class.getDeclaredField("data"));
} catch (NoSuchFieldException e) {
throw new Error(e);
}
}
public void increase() {
int oldValue;
while(true) {
// 获取共享变量旧值，可以在这一行加入断点，修改 data 调试来加深理解
oldValue = data;
// cas 尝试修改 data 为 旧值 + 1，如果期间旧值被别的线程改了，返回 false
if (unsafe.compareAndSwapInt(this, DATA_OFFSET, oldValue, oldValue + 1)) {
return;
}
}
}
public void decrease() {
int oldValue;
while(true) {
oldValue = data;
if (unsafe.compareAndSwapInt(this, DATA_OFFSET, oldValue, oldValue - 1)) {
return;
}
}
}
public int getData() {
return data;
}
}
结果
4.2 乐观锁和悲观锁- CAS 是基于乐观锁的思想：最乐观的估计，不怕别的线程来修改共享变量，就算改了也没关系，我吃亏点再重试呗。
- synchronized 是基于悲观锁的思想：最悲观的估计，得防着其它线程来修改共享变量，我上了锁你们都别想改，我改完了解开锁，你们才有机会。
juc（java.util.concurrent）中提供了原子操作类，可以提供线程安全的操作，例如：AtomicInteger、AtomicBoolean等，它们底层就是采用 CAS 技术 + volatile 来实现的。
可以使用 AtomicInteger 改写之前的例子：
package P4;
import java.util.concurrent.atomic.AtomicInteger;
public class Demo4_4 {
// 创建原子类整数对象
private static AtomicInteger i = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(()-> {
for (int j = 0; j > 5000; j++) {
i.getAndIncrement(); // 获取并且自增 i++
// i.incrementAndGet(); // 自增并且获取 ++i
}
});
Thread t2 = new Thread(()-> {
for (int j = 0; j > 5000; j++) {
i.getAndDecrement(); // 获取并且自减 i--
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(i);
}
}
结果
