synchronized原理，与锁的升级_java synchronized 锁升级 demo-CSDN博客

本文链接：https://blog.csdn.net/shun0304/article/details/134538562

synchronized内置锁是一种对象锁（锁的是对象而非引用），作用粒是对象，可以用来实现对临界资源的同步互斥访问，可重入

加锁的方式：

1.同步实例方法，锁是当前实例对象

2.同步类方法，锁是当前类对象

3.同步代码块，锁是括号里面的对象

1 //1.同步实例方法,锁是demo实例对象。当一个线程进入一个demo对象的同步实例方法时，
2 //其他线程对当前demo实例对象的所有同步实例方法的访问都将被阻塞，
3 //直到第一个线程退出同步方法。这称为“对象锁”或“实例锁”。
4 public class demo{
5     public synchronized void synchronizedMethod() { 
6         // 代码... 
7     }
8 }
9 //2.同步类方法,锁是demo类对象。当一个线程进入demo类的同步类方法时，
10 //其他线程对demo类的所有同步类方法的访问都将被阻塞，
11 //直到第一个线程退出同步方法。这称为“类锁”。
12 public class demo{
13     public static synchronized void synchronizedMethod() { 
14         // 代码... 
15     }
16 }
17 //3.同步代码块：锁是括号里面的对象。你可以指定任何对象作为锁。当一个线程进入同步代码块时，
18 //其他线程如果试图使用相同的锁进入同步代码块，将会被阻塞。
19 //当前this指的是demo这个对象实例，当其他线程想要调用demo这个实例的方法时被阻塞
20 public class demo{
21     public void method() { 
22         synchronized (this) { 
23             // 代码... 
24         } 
25     }
26 }

底层原理

synchronized是基于JVM内置锁实现，通过内部对象Monitor(监视器锁)实现，基于进入与退出Monitor对象实现方法与代码块同步。

监视器锁的实现依赖底层操作系统Mutex lock （互斥锁）实现，1.5版本之后做了优化，如锁粗化（Lock Coarsening）、锁消除（Lock Elimination）、轻量级锁（Lightweight Locking）、偏向锁（Biased Locking）、适应性自旋（Adaptive Spinning）等技术来减少锁操作的开销，，内置锁的并发性能已经基本与 Lock持平。

synchronized关键字被编译成字节码后会被翻译成monitorenter 和 monitorexit 两条指令分别在同步块逻辑代码的起始位置与结束位置。

Monitor监视锁

锁的膨胀升级过程

锁的状态总共有四种，无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁，但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级。从JDK 1.6 中默认是开启偏向锁和轻量级锁的，可以通过-XX:-UseBiasedLocking来禁用偏向锁。下图为锁的升级全过程：

1.先是无锁状态，cas获取锁，获取到锁后转为偏向锁。

2.其他线程获取锁失败会转为轻量级锁

3.轻量级锁自旋CAS操作，

4.当自旋达到一定次数未获取到锁，转变为重量级锁

偏向锁

偏向锁是Java 6之后加入的新锁，它是一种针对加锁操作的优化手段，经过研究发现，在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，因此为了减少同一线程获取锁(会涉及到一些CAS操作,耗时)的代价而引入偏向锁。偏向锁的核心思想是，如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word 的结构也变为偏向锁结构，当这个线程再次请求锁时，无需再做任何同步操作，即获取锁的过程，这样就省去了大量有关锁申请的操作，从而也就提供程序的性能。所以，对于没有锁竞争的场合，偏向锁有很好的优化效果，毕竟极有可能连续多次是同一个线程申请相同的锁。但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。下面我们接着了解轻量级锁。

默认开启偏向锁

开启偏向锁：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0

关闭偏向锁：-XX:-UseBiasedLocking

轻量级锁

倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)，此时Mark Word 的结构也变为轻量级锁的结构。轻量级锁能够提升程序性能的依据是“对绝大部分的锁，在整个同步周期内都不存在竞争”，注意这是经验数据。需要了解的是，轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场合，就会导致轻量级锁膨胀为重量级锁。

自旋锁

轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。这是基于在大多数情况下，线程持有锁的时间都不会太长，如果直接挂起操作系统层面的线程可能会得不偿失，毕竟操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，因此自旋锁会假设在不久将来，当前的线程可以获得锁，因此虚拟机会让当前想要获取锁的线程做几个空循环(这也是称为自旋的原因)，一般不会太久，可能是50个循环或100循环，在经过若干次循环后，如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作系统层面挂起，这就是自旋锁的优化方式，这种方式确实也是可以提升效率的。最后没办法也就只能升级为重量级锁了。

锁消除

消除锁是虚拟机另外一种锁的优化，这种优化更彻底，Java虚拟机在JIT编译时(可以简单理解为当某段代码即将第一次被执行时进行编译，又称即时编译)，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过这种方式消除没有必要的锁，可以节省毫无意义的请求锁时间，如下StringBuffer的append是一个同步方法，但是在add方法中的StringBuffer属于一个局部变量，并且不会被其他线程所使用，因此StringBuffer不可能存在共享资源竞争的情景，JVM会自动将其锁消除。锁消除的依据是逃逸分析的数据支持。

锁消除，前提是java必须运行在server模式（server模式会比client模式作更多的优化），同时必须开启逃逸分析

-XX:+DoEscapeAnalysis 开启逃逸分析

-XX:+EliminateLocks 表示开启锁消除。