JVM内存结构 VS Java内存模型 VS Java对象模型
- 整体方向
- JVM内存结构,和Java虚拟机的运行时区域有关。
- Java内存模型,和Java的并发编程有关。
- Java对象模型,和Java对象在虚拟机中表现形式有关。
Java对象模型
- Java对象自身的存储模型
- JVM会给这个类创建一个instanceKlass,保存在方法区,用来在JVM层表示该Java类。
- 当我们在Java代码中,使用new创建一个对象的时候,JVM会创建一个instanceOopDesc对象,这个对象中包含了对象头以及实例数据。
1.内存模型
内存模型:在特定的操作协议下,对特定的内存或高速缓存进行读写访问的过程抽象
Java内存模型主要关注JVM中把把变量值存储到内存和从内存中取出变量值这样的底层细节
- 所有变量(共享的)都存储在主内存中,每个线程都有自己工作内存;工作内存中保存该线程使用到的变量的主内存副本拷贝
- 线程对变量的所有操作(读、写)都应该在工作内存中完成
- 不同线程不能相互访问工作内存,交互数据要通过主内存
为什么需要JMM
JMM即为JAVA 内存模型(java memory model)。因为在不同的硬件生产商和不同的操作系统下,内存的访问逻辑有一定的差异,结果就是当你的代码在某个系统环境下运行良好,并且线程安全,但是换了个系统就出现各种问题。Java内存模型,就是为了屏蔽系统和硬件的差异,让一套代码在不同平台下能到达相同的访问结果
2.内存间的交互操作
Java内存模型规定了一些操作来实现内存间交互,JVM会保存证它们是原子的
lock:锁定,把变量标识为线程独占,作用于主内存变量
unlock:解锁,把锁定的变量释放,别的线程才能使用,作用于主内存变量
read:读取,把变量值从主内存读取到工作内存
load:载入,把read读取到的值放入工作内存的变量副本中
use:使用,把工作内存中一个变量的值传递给执行引擎
assign:赋值,把从执行引擎接收到的值赋给工作内存里面的变量
store:存储,把工作内存中一个变量的值传递到主内存中
write:写入,把store进来的数据存放到主内的变量中
3.内存间交互操作的规则
- 如果要把一个变量从主内存中复制到工作内存, 就需要按顺序地执 行read和load操作 , 如果把变量从工作内存中同步回主内存中, 就要按顺序地执行store和write操作. 但Java内存模型只要求上述操作必须按顺序执行,而没有保证必须是连续执行
- 不允许read和load、 store和write操作之一单独出现
- 不允许一个线程丢弃它的最近assign的操作,即变量在工作内存中改变了之后必须同步到主内存中
- 不允许一个线程无原因地(没有发生过任何assign操作)把数据从工作内存同步回主内存中
- 一个新的变量只能在主内存中诞生, 不允许在工作内存中直接使用一个未被初始化(load或assign)的变量。 即就是对一个变量实施use和store操作之前 , 必须先执行过了assign和load操作
- 一个变量在同一时刻只允许一条线程对 其进行lock操作 , 但lock操作可以被同一条线程重复执行多次,多7. 次执行lock后,只有执行相同次数的unlock操作,变量才会被解锁。lock和unlock必须成对出现
如果对一个变量执行lock操作,将会清空工作内存中此变量的值, 在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值 - 如果一个变量事先没有被lock操作锁定 , 则不允许 对它执行unlock操作 ; 也不允许去unlock一个被其他线程锁定的变量
- 对一个变量执行unlock操作之前 , 必须先把此变量同步到主内存中(执行store和write操作)
4.重排序
4.1重排序的代码案例
/**
* 描述: 演示重排序的现象 “直到达到某个条件才停止”,测试小概率事件
*/
public class OutOfOrderExecution {
private static int x = 0, y = 0;
private static int a = 0, b = 0;
public static void main(String[] args) throws InterruptedException {
int i = 0;
for (; ; ) {
i++;
x = 0;
y = 0;
a = 0;
b = 0;
CountDownLatch latch = new CountDownLatch(3);
Thread one = new Thread(new Runnable() {
@Override
public void run() {
try {
latch.countDown();
latch.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
a = 1;
x = b;
}
});
Thread two = new Thread(new Runnable() {
@Override
public void run() {
try {
latch.countDown();
latch.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
b = 1;
y = a;
}
});
two.start();
one.start();
latch.countDown();
one.join();
two.join();
String result = "第" + i + "次(" + x + "," + y + ")";
if (x == 0 && y == 0) {
System.out.println(result);
break;
} else {
System.out.println(result);
}
}
}
}
x,y 可以是0,1 1,0 1,1 不可能是0,0 但是输出结果
省略...
第133601次(0,1)
第133602次(0,1)
第133603次(0,1)
第133604次(1,0)
第133605次(0,0)
Process finished with exit code 0
会出现x=0,y=0?那是因为重排序发生了,4行代码的执行顺序的其中一种可能:
y = a;
a = 1;
x = b;
b = 1;
重排序的例子、什么是重排序
在线程1内部的两行代码的实际执行顺序和代码在Java文件中的顺序不一致,代码指令并不是严格按照代码语句顺序执行的,它们的顺序被改变了,这就是重排序,这里被颠倒的是y=a和b=1这两行语句。
4.2 重排序的好处:提高处理速度
- 对比重排序前后的指令
优化
重排序明显提高了处理速度
4.3 重排序的3种情况
- 编译器优化:
包括JVM,JIT编译器等 - CPU指令重排:
就算编译器不发生重排,CPU也可能对指令进行重排 - 内存的
"重排序"
:
线程A的修改线程B却看不到,引出可见性问题
程序执行一段代码,写一个普通的共享变量,其可能先被写到缓冲区然后再被写到主内存,此时指令完成的时间就被推迟了。看上去像"重排序"
5.可见性
public class FieldVisibility {
int a = 1;
int b = 2;
private void change() {
a = 3;
b = a;
}
private void print() {
System.out.println("b=" + b + ";a=" + a);
}
public static void main(String[] args) {
while (true) {
FieldVisibility test = new FieldVisibility();
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
test.change();
}
}).start();
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
test.print();
}
}).start();
}
}
}
而b其它线程恰好可见
可见性是什么?(通俗易懂)
a b 前面加上volatile 关键字,解决可见性问题
volatile int a = 1;
volatile int b = 2;
为什么会有可见性问题?
CPU有多级缓存,导致读的数据过期:
- 高速缓存的容量比主内存小,但是速度仅次于寄存器,所以在CPU和主内存之间就多了Cache层;
- 线程间的对于共享变量的可见性问题不是直接由多核引起的,而是由多缓存引起的;
- 如果所有的核心只有一个缓存,那就不会出现内存可见性问题;
但是每个核心都会将自己需要的数据读到独占的缓存中,数据修改后也是写入到缓存中,然后等待刷入到主存中,所以会导致有些核心读取的值是一个过期的值。
总结:
所有的共享变量存在于主内存
中,每个线程有自己的本地内存
,而且线程读写共享数据
也是通过工作内存交换,但是存在延迟的情况,所以导致可见性问题的出现。