JAVA 并发编程的艺术笔记(2.1 volatile的应用)

2.1.1 volatile 的定义与实现原理

java编程语言允许线程访问共享变量,为了确保共享变量能被准准确和一致地更新,线程应该确保通过排他锁单独获得这个变量。

如果一个字段被声明成voliatile,java线程内存模型确保所有线程看到这个变量的值是一致的。

相关cpu术语:

(图省略)

  • 内存屏障(memory barriers)

    是一组处理器指令,用于实现对内存操作的顺序限制

  • 缓冲行(cache line)

    缓存中可以分配的最小储存单位。处理器填写缓存线时会加载整个缓存线

  • 原子操作(atomoc operations)

    不可中断的一个或者一系列操作

  • 缓存行填充(cache line fill)

    当处理器识别到从内存中读取操作数是可缓存的,处理器整个缓存行到适当的缓存(L1,L2,L2或所有)

  • 缓存命中(cache hit)

    如果进行高速缓存行填充操作的内存位置仍然是下次处理器访问得地址时,处理器从缓存中读取操作数,而不是从内存读取。

  • 写命中(write hit)

    当处理器将操作数写回到一个内存缓存的区域时,它首先会检查这个缓存的内存地址是否在缓存行中,如果存在一个有效的缓存行,则处理器将这个操作数写会到缓存,而不是写回到内存,这个操作被称为写命中。

  • 写缺失

    一个有效的缓存行被写入到不存在的内存区域

    volatile是如何来保证可见性的呢?

    1)将当前处理器缓存行的数据写回到系统内存。

    2)这个写回内存的操作会使在其他CPU里缓存了该内存地址的数据无效。

    为了提高处理速度,处理器不直接和内存进行通信,而是先将系统内存的数据读到内部缓存(L1,L2或其他)后再进行操作,但操作完不知道何时会写到内存。如果对声明了volatile的

    变量进行写操作,JVM就会向处理器发送一条Lock前缀的指令,将这个变量所在缓存行的数据

    写回到系统内存。但是,就算写回到内存,如果其他处理器缓存的值还是旧的,再执行计算操

    作就会有问题。所以,在多处理器下,为了保证各个处理器的缓存是一致的,就会实现缓存一

    致性协议,每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了,当

    处理器发现自己缓存行对应的内存地址被修改,就会将当前处理器的缓存行设置成无效状

    态,当处理器对这个数据进行修改操作的时候,会重新从系统内存中把数据读到处理器缓存

    里。

    下面来具体讲解volatile的两条实现原则。

    1)Lock前缀指令会引起处理器缓存回写到内存。Lock前缀指令导致在执行指令期间,声

    言处理器的LOCK#信号。在多处理器环境中,LOCK#信号确保在声言该信号期间,处理器可以

    独占任何共享内存[2]。但是,在最近的处理器里,LOCK#信号一般不锁总线,而是锁缓存,毕

    竟锁总线开销的比较大。在8.1.4节有详细说明锁定操作对处理器缓存的影响,对于Intel486和

    Pentium处理器,在锁操作时,总是在总线上声言LOCK#信号。但在P6和目前的处理器中,如果

    访问的内存区域已经缓存在处理器内部,则不会声言LOCK#信号。相反,它会锁定这块内存区

    域的缓存并回写到内存,并使用缓存一致性机制来确保修改的原子性,此操作被称为“缓存锁

    定”,缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据。

    2)一个处理器的缓存回写到内存会导致其他处理器的缓存无效。IA-32处理器和Intel 64处

    理器使用MESI(修改、独占、共享、无效)控制协议去维护内部缓存和其他处理器缓存的一致

    性。在多核处理器系统中进行操作的时候,IA-32和Intel 64处理器能嗅探其他处理器访问系统

    内存和它们的内部缓存。处理器使用嗅探技术保证它的内部缓存、系统内存和其他处理器的

    缓存的数据在总线上保持一致。例如,在Pentium和P6 family处理器中,如果通过嗅探一个处理

    器来检测其他处理器打算写内存地址,而这个地址当前处于共享状态,那么正在嗅探的处理

    器将使它的缓存行无效,在下次访问相同内存地址时,强制执行缓存行填充。

    著名的Java并发编程大师Doug lea在JDK 7的并发包里新增一个队列集合类Linked-

    TransferQueue,它在使用volatile变量时,用一种追加字节的方式来优化队列出队和入队的性

    能。LinkedTransferQueue的代码如下。

    /** 队列中的头部节点 */

    private transient f?inal PaddedAtomicReference head;

    /** 队列中的尾部节点 */

    private transient f?inal PaddedAtomicReference tail;

    static f?inal class PaddedAtomicReference extends AtomicReference T> {

    // 使用很多4个字节的引用追加到64个字节

    Object p0, p1, p2, p3, p4, p5, p6, p7, p8, p9, pa, pb, pc, pd, pe;

    PaddedAtomicReference(T r) {

    super®;

    }

    }

    public class AtomicReference implements java.io.Serializable {

    private volatile V value;

    // 省略其他代码

    追加字节能优化性能?这种方式看起来很神奇,但如果深入理解处理器架构就能理解其

    中的奥秘。让我们先来看看LinkedTransferQueue这个类,它使用一个内部类类型来定义队列的

    头节点(head)和尾节点(tail),而这个内部类PaddedAtomicReference相对于父类

    AtomicReference只做了一件事情,就是将共享变量追加到64字节。我们可以来计算下,一个对

    象的引用占4个字节,它追加了15个变量(共占60个字节),再加上父类的value变量,一共64个

    字节。

    为什么追加64字节能够提高并发编程的效率呢?因为对于英特尔酷睿i7、酷睿、Atom和

    NetBurst,以及Core Solo和Pentium M处理器的L1、L2或L3缓存的高速缓存行是64个字节宽,不

    支持部分填充缓存行,这意味着,如果队列的头节点和尾节点都不足64字节的话,处理器会将

    它们都读到同一个高速缓存行中,在多处理器下每个处理器都会缓存同样的头、尾节点,当一

    个处理器试图修改头节点时,会将整个缓存行锁定,那么在缓存一致性机制的作用下,会导致

    其他处理器不能访问自己高速缓存中的尾节点,而队列的入队和出队操作则需要不停修改头节点和尾节点,所以在多处理器的情况下将会严重影响到队列的入队和出队效率。Doug lea使

    用追加到64字节的方式来填满高速缓冲区的缓存行,避免头节点和尾节点加载到同一个缓存

    行,使头、尾节点在修改时不会互相锁定。

    那么是不是在使用volatile变量时都应该追加到64字节呢?不是的。在两种场景下不应该

    使用这种方式。

    ·缓存行非64字节宽的处理器。如P6系列和奔腾处理器,它们的L1和L2高速缓存行是32个

    字节宽。

    ·共享变量不会被频繁地写。因为使用追加字节的方式需要处理器读取更多的字节到高速

    缓冲区,这本身就会带来一定的性能消耗,如果共享变量不被频繁写的话,锁的几率也非常

    小,就没必要通过追加字节的方式来避免相互锁定。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值