synchronized加锁过程

自己梳理了一下，备忘。

默认JVM启动后有一个偏向延时，默认刚启动4秒内创建的对象，不启用可偏向锁。可以通过jvm参数设置（BiasedLockingStartupDelay = 4000）。

锁竞争过程：

1.当对象未被任何线程持有（对象头锁标记为101，线程id为0，是可偏向状态），通过CAS将对象头的线程id指向当前线程。

2.当有线程竞争，判断锁对象的头信息（对象 头锁标 记为101，线程id不为0），头信息的线程id与当前线程id不相等，锁对象已被其他线程占用，此时判断头信息的epoch与锁对象头信息指向klass的epoch是否相等，如果不相等，则说明被批量重偏向，cas修改线程id为当前线程。

3.如果上面第二步epoch相等，判断当前锁对象持有的线程是否需要继续持有锁，如果需要，则锁膨胀为重量级锁，否则偏向锁撤销，将对象头信息锁标识位改为001，然后加轻量级锁，对象头锁标识位改为00

4.偏向锁可偏向状态不可逆，偏向锁升级为轻量级锁后，当锁释放为无锁状态，下次再获取锁，直接是轻量级锁

5.偏向锁只有锁撤销（epoch未过期前提，线程A持有，但是已经不适用了，线程B来竞争，此时偏向锁撤销，加轻量级锁），没有锁释放，但是可以批量重偏向

6.无论是偏向锁还是轻量级锁，只要有资源竞争，都会膨胀为重量级锁，只是在膨胀为重量级锁之后，在线程挂起之前，会自旋来获取锁（挂起前的挣扎）

膨胀过程：

偏向锁->重量级锁

轻量级锁->重量级锁

注：

1.如果对象获取过HASHCODE，则不可加偏向锁（默认hashcode懒加载，但由于加载了hashcode后对象头信息无法存储偏向线程id）

2.偏向锁持有过程中获取hashcode，直接膨胀为重量级锁