Java虚拟机13：互斥同步、锁优化及synchronized和volatile

互斥同步

互斥同步（Mutual Exclusion & Synchronization）是常见的一种并发正确性保证手段。同步是指子啊多个线程并发访问共享数据时，保证共享数据在同一时刻只能被一个（或者是一些，使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区（Critial Section）、互斥量（Mutex）和信号量（Semaphore）都是主要的互斥实现方式。所以，在这四个字里面，互斥是因，同步是果；互斥是方法，同步是目的。

 

synchronized的实现

在Java中，你们都知道，synchronized关键字是最基本的互斥同步手段。看一段简单的代码：

public static void main(String[] args)
{
    synchronized (TestMain.class)
    {
        
    }
}

这段代码被编译以后是这样的：

 1 public static void main(java.lang.String[]);
 2   flags: ACC_PUBLIC, ACC_STATIC
 3   Code:
 4     stack=2, locals=1, args_size=1
 5        0: ldc           #1                  // class com/xrq/test53/TestMain
 6        2: dup
 7        3: monitorenter
 8        4: monitorexit
 9        5: return
10     LineNumberTable:
11       line 7: 0
12       line 11: 5
13     LocalVariableTable:
14       Start  Length  Slot  Name   Signature
15              0       6     0  args   [Ljava/lang/String;

关键就在第7行和第8行，在源代码被编译以后，Java虚拟机会利用monitorenter和monitorexit条字节码指令来处理synchronized这个关键字。

根据虚拟机规范的要求，在执行monitorenter指令时，首先要尝试获取对象的锁，若是这个对象没有被锁定，或者当前线程已经拥有了那个对象的锁，把锁的计数器加1，相应地，在执行monitorexit指令时会将锁计数器减1，当计数器为0时，锁就会被释放。若是获取对象锁失败，那当前线程就要阻塞等待，直到对象锁被另一个线程释放为止。

关于monitorenter和monitorexit，有两点是要特别注意的：

一、synchronized同步块对同一条线程来讲是可重入的，不会出现把本身锁死的问题

二、同步块在已进入的线程执行完以前，会阻塞后面其它线程的进入

由于Java的线程是映射到操做系统的原生线程之上的，若是要阻塞或者唤醒一个线程，都须要操做系统来帮忙完成，这就须要从用户态转换到核心态中，所以状态转换须要耗费不少的处理器时间，对于代码简单的同步块，状态转换消耗的时间有可能比用户代码执行的时间还长，因此synchronized是Java语言中一个重量级（Heavyweight）锁，有经验的程序员都会在确实必要的状况下才使用这种操做。

顺便看一下HotSpot虚拟机对象头Mark Word：

存 储 内 存	标 识 位	状    态
对象哈希吗、对象分代年龄	01	未锁定
指向锁记录的指针	00	轻量级锁定
指向重量级锁的指针	10	膨胀（重量级锁定）
空，不须要记录信息	11	GC标记
偏向线程ID、偏向时间戳、对象分代年龄	01	可偏向

看到有一个重量级锁定，指的就是重量级锁。

 

volatile的实现

对于volatile关键字，一个被volatile关键字修饰的变量，在生成汇编语言以后，大体会多出这么一条指令：

0x01a3de24:lock addl $0x0,(%esp)      ;...f0830424 00

这个操做至关因而一个内存屏障，只有一个CPU访问内存时，并不须要内存屏障；但若是有两个或者更多CPU访问同一块内存时，且其中一个在观测另一个，就须要内存屏障来保证一致性了。这句指令中的"addl $0x0,(%esp)"（把esp寄存器的值加0）显然是一个空操做（采用这个空操做而不是空指令nop是由于IA32手册规定lock前缀不容许配合nop指令使用），关键在于lock前缀，查询IA32手册，它的做用是使得本CPU的Cache写入了内存，该写入动做也会引发别的CPU或者别的内核无效化其Cache，这种操做至关于对Cache中的变量作了一次"store和write"操做，因此经过这样一个空操做，可以让前面volatile变量的修改对其余CPU当即可见。

 

自旋锁与自适应自旋

互斥同步，对性能影响最大的是阻塞的实现，挂起线程和恢复线程的操做都须要转入内核状态完成，这些操做给系统的并发性能带来了很大的压力。同时，虚拟机开发团队也注意到不少应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。若是物理机上有一个以上的处理器，能让两个或两个以上的线程同时并行执行，咱们就可让后面请求锁的那个线程"稍等一下"，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，咱们只须要让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。

在JDK1.4.2就已经引入了自旋锁，只不过默认是关闭的。自旋不能代替阻塞，且先不说处理器数量的要求，自旋等待自己虽然避免了线程切换的开销，可是它是要占据处理器时间的，所以若是锁被占用的时间很短，自旋等待的效果就很是好；反之，若是锁被占用的时间很长，那么自旋的线程只会白白消耗处理器资源，而不会作任何有用的工做，反而会带来性能上的浪费。所以自选等待必须有必定的限度，若是自旋超过了限定的次数仍然没有成功得到锁，就应当使用传统的方式去挂起线程了，自旋次数的默认值是10。

在JDK1.6以后引入了自适应的自旋锁。自适应意味着自旋的时间再也不固定了，而是由前一次在同一个锁上自旋的时间以及锁的拥有者的状态来决定。若是在同一个锁对象上，自旋等待刚刚得到过锁，而且持有锁的线程正在运行中，那么虚拟机就会认为此次自旋也颇有可能再次成功，进而它将容许自旋等待持续相对更长的时间，好比100个循环。另外若是对于某一个锁，自旋不多成功得到过，那么在之后要得到这个锁时将可能忽略掉自旋过程，以免浪费处理器资源。有了自适应自旋，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的情况预测就会愈来愈准确。

 

锁消除

锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，可是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要断定依据来源于逃逸分析的支持，若是判断在一段代码中，堆上全部数据都不会逃逸出去从而被其余线程访问到，那就能够把它们当作栈上数据对待，认为它们是线程私有的，同步加锁天然无需进行。

 

锁粗化

原则上，咱们在编写代码的时候，老是推荐将同步块的做用范围限制得尽可能小----只在共享数据的实际做用域中才进行同步，这样是为了使得须要同步的操做数尽量变小，若是存在锁竞争，那等待锁的线程也能尽快拿到锁。

大部分状况下，上面的原则都是正确的，可是若是一系列的连续操做都对同一个对象反复加锁和解锁，甚至加锁操做是出如今循环体中的，那即便没有线程竞争，频繁地进行互斥同步操做也会致使没必要要的性能损耗。

若是这么说不够直观，那么想一想某段代码反复使用StringBuffer的append方法拼接字符串的例子吧。