JMM内存抽象
JMM定义了线程和主内存之间的抽象关系:线程之间的共享变量存储在主内存中,每个线程都有一个私有的本地内存,本地内存中存储了该线程以读/写共享变量的副本。
本地内存是JMM的一个抽象概念,并不真实存在。它涵盖了缓存,写缓冲区,寄存器以及其他的硬件和编译器优化。
同时JMM确保在不同的编译器和不同的处理器平台之上,通过禁止特定类型的编译器重排序和处理器重排序,为程序员提供一致的内存可见性保证
所有实例域、静态域和数组元素存储在堆内存中,堆内存在线程之间共享
局部变量,方法定义参数和异常处理器参数不会在线程之间共享,它们不会有内存可见性问题,也不受内存模型的影响
重排序
在执行程序时为了提高性能,编译器和处理器常常会对指令做重排序
- 编译器优化的重排序:编译器在不改变单线程程序语义的前提下,可以重新安排语句的执行顺序
- 指令级并行的重排序:现代处理器采用了指令级并行技术(Instruction-Level Parallelism, ILP)来将多条指令重叠执行。如果不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序
- 内存系统的重排序:由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是在乱序执行
- 对于编译器:JMM的编译器重排序规则会禁止特定类型的编译器重排序
- 对于处理器重排序:JMM的处理器重排序规则会要求java编译器在生成指令序列时,插入特定类型的内存屏障(memory barriers)指令,通过内存屏障指令来禁止特定类型的处理器重排序
内存屏障
为了保证内存可见性,java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序
屏障类型 | 指令示例 | 说明 |
---|---|---|
LoadLoad Barriers | Load1; LoadLoad; Load2 | 确保Load1数据的装载,之前于Load2及所有后续装载指令的装载 |
StoreStore Barriers | Store1; StoreStore; Store2 | 确保Store1数据对其他处理器可见(刷新到内存),之前于Store2及所有后续存储指令的存储 |
LoadStore Barriers | Load1; LoadStore; Store2 | 确保Load1数据装载,之前于Store2及所有后续的存储指令刷新到内存 |
StoreLoad Barriers | Store1; StoreLoad; Load2 | 确保Store1数据对其他处理器变得可见(指刷新到内存),之前于Load2及所有后续装载指令的装载。StoreLoad Barriers会使该屏障之前的所有内存访问指令(存储和装载指令)完成之后,才执行该屏障之后的内存访问指令 |
StoreLoad Barriers是一个“全能型”的屏障,它同时具有其他三个屏障的效果。执行该屏障开销会很昂贵,因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中(buffer fully flush)
Happen-Before原则
JMM通过这个概念来阐述操作之间的内存可见性:如果一个操作执行的结果需要对另一个操作可见,那么这两个操作之间必须存在happens-before关系
两个操作既可以是在一个线程之内,也可以是在不同线程之间
- 程序顺序规则:一个线程中的每个操作,happens- before 于该线程中的任意后续操作
- 监视器锁规则:对一个监视器锁的解锁,happens- before 于随后对这个监视器锁的加锁
- volatile变量规则:对一个volatile域的写,happens- before 于任意后续对这个volatile域的读
- 传递性:如果A happens- before B,且B happens- before C,那么A happens- before C
注意,两个操作之间具有happens-before关系,并不意味着前一个操作必须要在后一个操作之前执行!happens-before仅仅要求前一个操作(执行的结果)对后一个操作可见,且前一个操作按顺序排在第二个操作之前(the first is visible to and ordered before the second)
并发层次
通过Volatile机制和CAS指令实现了多核的
缓存一致性
通过MESI协议实现多核间的缓存一致性
CPU所有的操作都是在其各自核的缓存内完成的,如果不回写,其他核根本不知道变量被修改了,只有当CPU对缓存进行回写并通过MESI协议通知时才知道
Volatile
轻量级的同步机制,不会引起线程的上下文切换
当写一个volatile变量时,JMM会把该线程对应的本地内存中的共享变量刷新到主内存
当读一个volatile变量时,JMM会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量。即每次都从主存中读取最新的数据
但Volatile只能保证可见性,不能保证原子性
CAS
保证多核下指令执行的原子性,但操作的是主存,直接绕过了缓存(不会触发缓存回写)
所以要实现多核间的可见性,CAS操作的变量要使用volatile修饰
原子变量实现
利用volatile和cas
以AtomicInteger的实现为例
private volatile int value;
public final int incrementAndGet() {
// 一直循环,直到更新成功为止
for (;;) {
// 获取当前值
int current = get();
int next = current + 1;
// 使用cas原子性更新
if (compareAndSet(current, next))
return next;
}
}
// volatile修饰,每次都读取最新的值
public final int get() {
return value;
}
AQS实现
本质就是状态+等待链表
通过一个内部的Int变量来代表状态,状态的值代表通过还是等待
如果等待,则提供一个非阻塞的等待链表(通过CAS来实现节点的增删),同时在释放时,唤醒等待的线程
AQS是一个基础类,所有需要阻塞等待的,都可以使用其特性来实现
锁实现
继承于AQS,对于互斥锁,状态0为则没有通过,并设置为1,否则阻塞等待
public void lock() {
sync.lock();
}
// NonFair为例
final void lock() {
// 设置状态成功(0变成1),成功获取锁
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
// 再尝试申请,失败则等待
acquire(1);
}
// AQS
public final void acquire(int arg) {
// 如果尝试申请失败,则将当前线程加入到等待队列中
if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
// 再次尝试申请一次
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
// 如果是当前线程获取的锁,则直接增加次数即可
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
并发数据结构
这里不对每个数据结构的实现方式做详细描述,只简单地列一下每个数据结构的大概使用方式
数据结构 | 说明 |
---|---|
SynchronousQueue | 并不是一个队列,可以看成size=1的队列,一次只能放入一个元素 |
PriorityBlockingQueue | 优先级队列 |
LinkedBlockingQueue | 链表队列,队列为空时需要等待,适合生产者-消费者模型 |
LinkedBlockingDeque | 链表的双端队列 |
DelayQueue | 延迟队列 |
CopyOnWriteArraySet | 修改时进行复制的集合 |
CopyOnWriteArrayList | 修改时进行复制的队列 |
ConcurrentSkipListSet | 有序的Set |
ConcurrentSkipListMap | 有序的Map |
ConcurrentLinkedQueue | 并发队列,添加、获取都不会等待 |
ConcurrentHashMap | 并发HashMap |
ArrayBlockingQueue | 数组队列,有界 |
参考
深入理解Java内存模型(一)——基础
深入理解Java内存模型(四)——volatile
聊聊并发(一)——深入分析Volatile的实现原理
深入理解Java内存模型(五)——锁