Sync锁详解

代码示例：

public class Demo {
   
   private  static Object object=new Object();
   
   public static void main(String[] args) {
      synchronized (object){}
      System.out.println("Test");
   }

}

通过javap -v 反汇编class文件。

Sync锁的确是传了一个对象进来，如上例是object ，但实际上对象的monitor才是真正的锁。JVM会创建一个C++的monitor（监视器）对象，

monitor里面包含 ： owner （拥有锁的线程）  recursions（记录锁的次数）

比如T1线程执行到同步代码块，就会找到改对象的monitor（实际上的锁），查看别的线程有没有拿到该monitor，如果没有，就会把owner变成T1，并且recursions变成1.如果同步代码块里还有Sync锁，并且锁的对象还是object这个对象，那么就会变成重入锁，并且recursion变成2，每跳出一个同步代码块，那么recursion就会-1。减到0的时候，该线程就会退出monitor，退出锁。  当T1线程正在执行，此时来个T2线程，也来竞争这把锁，发现monitor对象中的owner不是T2，那么T2就会进入阻塞状态。

Sync出现异常会释放锁吗？  会的。同步代码块中如果出现异常，会释放。

Sync锁加在方法体上时，反汇编后，会增加ACC_Sync修饰。会隐式调用monitorrenter和monitorrexit。在执行同步方法之前，调用monitorrenter，方法结束后会调用monitorr

exit。

monitor锁对象原理  ：  在Java中new一个对象，对象会放在堆中 。一个对象会包含对象头（monitor对象）实例数据。​​​​​​​

Monitor的结构：

Entrylist  ：因为Sync本身是非公平的，等了一轮的线程还没有抢到锁，就是block阻塞状态，会放入Entrylist中

owner：拥有锁的线程

WaitSet ： 线程抢到了锁，但是执行了wait（）方法，进入wait状态，进入watiSet中。

Sync锁本身是非公平锁。

实际上1.6之前的Sync锁是性能不太好的，是非常重的锁（重量级锁）。

执行同步代码块 ，没有竞争到锁的线程会被park()挂起，竞争到锁的线程会unpark（）唤醒，此时会存在操作系统中用户态和内核态的转换。会消耗大量的系统资源。

JDK1.6之后的优化 ：

重量级锁 ：只有一个线程能获取锁，其他线程被迫进入阻塞队列，空等，消耗cpu资源。

实际业务中 ： 虽然为了保证安全必须加锁，但是并不一定会使用很多线程 ，所以引入了偏向锁的概念： 让下一次锁资源竞争时，更容易把锁分配给上一次抢到资源的锁 （example：给上次的线程加个id，下次去抢线程时直接报上姓名，让锁能识别这个线程，ok，再分给它资源）

这样可以解决很多只有一个线程的业务，增加效率。

如果很多个线程开始抢资源，ok，这时候锁升级成为轻量级锁（CAS轻度竞争（比对是不是释放锁了））。

引申： 轻量级锁不一定比重量级锁性能高。（大量线程等待加锁，在自旋的过程中浪费CPU资源）。如果大量线程自旋的消耗，大于CPU进行一次线程上下文切换的时间，就会认为此时使用CAS不划算，不如直接转成重量级锁节约资源 （这大概就是锁膨胀（升级）的过程）

升级锁是根据一个参数 markword

以下是流程图：