皆さんこんにちは、イーアンです！今日は、同期された同期ロックの最適化について話しましょう。
並行プログラミングでは、複数のスレッドが同じ共有リソースにアクセスする場合、データの原子性を維持する方法を考慮する必要があります。JDK1.5 より前は、Java は Synchronized キーワードに依存して、これを行うロック機能を実装していました。Synchronized は JVM によって実装される組み込みロックであり、ロックの取得と解放は JVM によって暗黙的に実装されます。
JDK1.5版では、ロック機能を実装するためにコンカレントパッケージにLockインターフェースが追加されており、Synchronizedキーワードと同様の同期機能を提供しますが、使用時には明示的にロックの取得と解放を行う必要があります。
Lock 同期ロックは Java に基づいて実装され、Synchronized は基盤となるオペレーティング システムの Mutex Lock に基づいて実装されます. ロック操作の取得と解放のたびに、ユーザー モードとカーネル モードの切り替えが発生し、システム パフォーマンスのオーバーヘッドが増加します。そのため、激しいロック競合の場合、Synchronized 同期ロックはパフォーマンスの点で非常に悪く、重量ロックと呼ばれることがよくあります。
特に単一のスレッドが繰り返しロックを申請する場合、JDK1.5 版の Synchronized ロックのパフォーマンスは Lock のパフォーマンスよりもはるかに悪くなります。たとえば、Dubbo が Netty をベースに実装した通信では、コンシューマーがサーバーと通信した後、返信メッセージの受信が非同期であるため、返信情報をポーリングして監視するスレッドが必要です。メッセージを受信するときは、リクエスト セッションの原子性を確保するためにロックが必要です。ここで Synchronized 同期ロックを使用すると、同じスレッドがロック リソースを要求するたびに、ユーザー モードとカーネル モードの切り替えが発生します。
Java は JDK1.6 バージョン以降、Synchronized 同期ロックを完全に最適化しており、一部のシナリオでも、そのパフォーマンスは Lock 同期ロックを上回っています。今日は、同期化された同期ロックがパフォーマンスの向上を達成するために通過した最適化を見ていきます。
同期同期ロックの実装原理
Synchronized 同期ロックの最適化を理解する前に、その基本的な実装原理を見てみましょう。これは、次の内容をよりよく理解するのに役立ちます。
通常、Synchronized で同期ロックを実装するには 2 つの方法があります。1 つはメソッドを変更する方法で、もう 1 つはメソッド ブロックを変更する方法です。以下は、Synchronized によって実装された 2 つの同期方法をロックする方法です。
// 关键字在实例方法上，锁为当前实例
public synchronized void method1() {
// code
}
// 关键字在代码块上，锁为括号里面的对象
public void method2() {
Object o = new Object();
synchronized (o) {
// code
}
}
次に、逆コンパイルによって特定のバイトコードの実装を確認し、次の逆コンパイル コマンドを実行して必要なバイトコードを出力します。
javac -encoding UTF-8 SyncTest.java //先运行编译class文件命令
javap -v SyncTest.class //再通过javap打印出字节文件
出力バイトコードから、Synchronized が同期コード ブロックを変更すると、monitorenter および monitorexit 命令によって同期されることがわかります。monitorenter 命令に入ると、スレッドは Monitor オブジェクトを保持し、monitorenter 命令を終了すると、スレッドは Monitor オブジェクトを解放します。
public void method2();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=2, locals=4, args_size=1
0: new #2
3: dup
4: invokespecial #1
7: astore_1
8: aload_1
9: dup
10: astore_2
11: monitorenter //monitorenter 指令
12: aload_2
13: monitorexit //monitorexit 指令
14: goto 22
17: astore_3
18: aload_2
19: monitorexit
20: aload_3
21: athrow
22: return
Exception table:
from to target type
12 14 17 any
17 20 17 any
LineNumberTable:
line 18: 0
line 19: 8
line 21: 12
line 22: 22
StackMapTable: number_of_entries = 2
frame_type = 255 /* full_frame */
offset_delta = 17
locals = [ class com/demo/io/SyncTest, class java/lang/Object, class java/lang/Object ]
stack = [ class java/lang/Throwable ]
frame_type = 250 /* chop */
offset_delta = 4
次の同期メソッドのバイトコードをもう一度見ると、Synchronized が同期メソッドを変更するときに、monitorenter および monitorexit 命令が見つからず、ACC_SYNCHRONIZED フラグが表示されることがわかります。
これは、JVM が ACC_SYNCHRONIZED アクセス フラグを使用して、メソッドが同期メソッドかどうかを区別するためです。メソッドが呼び出されると、call 命令は、メソッドに ACC_SYNCHRONIZED アクセス フラグが設定されているかどうかをチェックします。このフラグが設定されている場合、実行スレッドは、メソッドを実行する前に、まず Monitor オブジェクトを保持します。このメソッドの実行中、他のスレッドは Monitor オブジェクトを取得できず、メソッドの実行が完了すると Monitor オブジェクトは解放されます。
public synchronized void method1();
descriptor: ()V
flags: ACC_PUBLIC, ACC_SYNCHRONIZED // ACC_SYNCHRONIZED 标志
Code:
stack=0, locals=1, args_size=1
0: return
LineNumberTable:
line 8: 0
上記のソース コードを使用して、Synchronized 変更メソッドがロックの原則を実装する方法を見てみましょう。
JVM での同期は、Monitor オブジェクトの開始と終了に基づいています。各オブジェクト インスタンスには、オブジェクトと一緒に作成および破棄できる Monitor があります。次のように、Monitor は ObjectMonitor によって実装され、ObjectMonitor は C++ の ObjectMonitor.hpp ファイルによって実装されます。
ObjectMonitor() {
_header = NULL;
_count = 0; //记录个数
_waiters = 0,
_recursions = 0;
_object = NULL;
_owner = NULL;
_WaitSet = NULL; //处于wait状态的线程，会被加入到_WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ; //处于等待锁block状态的线程，会被加入到该列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
}
当多个线程同时访问一段同步代码时，多个线程会先被存放在ContentionList和_EntryList 集合中，处于block状态的线程，都会被加入到该列表。接下来当线程获取到对象的Monitor时，Monitor是依靠底层操作系统的Mutex Lock来实现互斥的，线程申请Mutex成功，则持有该Mutex，其它线程将无法获取到该Mutex，竞争失败的线程会再次进入ContentionList被挂起。
如果线程调用wait() 方法，就会释放当前持有的Mutex，并且该线程会进入WaitSet集合中，等待下一次被唤醒。如果当前线程顺利执行完方法，也将释放Mutex。
看完上面的讲解，相信你对同步锁的实现原理已经有个深入的了解了。总结来说就是，同步锁在这种实现方式中，因Monitor是依赖于底层的操作系统实现，存在用户态与内核态之间的切换，所以增加了性能开销。
锁升级优化
为了提升性能，JDK1.6引入了偏向锁、轻量级锁、重量级锁概念，来减少锁竞争带来的上下文切换，而正是新增的Java对象头实现了锁升级功能。
当Java对象被Synchronized关键字修饰成为同步锁后，围绕这个锁的一系列升级操作都将和Java对象头有关。
Java对象头
在JDK1.6 JVM中，对象实例在堆内存中被分为了三个部分：对象头、实例数据和对齐填充。其中Java对象头由Mark Word、指向类的指针以及数组长度三部分组成。
Mark Word记录了对象和锁有关的信息。Mark Word在64位JVM中的长度是64bit，我们可以一起看下64位JVM的存储结构是怎么样的。如下图所示：
锁升级功能主要依赖于Mark Word中的锁标志位和释放偏向锁标志位，Synchronized同步锁就是从偏向锁开始的，随着竞争越来越激烈，偏向锁升级到轻量级锁，最终升级到重量级锁。下面我们就沿着这条优化路径去看下具体的内容。
1.偏向锁
偏向锁主要用来优化同一线程多次申请同一个锁的竞争。在某些情况下，大部分时间是同一个线程竞争锁资源，例如，在创建一个线程并在线程中执行循环监听的场景下，或单线程操作一个线程安全集合时，同一线程每次都需要获取和释放锁，每次操作都会发生用户态与内核态的切换。
偏向锁的作用就是，当一个线程再次访问这个同步代码或方法时，该线程只需去对象头的Mark Word中去判断一下是否有偏向锁指向它的ID，无需再进入Monitor去竞争对象了。 当对象被当做同步锁并有一个线程抢到了锁时，锁标志位还是01，“是否偏向锁”标志位设置为1，并且记录抢到锁的线程ID，表示进入偏向锁状态。
一旦出现其它线程竞争锁资源时，偏向锁就会被撤销。偏向锁的撤销需要等待全局安全点，暂停持有该锁的线程，同时检查该线程是否还在执行该方法，如果是，则升级锁，反之则被其它线程抢占。
下图中红线流程部分为偏向锁获取和撤销流程：
因此，在高并发场景下，当大量线程同时竞争同一个锁资源时，偏向锁就会被撤销，发生stop the word后， 开启偏向锁无疑会带来更大的性能开销，这时我们可以通过添加JVM参数关闭偏向锁来调优系统性能，示例代码如下：
-XX:-UseBiasedLocking //关闭偏向锁（默认打开）
或
-XX:+UseHeavyMonitors //设置重量级锁
2.轻量级锁
当有另外一个线程竞争获取这个锁时，由于该锁已经是偏向锁，当发现对象头Mark Word中的线程ID不是自己的线程ID，就会进行CAS操作获取锁，如果获取成功，直接替换Mark Word中的线程ID为自己的ID，该锁会保持偏向锁状态；如果获取锁失败，代表当前锁有一定的竞争，偏向锁将升级为轻量级锁。
轻量级锁适用于线程交替执行同步块的场景，绝大部分的锁在整个同步周期内都不存在长时间的竞争。
下图中红线流程部分为升级轻量级锁及操作流程：
3.自旋锁与重量级锁
轻量级锁CAS抢锁失败，线程将会被挂起进入阻塞状态。如果正在持有锁的线程在很短的时间内释放资源，那么进入阻塞状态的线程无疑又要申请锁资源。
JVM提供了一种自旋锁，可以通过自旋方式不断尝试获取锁，从而避免线程被挂起阻塞。这是基于大多数情况下，线程持有锁的时间都不会太长，毕竟线程被挂起阻塞可能会得不偿失。
从JDK1.7开始，自旋锁默认启用，自旋次数由JVM设置决定，这里我不建议设置的重试次数过多，因为CAS重试操作意味着长时间地占用CPU。
自旋锁重试之后如果抢锁依然失败，同步锁就会升级至重量级锁，锁标志位改为10。在这个状态下，未抢到锁的线程都会进入Monitor，之后会被阻塞在_WaitSet队列中。
下图中红线流程部分为自旋后升级为重量级锁的流程：
在锁竞争不激烈且锁占用时间非常短的场景下，自旋锁可以提高系统性能。一旦锁竞争激烈或锁占用的时间过长，自旋锁将会导致大量的线程一直处于CAS重试状态，占用CPU资源，反而会增加系统性能开销。所以自旋锁和重量级锁的使用都要结合实际场景。
在高负载、高并发的场景下，我们可以通过设置JVM参数来关闭自旋锁，优化系统性能，示例代码如下：
-XX:-UseSpinning //参数关闭自旋锁优化(默认打开)
-XX:PreBlockSpin //参数修改默认的自旋次数。JDK1.7后，去掉此参数，由jvm控制
动态编译实现锁消除/锁粗化
除了锁升级优化，Java还使用了编译器对锁进行优化。JIT 编译器在动态编译同步块的时候，借助了一种被称为逃逸分析的技术，来判断同步块使用的锁对象是否只能够被一个线程访问，而没有被发布到其它线程。
确认是的话，那么 JIT 编译器在编译这个同步块的时候不会生成 synchronized 所表示的锁的申请与释放的机器码，即消除了锁的使用。在 Java7 之后的版本就不需要手动配置了，该操作可以自动实现。
锁粗化同理，就是在 JIT 编译器动态编译时，如果发现几个相邻的同步块使用的是同一个锁实例，那么 JIT 编译器将会把这几个同步块合并为一个大的同步块，从而避免一个线程“反复申请、释放同一个锁”所带来的性能开销。
减小锁粒度
除了锁内部优化和编译器优化之外，我们还可以通过代码层来实现锁优化，减小锁粒度就是一种惯用的方法。
当我们的锁对象是一个数组或队列时，集中竞争一个对象的话会非常激烈，锁也会升级为重量级锁。我们可以考虑将一个数组和队列对象拆成多个小对象，来降低锁竞争，提升并行度。
最经典的减小锁粒度的案例就是JDK1.8之前实现的ConcurrentHashMap版本。我们知道，HashTable是基于一个数组+链表实现的，所以在并发读写操作集合时，存在激烈的锁资源竞争，也因此性能会存在瓶颈。而ConcurrentHashMap就很很巧妙地使用了分段锁Segment来降低锁资源竞争，如下图所示：
总结
JVM在JDK1.6中引入了分级锁机制来优化Synchronized，当一个线程获取锁时，首先对象锁将成为一个偏向锁，这样做是为了优化同一线程重复获取导致的用户态与内核态的切换问题；其次如果有多个线程竞争锁资源，锁将会升级为轻量级锁，它适用于在短时间内持有锁，且分锁有交替切换的场景；轻量级锁还使用了自旋锁来避免线程用户态与内核态的频繁切换，大大地提高了系统性能；但如果锁竞争太激烈了，那么同步锁将会升级为重量级锁。
减少锁竞争，是优化Synchronized同步锁的关键。我们应该尽量使Synchronized同步锁处于轻量级锁或偏向锁，这样才能提高Synchronized同步锁的性能；通过减小锁粒度来降低锁竞争也是一种最常用的优化方法；另外我们还可以通过减少锁的持有时间来提高Synchronized同步锁在自旋时获取锁资源的成功率，避免Synchronized同步锁升级为重量级锁。
如果本文对你有帮助的话，欢迎点赞分享，这对我继续分享&创作优质文章非常重要。感谢 ！
本文由 mdnice 多平台发布