Java锁的优化

一、自旋锁与自适应自旋（Adaptive Spinning）

自旋锁：由于线程阻塞会引起性能的压力，频繁挂起和恢复线程并不值得，所以我们让请求锁的线程"稍等一会"，看持有锁的线程是否很快释放锁，所以让线程执行一个忙循环（自旋）

自旋锁虽然避免了线程切换的开销，但是它要占用处理器时间，如果占用的短，效果就很好，反之占用时间长，自旋的线程只会白白消耗处理器资源，而且不会做任何有价值的工作，只会带来性能的浪费。但是它也有自旋的限定次数，可以使用参数：-XX: PreBlockSpin来自行更改。

自适应自旋是对自旋锁的优化，意味着自旋的时间不再是固定的了，而是由前一次在同一个锁上的自选时间及锁的拥有者的状态来决定的。例如，一个锁对象在自旋等待中获取到了锁，那么虚拟机则认为这个锁对象会再一次获得，所以会把自旋等待的时间加长。另一方面，对于某个锁很少获取成功，那么很可能忽略的自旋过程。

随着程序运行的时间增长及监控性能信息不断的完善，虚拟机对锁的状况也会越来越准。

二、锁消除（Lock Elimination）

锁消除是指虚拟机即时编译在运行时，对一些代码要求同步，但是对被检测到不可能存在共享数据竞争的锁进行消除。

锁消除的主要判断依据是逃逸分析的数据支持，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把他们当作栈上数据对待，认为他们是线程私有的，同步加锁自然就无需再进行

  public String concatString(String s1, String s2, String s3) {
        return s1 + s2 + s3;
    }

以上代码是一个三个字符串相加的结果，由于String是一个不可变的类，对字符串的连接操作总是通过新的String对象来进行的，因此javac编译器会对String连接做自动优化，在JDK 5以前，字符串会转换为StringBuffer对象的联系 append() 操作，在JDK 5 以后，会转换为 StringBuilder 对象的联系append() 操作
以下是javac转换后的字符串连接操作

 public String concatString(String s1, String s2, String s3) {
        StringBuffer sb = new StringBuffer();
        sb.append(s1);
        sb.append(s2);
        sb.append(s3);
        return sb.toString();
    }

每个StringBuffer.append() 方法中都有一个同步块，经过逃逸分析会发现它的动态作用域限制在concatString() 方法内，所以有锁也会被消除掉。

三、锁粗化（Lock Coarsening）

如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁都是出现在循环体之中，即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。

例如上面的concatString() 方法，我们在在第一个 append() 操作到最后一个append() 操作，只加一次锁就可以了。

四、轻量级锁（Lightweight Locking）

轻量级锁是为了减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

虚拟机对象的内存布局：

HotSpot虚拟机的对象头（Object Header）分为两部分：

1、存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄（Generation GC Age），在32位和64位的Java虚拟机中分别会占用32或64个比特，官方称为Mark Word
2、用于存储指向方法区对象类型数据的指针，如果是数组对象，还会有一个额外的部分用于存储数组长度。

轻量锁的工作过程：

在代码即将进入同步块的时候，如果此同步对象没有被锁定（锁标志位位”01“状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝（官方为Displaced Mark Word），然后虚拟机使用CAS操作尝试把对象的Mark Word更新指向Lock Record 的指针，
这个操作成功了，即代表拥有了这个对象的锁，并且 Mark Word的标志位变为”00“，表示这个对象位轻量级锁定状态。
如果失败了，那意味着至少存在一条线程与当前线程竞争获取该对象的锁。虚拟机首先会检查对象的Mark Word 是否指向当前线程的栈帧，如果是，当前线程已经拥有了这个对象锁，直接进入同步块执行就可以了。否则就是被其他线程抢占了，这时候轻量级锁就不再有效，必须膨胀为重量级锁。锁的标志就变为”10“

在有竞争的情况，轻量级锁比重量级锁更慢，因为除了互斥量本身的开销，还有CAS操作的开销。

五、偏向锁（Biased Locking）

偏向锁就是在无竞争的情况下，把整个同步都消除掉，连CAS都不用做。

偏向锁的这个”偏“，它的意思会偏袒它第一获得它的线程，如果在接下来的执行过程中，该锁一直没有被其他线程获取，则持有偏向锁的线程永远不需要再进行同步。

偏向锁运行过程

在JDK 6中偏向锁是默认开启的（启用参数 -XX: +UseBiased Locking），当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设置为”01“，把偏向模式设置位”1“，表示进入了偏向模式。同时使用CAS操作把获取到这个锁的线程ID记录到对象的Mark Word之中，如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如加锁、解锁及对Mark Word的更新操作）
如果有出现另外一个线程尝试获取这个锁的情况，偏向模式马上宣告结束，并且偏向模式设置为”0“，标志位为”01“（未锁定）或者标志位为”00“（轻量级锁定）

原来对象头中的HashCode怎么办？

当对象进入偏向模式的时候，Mark Word大部分空间（23bit）都用于存储持有锁的线程ID，因此当一个对象已经计算过一致性哈希码后，也就无法进入偏向锁状态；当一个对象当前正处于偏向模式，又收到需要计算一致性哈希码请求时，他的偏向状态会立即撤销，并且会膨胀为重量级锁。