Java很多ThreadDump中，都可以看到Thin Lock, Fat Lock, Spin Lock，这些Lock都与Java语言、OS有密切的关系。

回到一个简单的问题，在Java中，如何实现Synchronizd？

最简单的一种做法是，利用OS的mutex机制，把Java的同步（基于Object），翻译成OS相关的monitor_enter和monitor_exit原语。

回到Java锁本身，锁在不同的应用下有着不同的统计表现，而大部分的统计数据表明，其实线程抢锁，即锁竞争，都是短暂的，在大部分的情况下，几乎都不会发生锁竞争的现象。

也就是说，Java锁，从安全性的角度来看，是有点累赘。

因此，大量的专家都在锁上针对这样的统计特性对Java锁进行优化。

其中一种优化方案是，我们对所有的锁都需要monitor_enter和monitor_exit吗？事实上不需要。

如果我们把monitor_enter/monitor_exit看成是Fat Lock方式，则可以把Thin Lock看成是一种基于CAS（Compare and Swap）的简易实现。

这两种锁，简单一点理解，就是：

而基于CAS方式的实现，线程进入竞争状态的，获得锁的线程，会让其他线程处于自旋状态（也称之为Spin Mode，即自旋），这是一种while(Lock_release) doStuff()的Busy-Wait方式，是一种耗CPU的方式；而Fat Lock方式下，一个线程获得锁的时候，其他线程可以先sleep，等锁释放后，再唤醒（Notify）。

CAS的优点是快，如果没有线程竞争的情况下，因为CAS只需要一个指令便获得锁，所以称之为Thin Lock，缺点也是很明显的，即如果频繁发生线程竞争，CAS是低效，主要表现为，排斥在锁之外的线程是Busy Wait状态；而monitor_enter/monitor_exit/monitor_notify方式，则是重量级的，在线程产生竞争的时候，Fat Lock在OS mutex方式下，可以实现no busy-wait。

于是，JVM早期版本的做法是，如果T1, T2，T3，T4...产生线程竞争，则T1通过CAS获得锁(此时是Thin Lock方式)，如果T1在CAS期间获得锁，则T2，T3进入SPIN状态直到T1释放锁；而第二个获得锁的线程，比如T2，会将锁升级（Inflation）为Fat Lock，于是，以后尝试获得锁的线程都使用Mutex方式获得锁。

这种设计为锁提供了两条路径：Thin Lock路径和Fat Lock路径，大部分情况下，可能都是走Thin Lock路径，而可能少部分情况，是走Fat Lock路径，这种方式提供了锁升级，但是避免不了Busy Wait，而且Thin-Lock升级Fat-Lock之后，没有办法回退到Thin-Lock（性能比Fat-Lock更好）。

Tasuki锁为这种方式做了2个优化：

1) 避免CAS导致Busy wait

2) Fat Lock可以deflate(与Inflate刚好相反)为Thin Lock(之前是Thin Lock变成Fat Lock之后便不能再回退)。

经过这样的改造后，锁性能提高了10%以上。

目前，Oracle的BEA JRockit与IBM的JVM都实现了Tasuki锁机制，唯一的不同是，在锁实现上都做了不同启发式的设计，即根据运行时采样的数据，动态调整一些权值数据，一边左右Lock Inflation/Lock Defaltion的过程（一颗树的两个分支），获取更好的锁性能。

 

关键词：JAVA   对象锁   JVM   锁机制   JVM锁   LOCK