携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第19天，点击查看活动详情

Java锁的膨胀过程以及一致性哈希对锁膨胀的影响

介绍了Java锁的膨胀过程以及一致性哈希对锁膨胀的影响

1、锁优化

在JDK6之前，通过synchronized来实现同步效率是很低的，被synchronized包裹的代码块经过javac编译后，会在代码块前后加上monitorenter和monitorexit字节码指令，被synchronized修饰的方法则会被加上ACC_SYNCHRONIZED标识，不论是在字节码中如何表示，作用和功能都是一样的，线程要想执行同步代码块或同步方法，首先需要竞争锁。

synchronized保证了任意时刻最多只有一个线程可以竞争到锁，那么竞争不到锁的的线程该如何处理呢？

在JDK6之前，Java直接通过OS级别的互斥量(Mutex)来实现同步，获取不到锁的线程被阻塞挂起，直到持有锁的线程释放锁后再将其唤醒，这需要OS频繁的将线程从用户态切换到核心态，这个切换过程开销是很大的，OS需要暂停原线程并保存数据，唤醒新线程并恢复数据，因此synchronized也被称为“重量级锁”。

也正是由于性能原因，开发者慢慢摈弃了synchronized，投入ReentrantLock的怀抱。

官方意识到这个问题以后，便将“高效并发”作为JDK6的一个重要改进项目，经过开发团队的重重优化，如今synchronized的性能已经和ReentrantLock保持在一个数量级了，虽然还是慢一丢丢，但是官方表示未来synchronized仍然有优化的余地。

1.1、锁消除

设计一个类时，考虑到存在并发安全问题，往往会对代码块上锁。
但是有时候这个被设计为“线程安全”的类在使用时压根就不存在多线程竞争，那么还有什么理由加锁呢？

锁消除优化得益于逃逸分析技术的成熟，即时编译器在运行时会对代码进行扫描，会对不存在共享数据竞争的锁消除。
例如：在方法中(栈内存线程私有)实例化一个线程安全的类，该实例既没有传递给其他方法，又没有作为对象返回出去(没有发生逃逸)，那么JVM就会对进行锁消除。

如下代码，尽管StringBuffer的append()是被synchronized修饰的，但是不存在线程竞争，锁会消除。

public String method(){    
StringBuffer sb =  new  StringBuffer(); 
sb.append("1");//append()是被synchronized修饰的

sb.append("2");
return sb.toString();} 

1.2、锁粗化

由于锁的竞争和释放开销比较大，如果代码中对锁进行了频繁的竞争和释放，那么JVM会进行优化，将锁的范围适当扩大。

如下代码，在循环内使用synchronized，JVM锁粗化后，会将锁范围扩大到循环外。

public void method()
{    
for(int  i=  0 ; i <  100; i++) {   
synchronized (this){
}  
}}

1.3、自旋锁

当有多个线程在竞争同一把锁时，竞争失败的线程如何处理？

两种情况：

• 将线程挂起，锁释放后再将其唤醒。
• 线程不挂起，进行自旋，直到竞争成功。

如果锁竞争非常激烈，且短时间得不到释放，那么将线程挂起效率会更高，因为竞争失败的线程不断自旋会造成CPU空转，浪费性能。

如果锁竞争并不激烈，且锁会很快得到释放，那么自旋效率会更高。因为将线程挂起和唤醒是一个开销很大的操作。

自旋锁的优化是针对“锁竞争不激烈，且会很快释放”的场景，避免了OS频繁挂起和唤醒线程。

1.4、自适应自旋锁

当线程竞争锁失败时，自旋和挂起哪一种更高效？

当线程竞争锁失败时，会自旋10次，如果仍然竞争不到锁，说明锁竞争比较激烈，继续自旋会浪费性能，JVM就会将线程挂起。

在JDK6之前，自旋的次数通过JVM参数-XX:PreBlockSpin设置，但是开发者往往不知道该设置多少比较合适，于是在JDK6中，对其进行了优化，加入了“自适应自旋锁”。

自适应自旋锁的大致原理：线程如果自旋成功了，那么下次自旋的最大次数会增加，因为JVM认为既然上次成功了，那么这一次也很大概率会成功。

反之，如果很少会自旋成功，那么下次会减少自旋的次数甚至不自旋，避免CPU空转。

1.5、锁膨胀

除了上述几种优化外，JDK6加入了新型的锁机制，不直接采用OS级的“重量级锁”，锁类型分为：偏向锁、轻量级锁、重量级锁。随着锁竞争的激烈程度不断膨胀，大大提升了竞争不太激烈的同步性能。

“synchronized锁的是对象，而非代码！”

每一个Java对象，在JVM中是存在对象头(Object Header)的，对象头中又分Mark Word和Klass Pointer，其中Mark Word就保存了对象的锁状态信息，其结构如下图所示：

无锁：初始状态
一个对象被实例化后，如果还没有被任何线程竞争锁，那么它就为无锁状态(01)。

偏向锁：单线程竞争
当线程A第一次竞争到锁时，通过CAS操作修改Mark Word中的偏向线程ID、偏向模式。如果不存在其他线程竞争，那么持有偏向锁的线程将永远不需要进行同步。

轻量级锁：多线程竞争，但是任意时刻最多只有一个线程竞争
如果线程B再去竞争锁，发现偏向线程ID不是自己，那么偏向模式就会立刻不可用。即使两个线程不存在竞争关系(线程A已经释放，线程B再去获取)，也会升级为轻量级锁(00)。

重量级锁：同一时刻多线程竞争
一旦轻量级锁CAS修改失败，说明存在多线程同时竞争锁，轻量级锁就不适用了，必须膨胀为重量级锁(10)。此时Mark Word存储的就是指向重量级锁(互斥量)的指针，后面等待锁的线程必须进入阻塞状态。