自旋锁 VS 适应性自旋锁
- 自旋锁：
阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态转换需要耗费处理器时间。如果同步代码块中的内容过于简单，状态转换消耗的时间有可能比用户代码执行的时间还要长。
在许多场景中，同步资源的锁定时间很短，为了这一小段时间去切换线程，线程挂起和恢复现场的花费可能会让系统得不偿失。
如果物理机器有多个处理器，能够让两个或以上的线程同时并行执行，我们就可以让后面那个请求锁的线程不放弃CPU的执行时间，看看持有锁的线程能否很快就释放锁。
而为了让当前线程“稍等一下”，我们需让当前线程进行自旋，如果在自旋完成后前面锁定同步资源的线程已经释放了锁，那么当前线程就可以不必阻塞而是直接获取同步资源，从而避免切换线程的开销。
这就是自旋。
- 自旋的缺点：
不能代替阻塞。虽然避免线程切换的开销，但要占用处理器时间。如果锁被占用的时间很短，自旋等待的效果就会非常好。反之，如果锁被长时间占用，那么自旋的线程只会浪费处理器资源。
所以，自旋等待的时间必须有一定的限度，如果自旋超过了限度次数（默认是10次，可以使用-XX:PreBlockSpin来更改）没有成功获得锁，就应当挂起线程。
自旋锁的实现原理同样也是CAS，AtomInteger中调用unsafe进行自增操作的源码中do-while循环就是一个自旋操作，如果修改数值失败则通过循环来执行自旋，直至修改成功。
- 适应性自旋锁：
自旋锁在JDK1.4.2中引入，使用 -XX:+UseSpinning来开启。JDK6中变成默认开启，并且引入了自适应的自旋锁（适应性自旋锁）。
自适应意味着自旋的时间（次数）不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在进行中，那么虚拟机就会认为这次自旋也是很有可能再次成功，进而它将允许自旋等待持续更长的时间。如果对于某个锁，自旋很少成功获得过，那在以后尝试获取这个锁时将可能省略掉自旋过程，直接阻塞线程，避免浪费处理资源。
- 自旋锁常见的锁形式：
TicketLock、CLHLock、MCSLock
