Synchronized的四种状态

• 无锁状态：锁对象在禁用偏向锁被创建出来未被任何线程所获取或者偏向锁撤销后的状态。
• 偏向锁：当JVM启用了偏向锁模式（jdk6默认开启），新创建对象的Mark Word中的Thread Id为0，说明此时处于可偏向但未偏向任何线程，也叫做匿名偏向状态(anonymously biased)。锁初次被线程获取也是偏向锁模式。在获取锁的过程中，线程在锁对象的markword中记录偏向锁状态和当前线程的线程ID,当该线程再次请求锁时，只需检查锁对象的markword的锁标记是否为偏向锁和记录的线程ID是否为当前线程的ID，无需再做有关申请锁的操作，连CAS都不需要，所以性能较高。偏向锁使用了一种等到出现竞争才会释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。偏向锁释放时，会将持有偏向锁的线程运行到安全点，然后检查该线程是否存活以及是否需要继续持有该偏向锁，如果线程存活或需要继续持有该偏向锁，则偏向锁升级为轻量级锁。如果线程不存活或不需要继续持有该偏向锁，则会重置锁状态为无锁状态，无锁状态只能升级为轻量级锁或重量级锁，无法再回到偏向锁状态。偏向锁在jdk1.6后默认开启，可以通过jvm参数来关闭偏向锁：-XX:-UseBiasedLocking = false。

//关闭延迟开启偏向锁 
‐XX:BiasedLockingStartupDelay=0 
//禁止偏向锁 
‐XX:‐UseBiasedLocking 
//启用偏向锁 
-XX:+UseBiasedLocking

• 轻量级锁：线程在获取轻量级锁时会在栈帧中创建一块用于存储锁记录的空间(Lock Record)，然后将锁对象头中的markword（无锁状态）复制到这块空间当中，称之为Displaced MarkWord(无家可归的markword)。之后用CAS机制尝试一次（不自旋）将锁对象头的中的markword替换为指向当前栈帧中锁记录的指针，并且将当前栈帧的owner指针更改为锁对象头的MarkWord指针。这个操作如果成功，则当前线程获取到轻量级锁。如果不成功，则锁升级为重量级锁。
  即轻量级锁所适应的场景是线程交替执行同步块的场合 ，如果存在同一时间多个线程访问同一把锁的场合，就会导致轻量级锁膨胀为重量级锁。
• 重量级锁：锁在碰撞成重量级锁的期间会创建一个monitor对象。即重量级锁的原理是monitor机制。重量级锁的竞争会导致线程在用户态和内核态来回切换，性能急剧下降，除了拥有锁的线程外，其他线程都会阻塞。适用于追求吞吐量，同步块或同步方法执行时间较长的场景。

偏向锁撤销之调用对象HashCode

• 轻量级锁会在锁记录中记录 hashCode
• 重量级锁会在 Monitor 中记录 hashCode

• 当对象可偏向但未偏向时，MarkWord将变成未锁定状态，并只能升级成轻量锁；
• 当对象正处于已偏向时，调用HashCode将使偏向锁强制升级成重量锁。

     假设有两个线程， A先获取到的就是偏向锁，那么B就会发生自旋等待锁的获取。当B自旋获取到锁时，会检查A是否还存活，如果不，则锁被重置为无锁状态，此时B竞争到锁，将其设置为偏向锁。如果存活，则锁升级为轻量级锁。当B自旋失败没获取到锁时，锁就自动升级为重量级锁，竞争重量级锁时所有的线程都不会发生自旋。并且在以后的竞争中，这把锁都只会是重量级锁的状态。除非发生GC，把锁当垃圾回收。第二种场景，如果有N个线程同时竞争锁，其中只有一个自旋失败没有获取到锁，那么锁也会升级成重量级锁。

synchronized锁状态变化总结

•  锁对象创建时可能有两种状态，如果禁用了偏向锁，或者开启了偏向锁但在服务启动的前4秒内，此时创建的对象是无锁状态，反之，则是匿名可偏向状态。
• 锁处于匿名可偏向状态时，如果调用hashcode方法则降级为无锁状态；如果此时有线程获取到了匿名可偏向锁，则锁转为偏向锁已偏向状态。
• 锁处于已偏向状态时，即使当前线程释放了锁，锁仍然会处于已偏向状态，不会转为无锁状态，直到出现了另一个线程的锁竞争，才会导致锁状态的转变。
• 偏向锁已偏向时转变锁有三种情况，第一，当出现了线程的竞争时，如果当前线程已经释放了获取的偏向锁，则锁会先重置为无锁状态，然后升级为轻量级锁。第二，如果出现线程竞争时，当前线程仍然没释放锁，则锁直接升级为轻量级锁。第三，即使未出现锁竞争，但当前线程在获取锁的时间段内，执行了hashcode或wait方法，则直接升级为重量级锁。
• 线程一旦转为无锁状态，则永远无法再转为偏向锁状态。在无锁状态时，如果出现轻微锁竞争，即只有一个线程去竞争，且竞争成功了，则升级为轻量级锁。如果出现大量竞争，即有一部分线程直接竞争失败了，则直接升级为重量级锁。
• 线程在竞争轻量级锁失败时，会导致锁升级为重量级锁。无锁、轻量级锁、重量级锁都无法再转为偏向锁。轻量级锁、重量级锁释放后都会转为无锁状态。
• 重量级锁依赖于monitor机制实现，会导致用户再内核态和用户态之间切换，性能很差。

偏向锁批量重偏向&批量撤销

      在开启偏向锁的条件下，对象创建出来则是匿名可偏向状态。如果此时线程竞争频繁时，偏向锁升级会先撤销为无锁再升级为轻量级锁。在这种情况下，偏向锁不仅不能提高性能，还会导致性能下降。于是，就有了批量重偏向与批量撤销的机制。

      批量重偏向：当一个类的所有对象锁累计撤销超过20次，即同一个类的多个对象锁累计由偏向锁转为轻量级锁超过20次，则jvm会认为之前的冲偏向策略可能时存在问题的，它会将20次之后的锁升级操作改为再次重偏向的操作偏向新的线程，即20次之前的锁升级为轻量级锁，20次之后的锁仍然是偏向锁。

       批量撤销： 当一个类的所有对象锁累计撤销超过40次，则jvm会认定这个类不适合使用偏向锁，之后，对于该class的锁，直接走轻量级锁的逻辑。即新对象创建出来为无锁状态，加锁直接加轻量级锁。

intx BiasedLockingBulkRebiasThreshold = 20 //默认偏向锁批量重偏向阈值 
intx BiasedLockingBulkRevokeThreshold = 40 //默认偏向锁批量撤销阈值

自旋优化

• 自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。
• 在 Java 6 之后自旋是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，比较智能。
• Java 7 之后不能控制是否开启自旋功能

锁粗化

StringBuffer buffer = new StringBuffer(); 
/** 
 * 锁粗化 
 */ 
public void append(){ 
 buffer.append("aaa").append(" bbb").append(" ccc"); 
}