前言

锁作为并发共享数据，保证一致性的工具，在JAVA平台有多种实现(如 synchronized 和 ReentrantLock等等 ) 。这些已经写好提供的锁为我们开发提供了便利，但是锁的具体性质以及类型却很少被提及。下面提及的锁在前面的多线程系列讲述过的，我就不在整理总结啦，主要讲述前面没提及的性质和类型。
重量级锁
现在我们应该知道，Synchronized是通过对象内部的一个叫做监视器锁（monitor）来实现的。但是监视器锁本质又是依赖于底层的操作系统的Mutex Lock来实现的。而操作系统实现线程之间的切换这就需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就是为什么Synchronized效率低的原因。因此，这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”。JDK中对Synchronized做的种种优化，其核心都是为了减少这种重量级锁的使用。JDK1.6以后，为了减少获得锁和释放锁所带来的性能消耗，提高性能，引入了“轻量级锁”和“偏向锁”。
锁的状态总共有四种：无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁（但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级）。JDK 1.6中默认是开启偏向锁和轻量级锁的，我们也可以通过-XX:-UseBiasedLocking来禁用偏向锁。锁的状态保存在对象的头文件中，以32位的JDK为例：
线程锁 - 图1
“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的。但是，首先需要强调一点的是，轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用产生的性能消耗。在解释轻量级锁的执行过程之前，先明白一点，轻量级锁所适应的场景是线程交替执行同步块的情况，如果存在同一时间访问同一锁的情况，就会导致轻量级锁膨胀为重量级锁。

1、轻量级锁

1、轻量级锁的加锁过程
（1）在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，官方称之为 Displaced Mark Word。这时候线程堆栈与对象头的状态如图2.1所示。
（2）拷贝对象头中的Mark Word复制到锁记录中。
（3）拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向object mark word。如果更新成功，则执行步骤（3），否则执行步骤（4）。
（4）如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图2.2所示。
（5）如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。 而当前线程便尝试使用自旋来获取锁，自旋就是为了不让线程阻塞，而采用循环去获取锁的过程。
线程锁 - 图2
图2.1 轻量级锁CAS操作之前堆栈与对象的状态
线程锁 - 图3
图2.2 轻量级锁CAS操作之后堆栈与对象的状态
2、轻量级锁的解锁过程：
（1）通过CAS操作尝试把线程中复制的Displaced Mark Word对象替换当前的Mark Word。
（2）如果替换成功，整个同步过程就完成了。
（3）如果替换失败，说明有其他线程尝试过获取该锁（此时锁已膨胀），那就要在释放锁的同时，唤醒被挂起的线程。

2、偏向锁

引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗）。上面说过，轻量级锁是为了在线程交替执行同步块时提高性能，而偏向锁则是在只有一个线程执行同步块时进一步提高性能。
1、偏向锁获取过程：
（1）访问Mark Word中偏向锁的标识是否设置成1，锁标志位是否为01——确认为可偏向状态。
（2）如果为可偏向状态，则测试线程ID是否指向当前线程，如果是，进入步骤（5），否则进入步骤（3）。
（3）如果线程ID并未指向当前线程，则通过CAS操作竞争锁。如果竞争成功，则将Mark Word中线程ID设置为当前线程ID，然后执行（5）；如果竞争失败，执行（4）。
（4）如果CAS获取偏向锁失败，则表示有竞争。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。
（5）执行同步代码。
2、偏向锁的释放：
偏向锁的撤销在上述第四步骤中有提到。偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程不会主动去释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态，撤销偏向锁后恢复到未锁定（标志位为“01”）或轻量级锁（标志位为“00”）的状态。
3、重量级锁、轻量级锁和偏向锁之间转换
线程锁 - 图4
锁状态转换图

3、自旋锁

为什么要自旋或者自适应自旋？
前面我们讨论互斥同步的时候，提到了互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性能 带来了很大的压力。同时，虚拟机的开发团队也注意到在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。如 果物理机器有一个以上的处理器，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程“稍等一会”，但不放弃处理器的执行时间，看看持有 锁的线程是否很快就会释放锁。为了让线程等待，我们只须让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。
自旋锁在JDK 1.4.2中就已经引入，只不过默认是关闭的，可以使用-XX:+UseSpinning参数来开启，在JDK 1.6中就已经改为默认开启了。自旋等待不能代替阻塞，且先不说对处理器数量的要求，自旋等待本身虽然避免了线程切换的开销，但它是要占用处理器时间的， 所以如果锁被占用的时间很短，自旋等待的效果就会非常好，反之如果锁被占用的时间很长，那么自旋的线程只会白白消耗处理器资源，而不会做任何有用的工作， 反而会带来性能的浪费。因此自旋等待的时间必须要有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程了。自旋次 数的默认值是10次，用户可以使用参数-XX:PreBlockSpin来更改。
在JDK 1.6中引入了自适应的自旋锁。自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象 上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而它将允许自旋等待持续相对更长的时间， 比如100个循环。另一方面，如果对于某个锁，自旋很少成功获得过，那在以后要获取这个锁时将可能省略掉自旋过程，以避免浪费处理器资源。有了自适应自 旋，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越准确，虚拟机就会变得越来越“聪明”了。
自旋锁是采用让当前线程不停地的在循环体内执行实现的，当循环的条件被其他线程改变时 才能进入临界区。如下所示：

  1. public class SpinLock {
  2.   private AtomicReference<Thread> sign =new AtomicReference<>();
  4.   public void lock(){
  5.     Thread current = Thread.currentThread();
  6.     while(!sign .compareAndSet(null, current)){
  7.     }
  8.   }
  10.   public void unlock (){
  11.     Thread current = Thread.currentThread();
  12.     sign .compareAndSet(current, null);
  13.   }
  14. }

使用了CAS原子操作，lock函数将owner设置为当前线程，并且预测原来的值为空。unlock函数将owner设置为null，并且预测值为当前线程。
当有第二个线程调用lock操作时由于owner值不为空，导致循环一直被执行，直至第一个线程调用unlock函数将owner设置为null，第二个线程才能进入临界区。
由于自旋锁只是将当前线程不停地执行循环体，不进行线程状态的改变，所以响应速度更快。但当线程数不停增加时，性能下降明显，因为每个线程都需要执行，占用CPU时间。如果线程竞争不激烈，并且保持锁的时间段。适合使用自旋锁。
注：该例子为非公平锁，获得锁的先后顺序，不会按照进入lock的先后顺序进行。

4、自旋锁的其他种类

前面讲到了自旋锁，在自旋锁中 另有三种常见的锁形式:TicketLock ，CLHlock 和MCSlock。
Ticket锁主要解决的是访问顺序的问题，主要的问题是在多核cpu上

  1. public class TicketLock {
  2.     private AtomicInteger                     serviceNum = new AtomicInteger();
  3.     private AtomicInteger                     ticketNum  = new AtomicInteger();
  4.     private static final ThreadLocal<Integer> LOCAL      = new ThreadLocal<Integer>();
  6.     public void lock() {
  7.         int myticket = ticketNum.getAndIncrement();
  8.         LOCAL.set(myticket);
  9.         while (myticket != serviceNum.get()) {
  10.         }
  12.     }
  14.     public void unlock() {
  15.         int myticket = LOCAL.get();
  16.         serviceNum.compareAndSet(myticket, myticket + 1);
  17.     }
  18. }

每次都要查询一个serviceNum 服务号，影响性能（必须要到主内存读取，并阻止其他cpu修改）。
CLHLock 和MCSLock 则是两种类型相似的公平锁，采用链表的形式进行排序：

  1. import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
  3. public class CLHLock {
  4.     public static class CLHNode {
  5.         private volatile boolean isLocked = true;
  6.     }
  8.     @SuppressWarnings("unused")
  9.     private volatile CLHNode                                           tail;
  10.     private static final ThreadLocal<CLHNode>                          LOCAL   = new ThreadLocal<CLHNode>();
  11.     private static final AtomicReferenceFieldUpdater<CLHLock, CLHNode> UPDATER = AtomicReferenceFieldUpdater.newUpdater(CLHLock.class,
  12.                                                                                    CLHNode.class, "tail");
  14.     public void lock() {
  15.         CLHNode node = new CLHNode();
  16.         LOCAL.set(node);
  17.         CLHNode preNode = UPDATER.getAndSet(this, node);
  18.         if (preNode != null) {
  19.             while (preNode.isLocked) {
  20.             }
  21.             preNode = null;
  22.             LOCAL.set(node);
  23.         }
  24.     }
  26.     public void unlock() {
  27.         CLHNode node = LOCAL.get();
  28.         if (!UPDATER.compareAndSet(this, node, null)) {
  29.             node.isLocked = false;
  30.         }
  31.         node = null;
  32.     }
  33. }

CLHlock是不停的查询前驱变量， 导致不适合在NUMA 架构下使用（在这种结构下，每个线程分布在不同的物理内存区域）。
MCSLock则是对本地变量的节点进行循环。不存在CLHlock 的问题。

  1. import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
  3. public class MCSLock {
  4.     public static class MCSNode {
  5.         volatile MCSNode next;
  6.         volatile boolean isLocked = true;
  7.     }
  9.     private static final ThreadLocal<MCSNode>                          NODE    = new ThreadLocal<MCSNode>();
  10.     @SuppressWarnings("unused")
  11.     private volatile MCSNode                                           queue;
  12.     private static final AtomicReferenceFieldUpdater<MCSLock, MCSNode> UPDATER = AtomicReferenceFieldUpdater.newUpdater(MCSLock.class,
  13.                                                                                    MCSNode.class, "queue");
  15.     public void lock() {
  16.         MCSNode currentNode = new MCSNode();
  17.         NODE.set(currentNode);
  18.         MCSNode preNode = UPDATER.getAndSet(this, currentNode);
  19.         if (preNode != null) {
  20.             preNode.next = currentNode;
  21.             while (currentNode.isLocked) {
  23.             }
  24.         }
  25.     }
  27.     public void unlock() {
  28.         MCSNode currentNode = NODE.get();
  29.         if (currentNode.next == null) {
  30.             if (UPDATER.compareAndSet(this, currentNode, null)) {
  32.             } else {
  33.                 while (currentNode.next == null) {
  34.                 }
  35.             }
  36.         } else {
  37.             currentNode.next.isLocked = false;
  38.             currentNode.next = null;
  39.         }
  40.     }
  41. }

从代码上 看，CLH 要比 MCS 更简单，
CLH 的队列是隐式的队列，没有真实的后继结点属性。
MCS 的队列是显式的队列，有真实的后继结点属性。
JUC ReentrantLock 默认内部使用的锁 即是 CLH锁（有很多改进的地方，将自旋锁换成了阻塞锁等等）。

5、阻塞锁

阻塞锁，与自旋锁不同，改变了线程的运行状态。
在JAVA环境中，线程Thread有如下几个状态：
1，新建状态
2，就绪状态
3，运行状态
4，阻塞状态
5，死亡状态
阻塞锁，可以说是让线程进入阻塞状态进行等待，当获得相应的信号（唤醒，时间） 时，才可以进入线程的准备就绪状态，准备就绪状态的所有线程，通过竞争，进入运行状态。
JAVA中，能够进入\退出、阻塞状态或包含阻塞锁的方法有 ，synchronized 关键字（其中的重量锁）ReentrantLock，Object.wait()\notify(),LockSupport.park()/unpart()(j.u.c经常使用)
下面是一个JAVA 阻塞锁实例:

  1. import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
  2. import java.util.concurrent.locks.LockSupport;
  4. public class CLHLock1 {
  5.     public static class CLHNode {
  6.         private volatile Thread isLocked;
  7.     }
  9.     @SuppressWarnings("unused")
  10.     private volatile CLHNode                                            tail;
  11.     private static final ThreadLocal<CLHNode>                           LOCAL   = new ThreadLocal<CLHNode>();
  12.     private static final AtomicReferenceFieldUpdater<CLHLock1, CLHNode> UPDATER = AtomicReferenceFieldUpdater.newUpdater(CLHLock1.class,
  13.                                                                                     CLHNode.class, "tail");
  15.     public void lock() {
  16.         CLHNode node = new CLHNode();
  17.         LOCAL.set(node);
  18.         CLHNode preNode = UPDATER.getAndSet(this, node);
  19.         if (preNode != null) {
  20.             preNode.isLocked = Thread.currentThread();
  21.             LockSupport.park(this);
  22.             preNode = null;
  23.             LOCAL.set(node);
  24.         }
  25.     }
  27.     public void unlock() {
  28.         CLHNode node = LOCAL.get();
  29.         if (!UPDATER.compareAndSet(this, node, null)) {
  30.             System.out.println("unlock\t" + node.isLocked.getName());
  31.             LockSupport.unpark(node.isLocked);
  32.         }
  33.         node = null;
  34.     }
  35. }

在这里我们使用了LockSupport.unpark()的阻塞锁。 该例子是将CLH锁修改而成。
阻塞锁的优势在于，阻塞的线程不会占用cpu时间， 不会导致 CPu占用率过高，但进入时间以及恢复时间都要比自旋锁略慢。
在竞争激烈的情况下 阻塞锁的性能要明显高于 自旋锁。
理想的情况则是; 在线程竞争不激烈的情况下，使用自旋锁，竞争激烈的情况下使用，阻塞锁。

6、可重入锁

本文里面讲的是广义上的可重入锁，而不是单指JAVA下的ReentrantLock。
可重入锁，也叫做递归锁，指的是同一线程 外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。
在JAVA环境下 ReentrantLock 和synchronized 都是 可重入锁。
下面是使用实例

  1. public class Test implements Runnable{
  3.     public synchronized void get(){
  4.         System.out.println(Thread.currentThread().getId());
  5.         set();
  6.     }
  8.     public synchronized void set(){
  9.         System.out.println(Thread.currentThread().getId());
  10.     }
  12.     @Override
  13.     public void run() {
  14.         get();
  15.     }
  16.     public static void main(String[] args) {
  17.         Test ss=new Test();
  18.         new Thread(ss).start();
  19.         new Thread(ss).start();
  20.         new Thread(ss).start();
  21.     }
  22. }
  1. public class Test implements Runnable {
  2.     ReentrantLock lock = new ReentrantLock();
  4.     public void get() {
  5.         lock.lock();
  6.         System.out.println(Thread.currentThread().getId());
  7.         set();
  8.         lock.unlock();
  9.     }
  11.     public void set() {
  12.         lock.lock();
  13.         System.out.println(Thread.currentThread().getId());
  14.         lock.unlock();
  15.     }
  17.     @Override
  18.     public void run() {
  19.         get();
  20.     }
  22.     public static void main(String[] args) {
  23.         Test ss = new Test();
  24.         new Thread(ss).start();
  25.         new Thread(ss).start();
  26.         new Thread(ss).start();
  27.     }
  28. }

两个例子最后的结果都是正确的，即 同一个线程id被连续输出两次。
结果如下：
Threadid: 8
Threadid: 8
Threadid: 10
Threadid: 10
Threadid: 9
Threadid: 9
可重入锁最大的作用是避免死锁
我们以自旋锁作为例子:

  1. public class SpinLock {
  2.     private AtomicReference<Thread> owner =new AtomicReference<>();
  3.     public void lock(){
  4.         Thread current = Thread.currentThread();
  5.         while(!owner.compareAndSet(null, current)){
  6.         }
  7.     }
  8.     public void unlock (){
  9.         Thread current = Thread.currentThread();
  10.         owner.compareAndSet(current, null);
  11.     }
  12. }

对于自旋锁来说，
1、若有同一线程两调用lock() ，会导致第二次调用lock位置进行自旋，产生了死锁
说明这个锁并不是可重入的。（在lock函数内，应验证线程是否为已经获得锁的线程）
2、若1问题已经解决，当unlock（）第一次调用时，就已经将锁释放了。实际上不应释放锁。
（采用计数次进行统计）
修改之后，如下：

  1. public class SpinLock1 {
  2.     private AtomicReference<Thread> owner =new AtomicReference<>();
  3.     private int count =0;
  4.     public void lock(){
  5.         Thread current = Thread.currentThread();
  6.         if(current==owner.get()) {
  7.             count++;
  8.             return ;
  9.         }
  11.         while(!owner.compareAndSet(null, current)){
  13.         }
  14.     }
  15.     public void unlock (){
  16.         Thread current = Thread.currentThread();
  17.         if(current==owner.get()){
  18.             if(count!=0){
  19.                 count--;
  20.             }else{
  21.                 owner.compareAndSet(current, null);
  22.             }
  24.         }
  26.     }
  27. }

该自旋锁即为可重入锁。

7、读写锁

读写锁：分为读锁和写锁，多个读锁不互斥，读锁与写锁互斥，这是由jvm自己控制的，你只要上好相应的锁即可。如果你的代码只读数据，可以很多人同时读，但不能同时写，那就上读锁；如果你的代码修改数据，只能有一个人在写，且不能同时读取，那就上写锁。总之，读的时候上读锁，写的时候上写锁！
ReentrantReadWriteLock会使用两把锁来解决问题，一个读锁，一个写锁，线程进入读锁的前提条件：
没有其他线程的写锁；
没有写请求或者有写请求，但调用线程和持有锁的线程是同一个。
线程进入写锁的前提条件：
没有其他线程的读锁；
没有其他线程的写锁。
到ReentrantReadWriteLock，首先要做的是与ReentrantLock划清界限。它和后者都是单独的实现，彼此之间没有继承或实现的关系。然后就是总结这个锁机制的特性了：
(a).重入方面其内部的WriteLock可以获取ReadLock，但是反过来ReadLock想要获得WriteLock则永远都不要想。
(b).WriteLock可以降级为ReadLock，顺序是：先获得WriteLock再获得ReadLock，然后释放WriteLock，这时候线程将保持Readlock的持有。反过来ReadLock想要升级为WriteLock则不可能，为什么？参看(a)，呵呵.
(c).ReadLock可以被多个线程持有并且在作用时排斥任何的WriteLock，而WriteLock则是完全的互斥。这一特性最为重要，因为对于高读取频率而相对较低写入的数据结构，使用此类锁同步机制则可以提高并发量。
(d).不管是ReadLock还是WriteLock都支持Interrupt，语义与ReentrantLock一致。
(e).WriteLock支持Condition并且与ReentrantLock语义一致，而ReadLock则不能使用Condition，否则抛出UnsupportedOperationException异常。

8、互斥锁

相交进程之间的关系主要有两种，同步与互斥。所谓互斥，是指散布在不同进程之间的若干程序片断，当某个进程运行其中一个程序片段时，其它进程就不能运行它们之中的任一程序片段，只能等到该进程运行完这个程序片段后才可以运行。所谓同步，是指散布在不同进程之间的若干程序片断，它们的运行必须严格按照规定的某种先后次序来运行，这种先后次序依赖于要完成的特定的任务。
显然，同步是一种更为复杂的互斥，而互斥是一种特殊的同步。
也就是说互斥是两个线程之间不可以同时运行，他们会相互排斥，必须等待一个线程运行完毕，另一个才能运行，而同步也是不能同时运行，但他是必须要安照某种次序来运行相应的线程（也是一种互斥）！
总结：互斥：是指某一资源同时只允许一个访问者对其进行访问，具有唯一性和排它性。但互斥无法限制访问者对资源的访问顺序，即访问是无序的。
同步：是指在互斥的基础上（大多数情况），通过其它机制实现访问者对资源的有序访问。在大多数情况下，同步已经实现了互斥，特别是所有写入资源的情况必定是互斥的。少数情况是指可以允许多个访问者同时访问资源。

9、悲观锁/乐观锁

线程中的锁可以分为乐观锁和悲观锁，这两个都是实现锁机制的两种办法。
悲观锁：根据字面意思，悲观，就是不是太好的。当一个线程访问这个数据的时候，悲观锁会把这个数据给锁住，不被其他线程所访问，直到这个线程完成了对数据的提交后，其他线程才能够访问或者操作。这样就带来了不便，比如，我们在进行网上订票的时候，一个用户访问了这个系统，访问了这个系统中数据库的数据，就把这个数据给锁住了，这样其他用户根本就看不到数据。这样显然不行，我们想要的效果是用户都可以访问数据，但是只有一个用户提交对这个数据的修改。这就要乐观锁。
乐观锁：当用户要对这个数据进行修改操作时，才把这个数据锁住，也就是实现了一个用户提交操作的用途，它的好处是，用户在查看的时候，数据并没有锁住，当要修改提交的时候，把数据锁住，当其他用户再要提交修改时，就不能修改了。其中的乐观锁里面有一个版本控制器，当修改后，版本就+1，其他用户现在的版本还是0，这样在提交的时候，发现版本号低于现在的，所以，要更新，之后在进行修改。

10、公平锁/非公平锁

jdk1.5并发包中ReentrantLock的创建可以指定构造函数的boolean类型来得到公平锁或非公平锁，关于两者区别，java并发编程实践里面有解释。
公平锁： Threads acquire a fair lock in the order in which they requested it
非公平锁：a nonfair lock permits barging: threads requesting a lock can jump ahead of the queue
of waiting threads if the lock happens to be available when it is requested.
公平锁，就是很公平，在并发环境中，每个线程在获取锁时会先查看此锁维护的等待队列，如果为空，或者当前线程线程是等待队列的第一个，就占有锁，否则就会加入到等待队列中，以后会按照FIFO的规则从队列中取到自己。
非公平锁比较粗鲁，上来就直接尝试占有锁，如果尝试失败，就再采用类似公平锁那种方式。
事实上公平的锁机制往往没有非公平的效率高，因为公平的获取锁没有考虑到操作系统对线程的调度因素，这样造成JVM对于等待中的线程调度次序和操作系统对线程的调度之间的不匹配。对于锁的快速且重复的获取过程中，连续获取的概率是非常高的，而公平锁会压制这种情况，虽然公平性得以保障，但是响应比却下降了，但是并不是任何场景都是以TPS作为唯一指标的，因为公平锁能够减少“饥饿”发生的概率，等待越久的请求越是能够得到优先满足。
实现分析
在ReentrantLock中，对于公平和非公平的定义是通过对同步器AbstractQueuedSynchronizer的扩展加以实现的，也就是在tryAcquire的实现上做了语义的控制。
非公平的获取语义：

  1.  final boolean nonfairTryAcquire(int acquires) {
  2.     final Thread current = Thread.currentThread();
  3.     int c = getState();
  4.     if (c == 0) {
  5.         if (compareAndSetState(0, acquires)) {
  6.             setExclusiveOwnerThread(current);
  7.             return true;
  8.         }
  9.     } else if (current == getExclusiveOwnerThread()) {
  10.         int nextc = c + acquires;
  11.                 if (nextc < 0) // overflow
  12.             throw new Error("Maximum lock count exceeded");
  13.         setState(nextc);
  14.         return true;
  15.     }
  16.     return false;
  17. }

上述逻辑主要包括：
如果当前状态为初始状态，那么尝试设置状态；
如果状态设置成功后就返回；
如果状态被设置，且获取锁的线程又是当前线程的时候，进行状态的自增；
如果未设置成功状态且当前线程不是获取锁的线程，那么返回失败。
公平的获取语义：

  1. protected final boolean tryAcquire(int acquires) {
  2.     final Thread current = Thread.currentThread();
  3.     int c = getState();
  4.     if (c == 0) {
  5.         if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {
  6.             setExclusiveOwnerThread(current);
  7.             return true;
  8.         }
  9.     } else if (current == getExclusiveOwnerThread()) {
  10.         int nextc = c + acquires;
  11.         if (nextc < 0)
  12.             throw new Error("Maximum lock count exceeded");
  13.         setState(nextc);
  14.         return true;
  15.     }
  16.     return false;
  17. }

上述逻辑相比较非公平的获取，仅加入了当前线程（Node）之前是否有前置节点在等待的判断。hasQueuedPredecessors()方法命名有些歧义，其实应该是currentThreadHasQueuedPredecessors()更为妥帖一些，也就是说当前面没有人排在该节点（Node）前面时候队且能够设置成功状态，才能够获取锁。
释放语义：

  1. protected final boolean tryRelease(int releases) {
  2.     int c = getState() - releases;
  3.     if (Thread.currentThread() != getExclusiveOwnerThread())
  4.         throw new IllegalMonitorStateException();
  5.     boolean free = false;
  6.     if (c == 0) {
  7.         free = true;
  8.         setExclusiveOwnerThread(null);
  9.     }
  10.     setState(c);
  11.     return free;
  12. }

上述逻辑主要主要计算了释放状态后的值，如果为0则完全释放，返回true，反之仅是设置状态，返回false。
下面将主要的笔墨放在公平性和非公平性上，首先看一下二者测试的对比：
测试用例如下：

  1. public class ReentrantLockTest {
  2.     private static Lock fairLock = new ReentrantLock(true);
  3.     private static Lock unfairLock = new ReentrantLock();
  5.     @Test
  6.     public void fair() {
  7.         System.out.println("fair version");
  8.         for (int i = 0; i < 5; i++) {
  9.             Thread thread = new Thread(new Job(fairLock));
  10.             thread.setName("" + i);
  11.             thread.start();
  12.         }
  14.         try {
  15.             Thread.sleep(5000);
  16.         } catch (InterruptedException e) {
  17.             e.printStackTrace();
  18.         }
  19.     }
  21.     @Test
  22.     public void unfair() {
  23.         System.out.println("unfair version");
  24.         for (int i = 0; i < 5; i++) {
  25.             Thread thread = new Thread(new Job(unfairLock));
  26.             thread.setName("" + i);
  27.             thread.start();
  28.         }
  30.         try {
  31.             Thread.sleep(5000);
  32.         } catch (InterruptedException e) {
  33.             e.printStackTrace();
  34.         }
  35.     }
  37.     private static class Job implements Runnable {
  38.         private Lock lock;
  39.         public Job(Lock lock) {
  40.             this.lock = lock;
  41.         }
  43.         @Override
  44.         public void run() {
  45.             for (int i = 0; i < 5; i++) {
  46.                 lock.lock();
  47.                 try {
  48.                     System.out.println("Lock by:"
  49.                             + Thread.currentThread().getName());
  50.                 } finally {
  51.                     lock.unlock();
  52.                 }
  53.             }
  54.         }
  55.     }
  56. }

调用非公平的测试方法，返回结果(部分)：

  1. unfair version
  2. Lock by:0
  3. Lock by:0
  4. Lock by:2
  5. Lock by:2
  6. Lock by:2
  7. Lock by:2
  8. Lock by:2
  9. Lock by:0
  10. Lock by:0
  11. Lock by:0
  12. Lock by:1
  13. Lock by:1
  14. Lock by:1

调用公平的测试方法，返回结果：

  1. fair version
  2. Lock by:0
  3. Lock by:1
  4. Lock by:0
  5. Lock by:2
  6. Lock by:3
  7. Lock by:4
  8. Lock by:1
  9. Lock by:0
  10. Lock by:2
  11. Lock by:3
  12. Lock by:4

仔细观察返回的结果(其中每个数字代表一个线程)，非公平的结果一个线程连续获取锁的情况非常多，而公平的结果连续获取的情况基本没有。那么在一个线程获取了锁的那一刻，究竟锁的公平性会导致锁有什么样的处理逻辑呢？
通过之前的同步器(AbstractQueuedSynchronizer)的介绍，在锁上是存在一个等待队列，sync队列，我们通过复写ReentrantLock的获取当前锁的sync队列，输出在ReentrantLock被获取时刻，当前的sync队列的状态。
修改测试如下：

  1. public class ReentrantLockTest {
  2.     private static Lock fairLock = new ReentrantLock2(true);
  3.     private static Lock unfairLock = new ReentrantLock2();
  4.     @Test
  5.     public void fair() {
  6.         System.out.println("fair version");
  7.         for (int i = 0; i < 5; i++) {
  8.             Thread thread = new Thread(new Job(fairLock)) {
  9.                 public String toString() {
  10.                     return getName();
  11.                 }
  12.             };
  13.             thread.setName("" + i);
  14.             thread.start();
  15.         }
  16.         // sleep 5000ms
  17.     }
  19.     @Test
  20.     public void unfair() {
  21.         System.out.println("unfair version");
  22.         for (int i = 0; i < 5; i++) {
  23.             Thread thread = new Thread(new Job(unfairLock)) {
  24.                 public String toString() {
  25.                     return getName();
  26.                 }
  27.             };
  28.             thread.setName("" + i);
  29.             thread.start();
  30.         }
  31.         // sleep 5000ms
  32.     }
  34.     private static class Job implements Runnable {
  35.         private Lock lock;
  37.         public Job(Lock lock) {
  38.             this.lock = lock;
  39.         }
  41.         @Override
  42.         public void run() {
  43.             for (int i = 0; i < 5; i++) {
  44.                 lock.lock();
  45.                 try {
  46.                     System.out.println("Lock by:"
  47.                             + Thread.currentThread().getName() + " and "
  48.                             + ((ReentrantLock2) lock).getQueuedThreads()
  49.                             + " waits.");
  50.                 } finally {
  51.                     lock.unlock();
  52.                 }
  53.             }
  54.         }
  55.     }
  57.     private static class ReentrantLock2 extends ReentrantLock {
  58.         // Constructor Override
  60.         private static final long serialVersionUID = 1773716895097002072L;
  62.         public Collection<Thread> getQueuedThreads() {
  63.             return super.getQueuedThreads();
  64.         }
  65.     }
  66. }

上述逻辑主要是通过构造ReentrantLock2用来输出在sync队列中的线程内容，而且每个线程的toString方法被重写，这样当一个线程获取到锁时，sync队列里的内容也就可以得知了，运行结果如下：
调用非公平方法，返回结果：

  1. unfair version
  2. Lock by:0 and [] waits.
  3. Lock by:0 and [] waits.
  4. Lock by:3 and [2, 1] waits.
  5. Lock by:3 and [4, 2, 1] waits.
  6. Lock by:3 and [4, 2, 1] waits.
  7. Lock by:3 and [0, 4, 2, 1] waits.
  8. Lock by:3 and [0, 4, 2, 1] waits.
  9. Lock by:1 and [0, 4, 2] waits.
  10. Lock by:1 and [0, 4, 2] waits.

调用公平方法，返回结果：

  1. fair version
  2. Lock by:0 and [] waits.
  3. Lock by:1 and [0, 4, 3, 2] waits.
  4. Lock by:2 and [1, 0, 4, 3] waits.
  5. Lock by:3 and [2, 1, 0, 4] waits.
  6. Lock by:4 and [3, 2, 1, 0] waits.
  7. Lock by:0 and [4, 3, 2, 1] waits.
  8. Lock by:1 and [0, 4, 3, 2] waits.
  9. Lock by:2 and [1, 0, 4, 3] waits.

可以明显看出，在非公平获取的过程中，“插队”现象非常严重，后续获取锁的线程根本不顾及sync队列中等待的线程，而是能获取就获取。反观公平获取的过程，锁的获取就类似线性化的，每次都由sync队列中等待最长的线程（链表的第一个，sync队列是由尾部结点添加，当前输出的sync队列是逆序输出）获取锁。一个 hasQueuedPredecessors方法能够获得公平性的特性，这点实际上是由AbstractQueuedSynchronizer来完成的，看一下acquire方法：

  1. public final void acquire(int arg) {
  2.     if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
  3.         selfInterrupt();
  4. }

可以看到，如果获取状态和在sync队列中排队是短路的判断，也就是说如果tryAcquire成功，那么是不会进入sync队列的，可以通过下图来深刻的认识公平性和AbstractQueuedSynchronizer的获取过程。
非公平的，或者说默认的获取方式如下图所示：
线程锁 - 图5
对于状态的获取，可以快速的通过tryAcquire的成功，也就是黄色的Fast路线，也可以由于tryAcquire的失败，构造节点，进入sync队列中排序后再次获取。因此可以理解为Fast就是一个快速通道，当例子中的线程释放锁之后，快速的通过Fast通道再次获取锁，就算当前sync队列中有排队等待的线程也会被忽略。这种模式，可以保证进入和退出锁的吞吐量，但是sync队列中过早排队的线程会一直处于阻塞状态，造成“饥饿”场景。
而公平性锁，就是在tryAcquire的调用中顾及当前sync队列中的等待节点（废弃了Fast通道），也就是任意请求都需要按照sync队列中既有的顺序进行，先到先得。这样很好的确保了公平性，但是可以从结果中看到，吞吐量就没有非公平的锁高了。

11、类锁/对象锁

一个对象里面如果有多个synchronized方法，某一个时刻内，只要一个线程去调用其中的一个synchronized方法了，其它的线程都只能等待，换句话说，某一个时刻内，只能有唯一一个线程去访问这些synchronized方法。
所有的非静态同步方法用的都是同一把锁——实例对象本身，也就是说如果一个实例对象的非静态同步方法获取锁后，该实例对象的其他非静态同步方法必须等待获取锁的方法释放锁后才能获取锁，可是别的实例对象的非静态同步方法因为跟该实例对象的非静态同步方法用的是不同的锁，所以毋须等待该实例对象已获取锁的非静态同步方法释放锁就可以获取他们自己的锁。
所有的静态同步方法用的也是同一把锁——类对象本身，这两把锁是两个不同的对象，所以静态同步方法与非静态同步方法之间是不会有竞态条件的。但是一旦一个静态同步方法获取锁后，其他的静态同步方法都必须等待该方法释放锁后才能获取锁，而不管是同一个实例对象的静态同步方法之间，还是不同的实例对象的静态同步方法之间，只要它们同一个类的实例对象！
具体的翻阅多线程(四) 线程同步(上)－synchronized,volatile。

12、锁粗化

锁粗化的概念应该比较好理解，就是将多次连接在一起的加锁、解锁操作合并为一次，将多个连续的锁扩展成一个范围更大的锁。举个例子：

  1. package com.paddx.test.string;
  3. public class StringBufferTest {
  4.     StringBuffer stringBuffer = new StringBuffer();
  6.     public void append(){
  7.         stringBuffer.append("a");
  8.         stringBuffer.append("b");
  9.         stringBuffer.append("c");
  10.     }
  11. }

这里每次调用stringBuffer.append方法都需要加锁和解锁，如果虚拟机检测到有一系列连串的对同一个对象加锁和解锁操作，就会将其合并成一次范围更大的加锁和解锁操作，即在第一次append方法时进行加锁，最后一次append方法结束后进行解锁。

13、锁消除

锁消除即删除不必要的加锁操作。根据代码逃逸技术，如果判断到一段代码中，堆上的数据不会逃逸出当前线程，那么可以认为这段代码是线程安全的，不必要加锁。看下面这段程序：

  1. public class SynchronizedTest02 {
  3.     public static void main(String[] args) {
  4.         SynchronizedTest02 test02 = new SynchronizedTest02();
  5.         //启动预热
  6.         for (int i = 0; i < 10000; i++) {
  7.             i++;
  8.         }
  9.         long start = System.currentTimeMillis();
  10.         for (int i = 0; i < 100000000; i++) {
  11.             test02.append("abc", "def");
  12.         }
  13.         System.out.println("Time=" + (System.currentTimeMillis() - start));
  14.     }
  16.     public void append(String str1, String str2) {
  17.         StringBuffer sb = new StringBuffer();
  18.         sb.append(str1).append(str2);
  19.     }
  20. }

虽然StringBuffer的append是一个同步方法，但是这段程序中的StringBuffer属于一个局部变量，并且不会从该方法中逃逸出去，所以其实这过程是线程安全的，可以将锁消除。下面是我本地执行的结果：
线程锁 - 图6
为了尽量减少其他因素的影响，这里禁用了偏向锁（-XX:-UseBiasedLocking）。通过上面程序，可以看出消除锁以后性能还是有比较大提升的。
注：可能JDK各个版本之间执行的结果不尽相同，这里采用的JDK版本为1.6。

14、锁膨胀

如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。 如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（膨胀）到整个操作序列的外部（由多次加锁编程只加锁一次）。

15、信号量
信号量前面讲过啦，就不再重复啦！文章链接：多线程(十)CountDownLatch、CyclicBarrier和Semaphore

总结

本文介绍了JDk中采用轻量级锁和偏向锁等对Synchronized的优化，但是这两种锁也不是完全没缺点的，比如竞争比较激烈的时候，不但无法提升效率，反而会降低效率，因为多了一个锁升级的过程，这个时候就需要通过-XX:-UseBiasedLocking来禁用偏向锁。下面是这几种锁的对比：

锁 优点 缺点 适用场景
偏向锁 加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距。 如果线程间存在锁竞争，会带来额外的锁撤销的消耗。 适用于只有一个线程访问同步块场景。
轻量级锁 竞争的线程不会阻塞，提高了程序的响应速度。 如果始终得不到锁竞争的线程使用自旋会消耗CPU。 追求响应时间。同步块执行速度非常快。
重量级锁 线程竞争不使用自旋，不会消耗CPU。 线程阻塞，响应时间缓慢。 追求吞吐量。同步块执行速度较长。