synchronized原理以及锁优化
https://blog.csdn.net/weixin_41563161/article/details/103869694
https://blog.csdn.net/weixin_41563161/article/details/102458297
1 概述
synchronized 是 java 中最常用的保证线程安全的方式，synchronized 的作用主要有三方面：
-
确保线程互斥的访问代码块，同一时刻只有一个方法可以进入到临界区
-
保证共享变量的修改能及时可见
语义上来讲，synchronized主要有三种用法：
-
修饰普通方法，锁的是当前对象实例（this）
-
修饰静态方法，锁的是当前 Class 对象（静态方法是属于类，而不是对象）
-
修饰代码块，锁的是括号里的对象
public class SynTest {
private static List<String> list = new ArrayList<String>();
//当前实例的锁
public synchronized void add1(String s){
list.add(s);
}
//SynTest.class 锁
public static synchronized void add2(String s){
list.add(s);
}
//SynTest.class 锁
public void add3(String s){
synchronized(SynTest.class){
list.add(s);
}
}
//当前实例的锁
public void add4(String s){
synchronized(this){
list.add(s);
}
}
}普通同步方法，锁是当前实例对象
add1 方法是synchronized的第一种用法，因为它是普通同步方法，所以获取当前实例的锁。
add2 方法是synchronized的第二种用法，因为它是静态同步方法，所以获取SynTest.class的锁。
add3 方法是synchronized的第三种用法。指定锁：SynTest.class。
add4 方法是synchronized的第三种用法。指定锁：this（当前实例）。
结论：
add1和add4方法的锁都是 当前实例，所以add1和add4 可以实现方法互斥
add2和add3方法的锁都是SynTest.class，所以add2和add3可以实现方法互斥。
**注意：**add1和add2两个synchronized是不互斥的，因为他们不是同一把锁。只有同一把锁才会互斥。
2. 实现原理
2.1监视器锁
synchronized英[ˈsɪŋkrənaɪzd] 同步代码块的语义底层是基于对象内部的监视器锁（monitor），分别是使用 monitorenter 和 monitorexit 指令完成。其实 wait/notify 也依赖于 monitor 对象，所以其一般要在 synchronized 同步的方法或代码块内使用。monitorenter 指令在编译为字节码后插入到同步代码块的开始位置，monitorexit 指令在编译为字节码后插入到方法结束处和异常处。JVM 要保证每个 monitorenter 必须有对应的 moniorexit。
monitorenter：每个对象都有一个监视器锁（monitor），当 monitor 被某个线程占用时就会处于锁定状态，线程执行 monitorenter 指令时尝试获得 monitor 的所有权，即尝试获取对象的锁。过程如下：
-
如果 monitor 的进入数为0，则该线程进入 monitor，然后将进入数设置为1，该线程即为 monitor 的所有者；
-
如果线程已经占有monitor，只是重新进入，则monitor的进入数+1；
-
如果其他线程已经占用 monitor，则该线程处于阻塞状态，直至 monitor 的进入数为0，再重新尝试获得 monitor 的所有权
monitorexit：执行 monitorexit 的线程必须是 objectref 所对应的 monitor 的所有者。执行指令时，monitor 的进入数减1，如果减1后进入数为0，则线程退出 monitor，不再是这个 monitor 的所有者，其他被这个 monitor 阻塞的线程可以尝试获取这个 monitor 的所有权。
2.2. 线程状态和状态转化
在 HotSpot JVM 中，monitor 由 ObjectMonitor 实现，其主要数据结构如下：ObjectMonitor() {
_header = NULL;
_count = 0; //记录个数
_waiters = 0,
_recursions = 0;
_object = NULL;
_owner = NULL; //持有monitor的线程
_WaitSet = NULL; //处于wait状态的线程，会被加入到_WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ; //处于等待锁block状态的线程，会被加入到该列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
}
ObjectMonitor 中有两个队列，_WaitSet 和 _EntryList，用来保存 ObjectWaiter 对象列表（每个等待锁的线程都会被封装成 ObjectWaiter 对象），_owner 指向持有 ObjectMonitor 对象的线程。-
当多个线程同时访问一段同步代码时，首先会进入 _EntryList，等待锁处于阻塞状态。
-
当线程获取到对象的 monitor 后进入 The Owner 区域，并把 ObjectMonitor 中的 _owner 变量设置为当前线程，同时 monitor 中的计数器 count 加1。
-
若线程调用 wait() 方法，将释放当前持有的 monitor，_owner 变量恢复为 null，count 减1，同时该线程进入 _WaitSet 集合中等待被唤醒，处于 waiting 状态。
-
若当前线程执行完毕，将释放 monitor 并复位变量的值，以便其他线程进入获取 monitor。
3. 锁优化
在 JDK1.6 之后，出现了各种锁优化技术，如轻量级锁、偏向锁、适应性自旋、锁粗化、锁消除等，这些技术都是为了在线程间更高效的解决竞争问题，从而提升程序的执行效率。
通过引入轻量级锁和偏向锁来减少重量级锁的使用。锁的状态总共分四种：无锁状态、偏向锁、轻量级锁和重量级锁。锁随着竞争情况可以升级，但锁升级后不能降级，意味着不能从轻量级锁状态降级为偏向锁状态，也不能从重量级锁状态降级为轻量级锁状态。
无锁状态 偏向锁状态 轻量级锁 重量级锁重量级锁
monitor 监视器锁本质上是依赖操作系统的 Mutex Lock 互斥量 来实现的，我们一般称之为重量级锁。因为 OS 实现线程间的切换需要从用户态转换到核心态，这个转换过程成本较高，耗时相对较长，因此 synchronized 效率会比较低。
重量级锁的锁标志位为'10'，指针指向的是 monitor 对象的起始地址，关于 monitor 的实现原理上文已经描述了。
1 轻量级锁
轻量级锁是相对基于OS的互斥量实现的重量级锁而言的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用OS的互斥量而带来的性能消耗。
轻量级锁提升性能的经验依据是：对于绝大部分锁，在整个同步周期内都是不存在竞争的。如果没有竞争，轻量级锁就可以使用 CAS 操作避免互斥量的开销，从而提升效率。
原理
轻量级锁是相对于传统的重量级锁而言，它使用 CAS 操作来避免重量级锁使用互斥量的开销。对于绝大部分的锁，在整个同步周期内都是不存在竞争的，因此也就不需要都使用互斥量进行同步，可以先采用 CAS 操作进行同步，如果 CAS 失败了再改用互斥量进行同步。
当尝试获取一个锁对象时，如果锁对象标记为 0 01，说明锁对象的锁未锁定（unlocked）状态。此时虚拟机在当前线程的虚拟机栈中创建 Lock Record，然后使用 CAS 操作将对象的 Mark Word 更新为 Lock Record 指针。如果 CAS 操作成功了，那么线程就获取了该对象上的锁，并且对象的 Mark Word 的锁标记变为 00，表示该对象处于轻量级锁状态。
如果 CAS 操作失败了，虚拟机首先会检查对象的 Mark Word 是否指向当前线程的虚拟机栈，如果是的话说明当前线程已经拥有了这个锁对象，那就可以直接进入同步块继续执行，否则说明这个锁对象已经被其他线程线程抢占了。如果有两条以上的线程争用同一个锁，那轻量级锁就不再有效，要膨胀为重量级锁。
2 偏向锁
轻量级锁是在无多线程竞争的情况下，使用 CAS 操作去消除互斥量；偏向锁是在无多线程竞争的情况下，将这个同步都消除掉。
偏向锁提升性能的经验依据是：对于绝大部分锁，在整个同步周期内不仅不存在竞争，而且总由同一线程多次获得。偏向锁会偏向第一个获得它的线程，如果接下来的执行过程中，该锁没有被其他线程获取，则持有偏向锁的线程不需要再进行同步。这使得线程获取锁的代价更低。
偏向锁的获取过程：
1、线程执行同步块，锁对象第一次被获取的时候，JVM 会将锁对象的 Mark Word 中的锁状态设置为偏向锁（锁标志位为'01'，是否偏向的标志位为'1'），同时通过 CAS 操作在 Mark Word 中记录获取到这个锁的线程的 ThreadID
2、如果 CAS 操作成功。持有偏向锁的线程每次进入和退出同步块时，只需测试一下 Mark Word 里是否存储着当前线程的 ThreadID。如果是，则表示线程已经获得了锁，而不需要额外花费 CAS 操作加锁和解锁
3、如果不是，则通过CAS操作竞争锁，竞争成功，则将 Mark Word 的 ThreadID 替换为当前线程的 ThreadID
偏向锁的释放过程：
1、当一个线程已经持有偏向锁，而另外一个线程尝试竞争偏向锁时，CAS 替换 ThreadID 操作失败，则开始撤销偏向锁。偏向锁的撤销，需要等待原持有偏向锁的线程到达全局安全点（在这个时间点上没有字节码正在执行），暂停该线程，并检查其状态
2、如果原持有偏向锁的线程不处于活动状态或已退出同步代码块，则该线程释放锁。将对象头设置为无锁状态（锁标志位为'01'，是否偏向标志位为'0'）
3、如果原持有偏向锁的线程未退出同步代码块，则升级为轻量级锁（锁标志位为'00'）
原理
偏向锁的思想是偏向于让第一个获取锁对象的线程，这个线程在之后获取该锁就不再需要进行同步操作，甚至连 CAS 操作也不再需要。
当锁对象第一次被线程获得的时候，进入偏向状态，标记为 1 01。同时使用 CAS 操作将线程 ID 记录到 Mark Word 中，如果 CAS 操作成功，这个线程以后每次进入这个锁相关的同步块就不需要再进行任何同步操作。
当有另外一个线程去尝试获取这个锁对象时，偏向状态就宣告结束，此时撤销偏向（Revoke Bias）后恢复到未锁定状态或者轻量级锁状态。
3 适应性自旋
自旋锁：互斥同步时，挂起和恢复线程都需要切换到内核态完成，这对性能并发带来了不少的压力。同时在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段较短的时间而去挂起和恢复线程并不值得。那么如果有多个线程同时并行执行，可以让后面请求锁的线程通过自旋（CPU忙循环执行空指令）的方式稍等一会儿，看看持有锁的线程是否会很快的释放锁，这样就不需要放弃 CPU 的执行时间了。
适应性自旋：在轻量级锁获取过程中，线程执行 CAS 操作失败时，需要通过自旋来获取重量级锁。如果锁被占用的时间比较短，那么自旋等待的效果就会比较好，而如果锁占用的时间很长，自旋的线程则会白白浪费 CPU 资源。解决这个问题的最简答的办法就是：指定自旋的次数，如果在限定次数内还没获取到锁（例如10次），就按传统的方式挂起线程进入阻塞状态。JDK1.6 之后引入了自适应性自旋的方式，如果在同一锁对象上，一线程自旋等待刚刚成功获得锁，并且持有锁的线程正在运行中，那么 JVM 会认为这次自旋也有可能再次成功获得锁，进而允许自旋等待相对更长的时间（例如100次）。另一方面，如果某个锁自旋很少成功获得，那么以后要获得这个锁时将省略自旋过程，以避免浪费 CPU。
4 锁消除
锁消除就是编译器运行时，对一些被检测到不可能存在共享数据竞争的锁进行消除。如果判断一段代码中，堆上的数据不会逃逸出去从而被其他线程访问到，则可以把他们当做栈上的数据对待，认为它们是线程私有的，不必要加锁。public String concatString(String s1, String s2, String s3) {
StringBuffer sb = new StringBuffer();
sb.append("a");
sb.append("b");
sb.append("c");
return sb.toString();
}在 StringBuffer.append() 方法中有一个同步代码块，锁就是sb对象，但 sb 的所有引用不会逃逸到 concatString() 方法外部，其他线程无法访问它。因此这里有锁，但是在即时编译之后，会被安全的消除掉，忽略掉同步而直接执行了。5 锁粗化
锁粗化就是 JVM 检测到一串零碎的操作都对同一个对象加锁，则会把加锁同步的范围粗化到整个操作序列的外部。以上述 concatString() 方法为例，内部的 StringBuffer.append() 每次都会加锁，将会锁粗化，在第一次 append() 前至 最后一个 append() 后只需要加一次锁就可以了。
京公网安备 11010502036488号