偏向锁是为了解决轻量锁锁记录和对象头markword中的cas性能开销过大的问题，特别是在重入的时候会出现这样的现象。 对于如下的所示的代码：m1方法里面调用m2方法，m2方法调用m3方法，这时只有一个线程，本来可以使用轻量级锁，但是jvm底层还会对轻量级锁进行优化，也就是偏向锁。 在对象头中的markword中存储的就是偏向锁的信息，也就是线程ID等信息，在 java对象头的结构 这篇文章中有偏向锁的结构。在重入的时候，线程发现对象头中的thread是自己，就表示没有竞争，不用重新CAS，这个对象就归该线程所有。

当一个线程获得对象的锁，另外一个线程要进入同步代码块不会立马阻塞，而是会自旋重试，从而提升性能。 具体如下所示：在自旋重试的过程中，如果获得锁的线程释放了锁，则自旋重试成功，则获得锁，也就是不用进入阻塞。

一个线程已经对对象加了轻量级锁，另外一个线程也想对对象加锁，object中的轻量级锁会膨胀成重量级锁，如下所示。 锁膨胀的流程： Thread1加轻量级锁失败，进入锁膨胀流程 为Object 申请Monitor锁，让object指向重量级锁指针 然后自己进入monitor的entrylist进行blocked 锁膨胀之后的解锁流程 Thread0退出同步代码块，进行解锁时发现object中的markword不再是轻量级锁记录的地址，因此根据monitor去找monitor锁，将其owner置为空，并唤醒entryl…

轻量级锁的使用场景，如果一个对象有多个线程访问，但多线程的访问时间是错开的（也就是没有竞争），那么可以让轻量级锁来优化，轻量级锁的语法还是Syncronized。 假设有两个方法同步代码块，利用同一个对象进行加锁： static final Object object = new Object(); public static void method1() { Syncronized(object) { // 同步块A method2(); } } ​ public static void method2() { …