目前在Java中存在两种锁机制：synchronized和Lock。数据同步需要依赖锁，那锁时如何实现的呢，synchronized给出的答案是软件层面依赖JVM，而Lock给出的方案是在硬件层面依赖特殊的CPU指令。
下面先介绍synchronized的实现：
synchronized是关键字，即使有了Lock接口（Lock能够实现synchronized能够实现的所有功能），使用的还是非常广泛。其应用层的语义是可以把任何一个非nul对象作为锁，当synchronized作用在方法上时，锁住的对象是实例对象（this）；当作用在静态方法时锁住的对象时对象对应的Class实例，因为Class数据存在于永久带，因此静态方法锁相当于类的一个全局锁；当synchronized作用于某一个对象实例时，锁住的便是对应的代码块。在JVM实现中，所有一个专门的名字：对象监视器
线程状态与状态的转换
当多个线程同时请求某个对象监视器时，对象监视器会设置几种状态来区分请求的线程
- Contention List：所有请求锁的线程将被首先放置到竞争队列。Contention List是一个虚拟队列，原因在于Contention List是一个由Node及next指针逻辑构成，并不存在一个Queue的数据结构。ContentionList是一个后进先出（LIFO）队列。
- Entry List：Contention List中那些有资格成为候选人的线程被移到Entry List。Entry List和Contention List逻辑上同属等待队列。Contention List会被线程并发访问，为了降低对Contention List队尾的争用，而建立Entry List。Owner线程在unlock时会从Contention List中迁移到Entry List。线程被wait方法阻塞，则被防止到Wait Set，被notify或notifyAll唤醒之后，重新被放置到EntryList。
- Wait Set：那些调用wait方法被阻塞的线程被放置到WaitSet
- onDeck：任何时刻最多只能有一个线程正在竞争锁，该线程被称为onDeck
- Owner：获得锁的线程被称为Owner
- ！Owner：释放锁的线程。
状态转换关系：
新请求锁的线程首先被加入到 ContentionList中，当某个拥有锁的线程（Owner状态）调用unlock之后，如果发现EntryList为空则从ContentionList中移动线程到EntryList。
自旋锁
那些处于ContetionList、EntryList、WaitSet中的线程均处于阻塞状态，阻塞操作由操作系统完成（在Linxu下通过pthread_mutex_lock函数）。线程被阻塞后便进入内核（Linux）调度状态，这个会导致系统在用户态与内核态之间来回切换，严重影响锁的性能。缓解上述问题的办法便是自旋，其原理是：当发生争用时，若Owner线程能在很短的时间内释放锁，则那些正在争用线程可以稍微等一等（自旋），在Owner线程释放锁后，争用线程可能会立即得到锁，从而避免了系统阻塞。但Owner运行的时间可能会超出了临界值，争用线程自旋一段时间后还是无法获得锁，这时争用线程则会停止自旋进入阻塞状态（后退）。基本思路就是自旋，不成功再阻塞，尽量降低阻塞的可能性，这对那些执行时间很短的代码块来说有非常重要的性能提高。自旋锁有个更贴切的名字：自旋-指数后退锁，也即复合锁。很显然，自旋在多处理器上才有意义。还有个问题是，线程自旋时做些啥？其实啥都不做，可以执行几次for循环，可以执行几条空的汇编指令，目的是占着CPU不放，等待获取锁的机会。所以说，自旋是把双刃剑，如果旋的时间过长会影响整体性能，时间过短又达不到延迟阻塞的目的。显然，自旋的周期选择显得非常重要，但这与操作系统、硬件体系、系统的负载等诸多场景相关，很难选择，如果选择不当，不但性能得不到提高，可能还会下降，因此大家普遍认为自旋锁不具有扩展性。对自旋锁周期的选择上，HotSpot认为最佳时间应是一个线程上下文切换的时间，但目前并没有做到。经过调查，目前只是通过汇编暂停了几个CPU周期，除了自旋周期选择，HotSpot还进行许多其他的自旋优化策略，具体如下：
◆ 如果平均负载小于CPUs则一直自旋。
◆ 如果有超过(CPUs/2)个线程正在自旋，则后来线程直接阻塞。
◆ 如果正在自旋的线程发现Owner发生了变化则延迟自旋时间（自旋计数）或进入阻塞。
◆ 如果CPU处于节电模式则停止自旋。
◆ 自旋时间的最坏情况是CPU的存储延迟（CPU A存储了一个数据，到CPU B得知这个数据直接的时间差）。
◆ 自旋时会适当放弃线程优先级之间的差异。
那synchronized实现何时使用了自旋锁？答案是在线程进入ContentionList时，也即第一步操作前。线程在进入等待队列时首先进行自旋尝试获得锁，如果不成功再进入等待队列。这对那些已经在等待队列中的线程来说，稍微显得不公平。还有一个不公平的地方是自旋线程可能会抢占了Ready线程的锁。自旋锁由每个监视对象维护，每个监视对象一个。
通过上面的介绍可以看出，synchronized的底层实现主要是依靠Lock-Free的队列，基本思路是自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。
来源：oschina
链接：https://my.oschina.net/u/2808406/blog/736029