很多人将【java 内存结构】与【java 内存模型】傻傻分不清,【java 内存模型】是 Java Memory Model(JMM)的意思。
关于它的权威解释,请参考 https://download.oracle.com/otn-pub/jcp/memory_model-1.0-pfdspec-oth-JSpec/memory_model-1_0-pfd-spec.pdf? AuthParam=1562811549_4d4994cbd5b59d964cd2907ea22ca08b。
简单的说,JMM 定义了一套在多线程读写共享数据时(成员变量、数组)时,对数据的可见性、有序 性、和原子性的规则和保障
MM 即 Java Memory Model,它定义了主存(共享内存)、工作内存(线程私有)抽象概念,底层对应着 CPU 寄存器、缓存、硬件内存、 CPU 指令优化等。
JMM体现在以下几个方面
原子性 - 保证指令不会受到线程上下文切换的影响
可见性 - 保证指令不会受 cpu 缓存的影响
有序性 - 保证指令不会受 cpu 指令并行优化的影响
原子性在学习线程时讲过,下面来个例子简单回顾一下:
问题提出,两个线程对初始值为 0 的静态变量一个做自增,一个做自减,各做 5000 次,结果是 0 吗?
答案是结果不一定是0
public class Demo4_1 {
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 < 50000; j++) {
i++;
}
});
Thread t2 = new Thread(() -> {
for (int j = 0; j < 50000; j++) {
i--;
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(i);
}
}
以上的结果可能是正数、负数、零。为什么呢?因为 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
注意,这里静态变量和局部变量取数时所用的指令不同,局部变量是在局部变量曹上执行的。
**而java的内存模型如下,内存模型把整个内存分为两部分,一部分叫主内存,一部分叫工作内存。它们不能和内存结构中的堆栈相混淆。
完成静态变量的自增、自减需要在主存和线程内存中进行数据交换。
getstatic把主存中把i的值读入到工作内存中来,然后工作内存中做完了加法,然后把结果写回到主内存中去。
如果是单线程以上 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 行代码可能交错运行(为什么会交错?思考一下): 出现负数的情况:
// 假设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
整个操作系统中,在微观上看,是一种多任务性的,线程会轮流拿到CPU的时间片,有可能CPU在时间片1的时候执行线程1,在时间片2的时候执行线程2。但总是会出现这样一种情况,CPU执行线程1getstatic,获取到了静态变量的初始值,刚开始i为0,但是在这个时候,时间片用完,CPU执行线程2的代码,也是执行getstatic,此时获取到的初始值也为0.这样在后续的操作中,它们都是对0做加减。最终线程2的结果覆盖了线程1的结果,我们得到的结果是-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
synchronized同步关键字
语法
synchronized( 对象 ) {
要作为原子操作代码
}
当某个线程执行到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 < 50000; j++) {
synchronized (obj) {
i++;
}
}
});
Thread t2 = new Thread(() -> {
for (int j = 0; j < 50000; j++) {
synchronized (obj) {
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来了,如果它发现monitor中的owner是空着的,并没有其它线程所占据,这个时候,这个线程就会成为owner,并且会用monitor_enter指令对monitor进行锁定。
当第二个线程t2来了,发现t1已经成为了owner,并且把monitor锁定了,但是它可以进入EntryList,这是一个排队等候区。它实际上阻塞了。
当t1执行完了之后,它会执行一个monitor_exit,它会通知entryList中正在等待的线程,这个时候t2线程就可以成为新的owner。然后执行同样的过程。
如果EntryList有多个线程的话,它们实际上会争抢成为新的owner
但是这样效率会非常低,我们执行50000次,这样就要执行50000次的monitor_enter和monitor_exit指令,这样是比较耗时的。虽然Java虚拟机支持对同一个对象monitor_enter和exit,显然效率比较低。
先来看一个现象,main 线程对 run 变量的修改对于 t 线程不可见,导致了 t 线程无法停止:
public class Demo4_2 {
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; // 线程t不会如预想的停下来
}
}
为什么呢?分析一下:
volatile(易变关键字)
它可以用来修饰成员变量和静态成员变量,他可以避免线程从自己的工作缓存中查找变量的值,必须到 主存中获取它的值,线程操作 volatile 变量都是直接操作主存
public class Demo4_2 {
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; // 线程t不会如预想的停下来
}
}
此时,程序正常运行结束。
因为volatile修饰的变量,读取是每次都到主存中读取的,不会说每次都到高速缓存中读取,这样就保证了读取的线程看到的总是最新的结果。
前面例子体现的实际就是可见性,它保证的是在多个线程之间,一个线程对 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=-
可见性与原子性
注意 synchronized 语句块既可以保证代码块的原子性,也同时保证代码块内变量的可见性。
但缺点是 synchronized 是属于重量级操作,性能相对更低。
如果在前面示例的死循环中加入 System.out.println() 会发现即使不加 volatile 修饰符,线程 t 也能正确看到 对 run 变量的修改了,想一想为什么?
public class Demo4_2 {
volatile 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; // 线程t不会如预想的停下来
}
}
这是因为底层synchronized方法起到了作用。
public void println(String x) {
//使用了synchronized关键字
synchronized (this) {
print(x);
newLine();
}
}
因为它也可以防止当前线程从高速缓存中获取的值,破坏了刚才的JIT的优化。
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
mvn archetype:generate -DinteractiveMode=false
DarchetypeGroupId=org.openjdk.jcstress -DarchetypeArtifactId=jcstress-java-testarchetype -DgroupId=org.sample -DartifactId=test -Dversion=1.0
创建 maven 项目,提供如下测试类
@JCStressTest
//如果结果是1和4,那么分类到可接受集中,表示结果意料之中
@Outcome(id = {
"1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")
//如果结果是0,归类到感兴趣的结果类
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")
@State public
class ConcurrencyTest {
int num = 0;
boolean ready = false;
//这两个方法将来要通过不同的线程来测试并发,因此需要加上actor标签
@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
会输出我们感兴趣的结果,摘录其中一次结果:
volatile 修饰的变量,可以禁用指令重排。然后一个线程往volatile变量写,一个线程从volatile变量读。读写操作就不会受到指令重排的影响了。
@JCStressTest
//如果结果是1和4,那么分类到可接受集中,表示结果意料之中
@Outcome(id = {
"1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")
//如果结果是0,归类到感兴趣的结果类
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")
@State public
class ConcurrencyTest {
int num = 0;
volatile boolean ready = false;
//这两个方法将来要通过不同的线程来测试并发,因此需要加上actor标签
@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;
}
}
结果为:
*** INTERESTING tests
Some interesting behaviors observed. This is for the plain curiosity.
0 matching test results.
同一个线程内,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代码块
//多线程并发调用getinstance方法,有可能会造成单例对象被创建多次
//实际上,我们只需要第一次判断的时候才需要加锁,其它时候不需要加锁,所以需要双重检查
if (INSTANCE == null) {
synchronized (Singleton.class) {
// 也许有其它线程已经创建实例,所以再判断一次
if (INSTANCE == null) {
INSTANCE = new Singleton();
}
}
}
return INSTANCE;
}
}
以上的实现特点是:
懒惰实例化
首次使用 getInstance() 才使用 synchronized 加锁,后续使用时无需加锁
但在多线程环境下,上面的代码是有问题的, INSTANCE = new Singleton() 对应的字节码为:
0: new #2 // class cn/itcast/jvm/t4/Singleton
3: dup
4: invokespecial #3 // Method "":()V
7: putstatic #4 // Field INSTANCE:Lcn/itcast/jvm/t4/Singleton;
第一步,new一个对象,给对象分配空间,它的执行结果会把对象的引用放入操作数栈。操作数栈把这个对象的引用复制了一份,相当于这时栈顶有两个对象引用,第一个对象引用交给了invokespecial调用构造方法,第二个对象引用交给了putstatic给INSTANCE静态变量赋值。
其中4 7 两边的顺序不是固定的,也许jvm会优化为:先将引用地址赋值给INSTANCE变量后,再执行构造方法,如果两个线程t1和t2按如下时间序列执行:
时间1 t1 线程执行到 INSTANCE = new Singleton();
时间2 t1 线程分配空间,为Singleton对象生成了引用地址(0 处)
时间3 t1 线程将引用地址赋值给 INSTANCE,这时 INSTANCE != null(7 处)
时间4 t2 线程进入getInstance() 方法,发现 INSTANCE != null(synchronized块外),直接 返回 INSTANCE
时间5 t1 线程执行Singleton的构造方法(4 处)
这时 t1 还未完全将构造方法执行完毕,如果在构造方法中要执行很多初始化操作,那么 t2 拿到的是将 是一个未初始化完毕的单例
对 INSTANCE 使用 volatile 修饰即可,可以禁用指令重排,但要注意在 JDK 5 以上的版本的 volatile 才 会真正有效
happens-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();
假设上述程序,t1先执行,t2后执行。那么t1修改了之后对t2可见。
线程对 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(()->{
sleep(1);
x = 10;
t2.interrupt();
},"t1").start();
while(!t2.isInterrupted()) {
Thread.yield();
}
System.out.println(x); }
6.对变量默认值(0,false,null)的写,对其它线程对该变量的读可见
7.具有传递性,如果 x hb-> y 并且 y hb-> z 那么有 x hb-> z ,配合 volatile 的防指令重排,有下面的例子
volatile static int x;
static int y;
new Thread(()->{
y = 10;
x = 20;
},"t1").start();
new Thread(()->{
// x=20 对 t2 可见, 同时 y=10 也对 t2 可见
System.out.println(x);
},"t2").start();