1 概念

synchronized 块是 Java提供的一种原子性内置锁, Javva中的每个对象都可以把它当作同步锁来使用 这些 Java内置的使用者看不到的锁被称为内部锁,也叫作监视器锁。线程的执行代码在进入 synchronized 代码块前会自动获取内部锁,这时候其他线程访问该同步代码块时会被阻塞挂起。拿到内部锁的线程会在正常退出同步代码块或者抛出异常后或者在同步块内调用了该内置锁资源wait系列方法时释放该内置锁。内置锁是排它锁 ,就是当一 线程获取这个锁后 其他线程必须等待该线程释放锁后才能获取该锁。

示例:

  1. public class SynchronizedTest {
  2. public static void main(String[] args) throws InterruptedException {
  3. ThreadNOtSafeTest notSafe = new ThreadNOtSafeTest();
  4. Thread t1_notSafe = new Thread(notSafe);
  5. Thread t2_notSafe = new Thread(notSafe);
  6. System.out.println("--------------线程非安全类测试-------------");
  7. t1_notSafe.start();
  8. t2_notSafe.start();
  9. t1_notSafe.join();//控制线程执行顺序
  10. t2_notSafe.join();
  11. System.out.println("--------------同实例线程安全类测试-------------");
  12. ThreadSafeTest safe = new ThreadSafeTest();
  13. Thread t1_safe = new Thread(safe);
  14. Thread t2_safe = new Thread(safe);
  15. t1_safe.start();
  16. t2_safe.start();
  17. t1_safe.join();
  18. t2_safe.join();
  19. System.out.println("--------------不同实例线程安全类测试-------------");
  20. Thread t1_safe_new = new Thread(new ThreadSafeTest());
  21. Thread t2_safe_new = new Thread(new ThreadSafeTest());
  22. t1_safe_new.start();
  23. t2_safe_new.start();
  24. t1_safe_new.join();
  25. t2_safe_new.join();
  26. System.out.println("-----------静态方法线程安全测试----------------");
  27. Thread t1_staticSafe = new Thread(new StaticThreadSafeTest());
  28. Thread t2_staticSafe = new Thread(new StaticThreadSafeTest());
  29. t1_staticSafe.start();
  30. t2_staticSafe.start();
  31. t1_staticSafe.join();
  32. t2_staticSafe.join();
  33. }
  34. }
  35. class ThreadNOtSafeTest implements Runnable {
  36. volatile int num = 0;
  37. void increase() {
  38. for (int i = 0; i < 10000000; i++, num++) ;
  39. System.out.println(this.getClass().getName() + " " + Thread.currentThread().getName() + " num:" + num);
  40. }
  41. @Override
  42. public void run() {
  43. increase();
  44. }
  45. }
  46. class ThreadSafeTest implements Runnable {
  47. volatile int num = 0;
  48. synchronized void increase() {
  49. for (int i = 0; i < 10000000; i++, num++) ;
  50. System.out.println(this.getClass().getName() + " " + Thread.currentThread().getName() + " num:" + num);
  51. }
  52. @Override
  53. public void run() {
  54. increase();
  55. }
  56. }
  57. class StaticThreadSafeTest implements Runnable {
  58. static volatile int num = 0;
  59. static synchronized void increase() {
  60. for (int i = 0; i < 10000000; i++, num++) ;
  61. System.out.println(StaticThreadSafeTest.class.getName() + " " + Thread.currentThread().getName() + " num:" + num);
  62. }
  63. @Override
  64. public void run() {
  65. increase();
  66. }
  67. }

输出:

  1. --------------线程非安全类测试-------------
  2. com.tools.threadDemo.sync.ThreadNOtSafeTest Thread-1 num:10469988
  3. com.tools.threadDemo.sync.ThreadNOtSafeTest Thread-0 num:11599593
  4. --------------同实例线程安全类测试-------------
  5. com.tools.threadDemo.sync.ThreadSafeTest Thread-2 num:10000000
  6. com.tools.threadDemo.sync.ThreadSafeTest Thread-3 num:20000000
  7. --------------不同实例线程安全类测试-------------
  8. com.tools.threadDemo.sync.ThreadSafeTest Thread-5 num:10000000
  9. com.tools.threadDemo.sync.ThreadSafeTest Thread-4 num:10000000
  10. -----------静态方法线程安全测试----------------
  11. com.tools.threadDemo.sync.StaticThreadSafeTest Thread-6 num:10000000
  12. com.tools.threadDemo.sync.StaticThreadSafeTest Thread-7 num:20000000

2 实现原理

2.1 同步代码块

  1. public class synchronizedTest2 implements Runnable {
  2. private Integer num = 0;
  3. static synchronizedTest2 test2 = new synchronizedTest2();
  4. public static void main(String[] args) {
  5. Thread t = new Thread(test2);
  6. Thread t2 = new Thread(test2);
  7. Thread t3 = new Thread(test2);
  8. Thread t4 = new Thread(test2);
  9. Thread t5 = new Thread(test2);
  10. t.start();
  11. t2.start();
  12. t3.start();
  13. t4.start();
  14. t5.start();
  15. }
  16. @Override
  17. public void run() {
  18. synchronized (this) {
  19. for (int i = 0; i < 10000; i++) {
  20. num++;
  21. }
  22. System.out.println(num);
  23. }
  24. }
  25. }

image.png
image.png
image.png
代码块的同步是利用monitorenter和monitorexit这两个字节码指令。它们分别位于同步代码块的开始和结束位置。当jvm执行到monitorenter指令时,当前线程试图获取monitor对象的所有权,如果未加锁或者已经被当前线程所持有,就把锁的计数器+1;当执行monitorexit指令时,锁计数器-1;当锁计数器为0时,该锁就被释放了。如果获取monitor对象失败,该线程则会进入阻塞状态,直到其他线程释放锁。
在Java虚拟机(HotSpot)中,monitor是由ObjectMonitor实现的,其主要数据结构如下(位于HotSpot虚拟机源码ObjectMonitor.hpp文件,C++实现的)。

  1. ObjectMonitor() {
  2. _header = NULL;
  3. _count = 0; //记录个数
  4. _waiters = 0,
  5. _recursions = 0;
  6. _object = NULL;
  7. _owner = NULL;
  8. _WaitSet = NULL; //处于wait状态的线程,会被加入到_WaitSet
  9. _WaitSetLock = 0 ;
  10. _Responsible = NULL ;
  11. _succ = NULL ;
  12. _cxq = NULL ;
  13. FreeNext = NULL ;
  14. _EntryList = NULL ; //处于等待锁block状态的线程,会被加入到该列表
  15. _SpinFreq = 0 ;
  16. _SpinClock = 0 ;
  17. OwnerIsThread = 0 ;
  18. }

bjectMonitor中有两个队列,_WaitSet 和 _EntryList,用来保存ObjectWaiter对象列表( 每个等待锁的线程都会被封装成ObjectWaiter对象),_owner指向持有ObjectMonitor对象的线程,当多个线程同时访问一段同步代码时,首先会进入 _EntryList 集合,当线程获取到对象的monitor 后进入 _Owner 区域并把monitor中的owner变量设置为当前线程同时monitor中的计数器count加1,若线程调用 wait() 方法,将释放当前持有的monitor,owner变量恢复为null,count自减1,同时该线程进入 WaitSe t集合中等待被唤醒。若当前线程执行完毕也将释放monitor(锁)并复位变量的值,以便其他线程进入获取monitor(锁)。

2.2 同步方法

  1. public class SyncMethod {
  2. public int i;
  3. public synchronized void syncTask() {
  4. i++;
  5. }
  6. }

查看字节码:

  1. Classfile /E:/demo/spring/src/main/java/com/tools/threadDemo/sync/SyncMethod.class
  2. Last modified 2021-10-9; size 310 bytes
  3. MD5 checksum ab18a869acc9a6c55d2d293e3de1c61b
  4. Compiled from "SyncMethod.java"
  5. public class com.tools.threadDemo.sync.SyncMethod
  6. minor version: 0
  7. major version: 52
  8. flags: ACC_PUBLIC, ACC_SUPER
  9. Constant pool:
  10. #1 = Methodref #4.#14 // java/lang/Object."<init>":()V
  11. #2 = Fieldref #3.#15 // com/tools/threadDemo/sync/SyncMethod.i:I
  12. #3 = Class #16 // com/tools/threadDemo/sync/SyncMethod
  13. #4 = Class #17 // java/lang/Object
  14. #5 = Utf8 i
  15. #6 = Utf8 I
  16. #7 = Utf8 <init>
  17. #8 = Utf8 ()V
  18. #9 = Utf8 Code
  19. #10 = Utf8 LineNumberTable
  20. #11 = Utf8 syncTask
  21. #12 = Utf8 SourceFile
  22. #13 = Utf8 SyncMethod.java
  23. #14 = NameAndType #7:#8 // "<init>":()V
  24. #15 = NameAndType #5:#6 // i:I
  25. #16 = Utf8 com/tools/threadDemo/sync/SyncMethod
  26. #17 = Utf8 java/lang/Object
  27. {
  28. public int i;
  29. descriptor: I
  30. flags: ACC_PUBLIC
  31. public com.tools.threadDemo.sync.SyncMethod();
  32. descriptor: ()V
  33. flags: ACC_PUBLIC
  34. Code:
  35. stack=1, locals=1, args_size=1
  36. 0: aload_0
  37. 1: invokespecial #1 // Method java/lang/Object."<init>":()V
  38. 4: return
  39. LineNumberTable:
  40. line 3: 0
  41. public synchronized void syncTask();
  42. descriptor: ()V
  43. //方法标识ACC_PUBLIC代表public修饰,ACC_SYNCHRONIZED指明该方法为同步方法
  44. flags: ACC_PUBLIC, ACC_SYNCHRONIZED
  45. Code:
  46. stack=3, locals=1, args_size=1
  47. 0: aload_0
  48. 1: dup
  49. 2: getfield #2 // Field i:I
  50. 5: iconst_1
  51. 6: iadd
  52. 7: putfield #2 // Field i:I
  53. 10: return
  54. LineNumberTable:
  55. line 8: 0
  56. line 9: 10
  57. }
  58. SourceFile: "SyncMethod.java"

从字节码中可以看出,synchronized修饰的方法并没有monitorenter指令和monitorexit指令,取得代之的确实是ACC_SYNCHRONIZED标识,该标识指明了该方法是一个同步方法,JVM通过该ACC_SYNCHRONIZED访问标志来辨别一个方法是否声明为同步方法,从而执行相应的同步调用。这便是synchronized锁在同步代码块和同步方法上实现的基本原理。
同时我们还必须注意到的是在Java早期版本中,synchronized属于重量级锁,效率低下,因为监视器锁(monitor)是依赖于底层的操作系统的Mutex Lock来实现的,而操作系统实现线程之间的切换时需要从用户态转换到核心态,这个状态之间的转换需要相对比较长的时间,时间成本相对较高,这也是为什么早期的synchronized效率低的原因。庆幸的是在Java 6之后Java官方对从JVM层面对synchronized较大优化,所以现在的synchronized锁效率也优化得很不错了,Java 6之后,为了减少获得锁和释放锁所带来的性能消耗,引入了轻量级锁和偏向锁,接下来我们将简单了解一下Java官方在JVM层面对synchronized锁的优化。

2.3 Java对象头

像我们上面所提到的monitor监视器对象存在于Java对象的对象头Mark Word中,什么是Java对象头的Mark Word了?
这就跟Java对象在JVM中的内存布局有关系,Java对象在JVM内存中分为三块区域:对象头,实例数据和对齐填充。
对象头:对象头又包含以下部分:Mark Word, 类型指针,如果对象是数组的话,还会存在一个数据数组长度,用来记录数据长度。其中Mark Word又包含:哈希码(HashCode),GC分代年龄,锁状态标志,线程持有的锁等信息。
实例数据:这部分是对象真正存储的有效信息,也就是我们在程序中所定义的各种类型的字段内容。
对齐填充:这部分数据并不是必然存在的,JVM内存管理系统要求我们定义的对象大小必须是8字节的整数倍,如果对象大小不是整数倍,这时就会有对齐填充这块数据,来将对象大小补全成为8字节的整数倍
image.png
JDK对synchronized关键字的优化都是基于对象头中的Mark Word进行优化的,当对象被不同数量线程去竞争时,这是对象的锁状态会发生改变,来标识这时对象处于一个无锁,偏向锁,轻量级锁和重量级锁状态。

3 Java虚拟机对synchronized的优化

高效并发是从JDK 5升级到JDK 6后一项重要的改进项,HotSpot虚拟机开发团队在这个版本上花费了大量的资源去实现各种锁优化技术,如适应性自旋(Adaptive Spinning)、锁消除(Lock Elimination)、锁膨胀(Lock Coarsening)、轻量级锁(Lightweight Locking)、偏向锁(Biased Locking)等,这些技术都是为了在线程之间更高效地共享数据及解决竞争问题,从而提高程序的执行效率。

3.1 自旋锁与自适应自旋

  1. 现在绝大多数的个人电脑和服务器都是多路(核)处理器系统,如果物理机器有一个以上的处理器或者处理器核心,能让两个或以上的线程同时并行执行,我们就可以让后面请求锁的那个线程“稍等一会”,但不放弃处理器的执行时间,看看持有锁的线程是否很快就会释放锁。为了让线程等待,我们只须让线程执行一个忙循环(自旋),这项技术就是所谓的自旋锁。 <br /> 自旋锁在JDK 1.4.2中就已经引入,只不过默认是关闭的,可以使用-XX:+UseSpinning参数来开启,在JDK 6中就已经改为默认开启了。自旋等待不能代替阻塞,且先不说对处理器数量的要求,自旋等待本身虽然避免了线程切换的开销,但它是要占用处理器时间的,所以如果锁被占用的时间很短,自旋等待的效果就会非常好,反之如果锁被占用的时间很长,那么自旋的线程只会白白消耗处理器资源,而不会做任何有价值的工作,这就会带来性能的浪费。因此自旋等待的时间必须有一定的限度,如果自旋超过了限定的次数仍然没有成功获得锁,就应当使用传统的方式去挂起线程。自旋次数的默认值是十次,用户也可以使用参数-XXPreBlockSpin来自行更改。 <br /> 不过无论是默认值还是用户指定的自旋次数,对整个Java虚拟机中所有的锁来说都是相同的。在JDK 6中对自旋锁的优化,引入了自适应的自旋。自适应意味着自旋的时间不再是固定的了,而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。如果在同一个锁对象上,自旋等待刚刚成功获得过锁,并且持有锁的线程正在运行中,那么虚拟机就会认为这次自旋也很有可能再次成功,进而允许自旋等待持续相对更长的时间,比如持续100次忙循环。另一方面,如果对于某个锁,自旋很少成功获得过锁,那在以后要获取这个锁时将有可能直接省略掉自旋过程,以避免浪费处理器资源。有了自适应自旋,随着程序运行时间的增长及性能监控信息的不断完善,虚拟机对程序锁的状况预测就会越来越精准,虚拟机就会变得越来越“聪明”了。

3.2 锁消除

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

  1. public String concatString(String s1, String s2, String s3) {
  2. StringBuffer sb = new StringBuffer();
  3. sb.append(s1);
  4. sb.append(s2);
  5. sb.append(s3);
  6. return sb.toString();
  7. }

现在大家还认为这段代码没有涉及同步吗?每个StringBuffer.append()方法中都有一个同步块,锁就是sb对象。虚拟机观察变量sb,经过逃逸分析后会发现它的动态作用域被限制在concatString()方法内部。也就是sb的所有引用都永远不会逃逸到concatString()方法之外,其他线程无法访问到它,所以这里虽然有锁,但是可以被安全地消除掉。在解释执行时这里仍然会加锁,但在经过服务端编译器的即时编译之后,这段代码就会忽略所有的同步措施而直接执行。

3.3 锁粗化

原则上,我们在编写代码的时候,总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步,这样是为了使得需要同步的操作数量尽可能变少,即使存在锁竞争,等待锁的线程也能尽可能快地拿到锁。
大多数情况下,上面的原则都是正确的,但是如果一系列的连续操作都对同一个对象反复加锁和解锁,甚至加锁操作是出现在循环体之中的,那即使没有线程竞争,频繁地进行互斥同步操作也会导致不必要的性能损耗。
下列代码所示连续的append()方法就属于这类情况。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁,将会把加锁同步的范围扩展(粗化)到整个操作序列的外部,以下代码为例,就是扩展到第一个append()操作之前直至最后一个append()操作之后,这样只需要加锁一次就可以了。

  1. public String concatString(String s1, String s2, String s3) {
  2. StringBuffer sb = new StringBuffer();
  3. sb.append(s1);
  4. sb.append(s2);
  5. sb.append(s3);
  6. return sb.toString();
  7. }

3.4 轻量级锁

轻量级锁是JDK 6时加入的新型锁机制,它名字中的“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的,因此传统的锁机制就被称为“重量级”锁。不过,需要强调一点,轻量级锁并不是用来代替重量级锁的,它设计的初衷是在没有多线程竞争的前提下,减少传统的重量级锁使用操作系统互斥量产生的性能消耗。
HotSpot虚拟机的对象头(Object Header)分为两部分,第一部分用于存储对象自身的运行时数据,如哈希码(HashCode)、GC分代年龄(Generational GC Age)等。这部分数据的长度在32位和64位的Java虚拟机中分别会占用32个或64个比特,官方称它为“Mark Word”。这部分是实现轻量级锁和偏向锁的关键。另外一部分用于存储指向方法区对象类型数据的指针,如果是数组对象,还会有一个额外的部分用于存储数组长度。
HotSpot虚拟机对象头Mark Word
image.png
在代码即将进入同步块的时候,如果此同步对象没有被锁定(锁标志位为“01”状态),虚拟机首先将在当前线程的栈帧中建立一个名为锁记录(Lock Record)的空间,用于存储锁对象目前的Mark Word的拷贝。
然后,虚拟机将使用CAS操作尝试把对象的Mark Word更新为指向Lock Record的指针。如果这个更新动作成功了,即代表该线程拥有了这个对象的锁,并且对象Mark Word的锁标志位(Mark Word的最后两个比特)将转变为“00”,表示此对象处于轻量级锁定状态。
如果这个更新操作失败了,那就意味着至少存在一条线程与当前线程竞争获取该对象的锁。虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧,如果是,说明当前线程已经拥有了这个对象的锁,那直接进入同步块继续执行就可以了,否则就说明这个锁对象已经被其他线程抢占了。如果出现两条以上的线程争用同一个锁的情况,那轻量级锁就不再有效,必须要膨胀为重量级锁,锁标志的状态值变为“10”,此时Mark Word中存储的就是指向重量级锁(互斥量)的指针,后面等待锁的线程也必须进入阻塞状态。

上面描述的是轻量级锁的加锁过程,它的解锁过程也同样是通过CAS操作来进行的,如果对象的Mark Word仍然指向线程的锁记录,那就用CAS操作把对象当前的Mark Word和线程中复制的Displaced Mark Word替换回来。假如能够成功替换,那整个同步过程就顺利完成了;如果替换失败,则说明有其他线程尝试过获取该锁,就要在释放锁的同时,唤醒被挂起的线程。

3.5 偏向锁

偏向锁也是JDK 6中引入的一项锁优化措施,它的目的是消除数据在无竞争情况下的同步原语,进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量,那偏向锁就是在无竞争的情况下把整个同步都消除掉,连CAS操作都不去做了。
假设当前虚拟机启用了偏向锁(启用参数-XX:+UseBiased Locking,这是自JDK 6起HotSpot虚拟机的默认值),那么当锁对象第一次被线程获取的时候,虚拟机将会把对象头中的标志位设置为“01”、把偏向模式设置为“1”,表示进入偏向模式。同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中。如果CAS操作成功,持有偏向锁的线程以后每次进入这个锁相关的同步块时,虚拟机都可以不再进行任何同步操作(例如加锁、解锁及对Mark Word的更新操作 等)。
一旦出现另外一个线程去尝试获取这个锁的情况,偏向模式就马上宣告结束。根据锁对象目前是否处于被锁定的状态决定是否撤销偏向(偏向模式设置为“0”),撤销后标志位恢复到未锁定(标志位为“01”)或轻量级锁定(标志位为“00”)的状态,后续的同步操作就按照上面介绍的轻量级锁那样去执行。偏向锁、轻量级锁的状态转化及对象Mark Word的关系如图所示。
image.png
偏向锁可以提高带有同步但无竞争的程序性能,但它同样是一个带有效益权衡(Trade Off)性质的优化,也就是说它并非总是对程序运行有利。如果程序中大多数的锁都总是被多个不同的线程访问,那偏向模式就是多余的。在具体问题具体分析的前提下,有时候使用参数-XX:-UseBiasedLocking来禁止偏向锁优化反而可以提升性能。