ReentrantLock()和synchronized的原理

大自然的生存法则，在Java里也异常适用。

ReentrantLock默认就是采用非公平锁，让线程们自己去竞争。
ReentrantLock类里一共由三部分组成。

synchronized的局限性

synchronized是java内置的关键字，它提供了一种独占的加锁方式。synchronized的获取和释放锁由JVM实现，用户不需要显示的释放锁，非常方便。然而synchronized也有一定的局限性，例如：

1. 当线程尝试获取锁的时候，如果获取不到锁会一直阻塞。

2. 如果获取锁的线程进入休眠或者阻塞，除非当前线程异常，否则其他线程尝试获取锁必须一直等待。

   JDK1.5之后发布，加入了Doug Lea实现的concurrent包。包内提供了Lock类，用来提供更多扩展的加锁功能。Lock弥补了synchronized的局限，提供了更加细粒度的加锁功能。

AQS

AbstractQueuedSynchronizer简称AQS，是一个用于构建锁和同步容器的框架。事实上concurrent包内许多类都是基于AQS构建，例如ReentrantLock，Semaphore，CountDownLatch，ReentrantReadWriteLock，FutureTask等。AQS解决了在实现同步容器时设计的大量细节问题。

AQS使用一个FIFO的队列表示排队等待锁的线程，队列头节点称作“哨兵节点”或者“哑节点”，它不与任何线程关联。其他的节点与等待线程关联，每个节点维护一个等待状态waitStatus。
  AQS中还有一个表示状态的字段state，例如ReentrantLocky用它表示线程重入锁的次数，Semaphore用它表示剩余的许可数量，FutureTask用它表示任务的状态。对state变量值的更新都采用CAS操作保证更新操作的原子性。

源码分析

ReentrantLock类中有三个内部类。
Sync：继承AQS。
NonfairSync:继承Sync。
FairSync：继承Sync。

package java.util.concurrent.locks;
import java.util.concurrent.TimeUnit;
import java.util.Collection;

public class ReentrantLock implements Lock, java.io.Serializable {


  //首先，就是我们最经常使用的构造方法，默认使用的都是非公平锁。
  //NofairSync，就是不公平锁的意思。
  public ReentrantLock() {
        sync = new NonfairSync();
    }

    //这里,你也可以构造一个公平锁出来,传递true参数即可。
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }


    //下边这么长，是一个内部类Sync。
    //我们的公平锁，非公平锁都是集成Sync，自然里边的方法都可以用。
    //很长，不用看，看下边的公平锁和非公平锁就可以。
    abstract static class Sync extends AbstractQueuedSynchronizer {
    
		//非公平锁就是这个，非公平锁类里判断能不能获取锁就是通过这个方法搞的。
		//将非公平锁的这个方法，与公平锁的这个方法一对比。
		//其意自现。
        final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
    }


 	//非公平锁
    static final class NonfairSync extends Sync {
        private static final long serialVersionUID = 7316153563782823691L;

        /**
        这里可以看到这个方法compareAndSetState()
        比较并改变状态，简称CAS，这个和CAS思想是一样的。
        看看state是不是0，是0的话就修改状态为1.
        并获取锁，设置锁线程为当前自己线程。**/

		//非公平锁的lock方法
		//如果执行成功，则获取锁，失败，则执行acquire(1)方法。
		//acquire()方法在AbstractQueuedSynchronizer内部。
        final void lock() {
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);
        }
        
		//这里非公平锁调用了父类Sync里的方法，判断是否可以进入获取锁。
        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }
    }

   //公平锁
    static final class FairSync extends Sync {

		//上锁，修改状态state为1。
        final void lock() {
            acquire(1);
        }
		//在多线程竞争锁的时候，谁能获取小红的欢心，获取锁就是这个方法。
        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
            	//非公平锁那里的判断是两个
            	//公平锁这里的判断是三个判断
            	//相比非公平锁，这里多了一个判断，判断一下自己本线程是否在等待队列的首部。
            	//另外两个操作一样，都是CAS操作以及获取锁操作。
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
    }

  
    //这里是ReentrantLock的方法，可以看到它使用的是内部类Sync的方法。
    //所以使用ReentrantLock时，下边很多方法都是Sync的，其实就是使用的Sync。
    //默认使用的都是非公平锁的lock()方法。
    public void lock() {
        sync.lock();
    }

   //统一都是Sync的方法。
    public void lockInterruptibly() throws InterruptedException {
        sync.acquireInterruptibly(1);
    }

    //统一都是Sync的方法。
    public boolean tryLock() {
        return sync.nonfairTryAcquire(1);
    }

    //统一都是Sync的方法。
    public boolean tryLock(long timeout, TimeUnit unit)
            throws InterruptedException {
        return sync.tryAcquireNanos(1, unit.toNanos(timeout));
    }

    //统一都是Sync的方法。
    public void unlock() {
        sync.release(1);
    }

    //统一都是Sync的方法。
    public Condition newCondition() {
        return sync.newCondition();
    }
    
    //统一都是Sync的方法。
    public boolean isLocked() {
        return sync.isLocked();
    }

  	//统一都是Sync的方法。
    public final boolean isFair() {
        return sync instanceof FairSync;
    }

  	//统一都是Sync的方法。
    protected Thread getOwner() {
        return sync.getOwner();
    }

    //统一都是Sync的方法。
    public final boolean hasQueuedThreads() {
        return sync.hasQueuedThreads();
    }

    //统一都是Sync的方法。
    public final boolean hasQueuedThread(Thread thread) {
        return sync.isQueued(thread);
    }

    //统一都是Sync的方法。
    public final int getQueueLength() {
        return sync.getQueueLength();
    }

    //统一都是Sync的方法。
    protected Collection<Thread> getQueuedThreads() {
        return sync.getQueuedThreads();
    }

    //统一都是Sync的方法。
    public boolean hasWaiters(Condition condition) {
        if (condition == null)
            throw new NullPointerException();
        if (!(condition instanceof AbstractQueuedSynchronizer.ConditionObject))
            throw new IllegalArgumentException("not owner");
        return sync.hasWaiters((AbstractQueuedSynchronizer.ConditionObject)condition);
    }

    //统一都是Sync的方法。
    public int getWaitQueueLength(Condition condition) {
        if (condition == null)
            throw new NullPointerException();
        if (!(condition instanceof AbstractQueuedSynchronizer.ConditionObject))
            throw new IllegalArgumentException("not owner");
        return sync.getWaitQueueLength((AbstractQueuedSynchronizer.ConditionObject)condition);
    }

    //统一都是Sync的方法，看似你使用的是ReentrantLock但是实际上内部已经被Sync腐蚀了。
    protected Collection<Thread> getWaitingThreads(Condition condition) {
        if (condition == null)
            throw new NullPointerException();
        if (!(condition instanceof AbstractQueuedSynchronizer.ConditionObject))
            throw new IllegalArgumentException("not owner");
        return sync.getWaitingThreads((AbstractQueuedSynchronizer.ConditionObject)condition);
    }

   
    public String toString() {
        Thread o = sync.getOwner();
        return super.toString() + ((o == null) ?
                                   "[Unlocked]" :
                                   "[Locked by thread " + o.getName() + "]");
    }
}

执行流程

非公平锁
1、各个线程争夺CPU的执行权，线程小王争夺到了。

2、观察state为0，执行CAS操作，修改状态，修改持有线程为小王，并获取锁。

3、小王完事了，该小绿上场了，小绿观察state为0，我要进去了。

4、小绿在即将进去的那一刻，老王给他戴了帽子，因为老王也观察到state为0，身为老司机当然要比小绿厉害了。

5、小王获得锁。

公平锁
1、各个线程争夺CPU的执行权，线程小王争夺到了。

2、观察state为0，执行CAS操作，修改状态，修改持有线程为小王，并获取锁。

3、小王完事了，该小绿上场了，小绿观察state为0，我要进去了。

4、小绿在即将进去的那一刻，老王想给他戴帽子，但是老王的距离太短了，他是等待队列中的二号位，只有一号位才能给别人戴帽子。

5、小绿获得锁。

公平锁的实现多了一步，线程判断一下自己在不在队列的首位。

在首位，则获取锁。不在首位，等着吧。

有什么不同
公平锁与非公平锁就是等待队列中的线程排队不排队的问题。

公平锁/非公平锁优劣
公平锁
优点：大锅饭，统一分配资源。

缺点：性能下降很多，第一个线程释放锁后，如果还想再次获取锁，需要进入等待队列尾部，重新排队，进入阻塞状态，等待CPU唤醒。

非公平锁
优点：强者恒强，性能高。

缺点：弱者恒弱，抢不到饭吃。

为什么公平锁的性能低于非公平锁？

我们必须先知道，在恢复一个被挂起的线程与该线程真正开始运行之间存在着严重的延迟。

举个例子，a线程获取到了锁，现在b线程来请求锁。a线程释放锁唤醒b线程。b线程恢复运行状态。这里需要时间。如果允许插队，c线程刚刚好在a释放前请求锁。可能在c释放完锁后。b线程才真正开始运行起来。

其实就是说切换上下文的开销是比较大的。有时候我们可以用短时间的轮询获取锁会更快。