3 java.util.concurrent.locks包

前面介绍过了Java中的“隐式锁”——synchronized关键字，在使用synchronized关键字的时候，会在生成的字节码中包含对应的指令或者标记。JVM在执行的时候，会根据这些标记获取和释放锁。锁的获取和释放都是由JVM控制的，我们并不能根据自己的需求控制获取锁和释放锁的一些细节。
如果需要可操作性、可控制性更强的锁，Java中提供了java.util.concurrent.locks包，其中有一些有用的锁的接口和实现。

3.1 Lock接口

在java.util.concurrent.locks 这个包中提供了Lock接口，该接口的定义如下：

public interface Lock {
  void lock();
  void lockInterruptibly();
  boolean tryLock();
  boolean tryLock(long time, TimeUnit unit) throw InterruptedException;
  boolean unlock();
  Condition newCondition();
}

这其中的lock方法和unlock方法没有什么好讲的，其实作用和synchronized(lock)差不多。lock方法会阻塞式的等待锁。

lockInterrupitbly()方法中，获取到锁的线程被中断的时候，会抛出中断异常，并释放持有的锁。使用synchronized关键字获取锁的线程是做不到这一点的。

tryLock()方法则不会阻塞，如果没有获取到锁，会立即返回false，不会一直等待。

tryLock(long time, TimeUnit unit)则会在指定的时间段内等待锁。如果没有等到，则返回false。

最后一个方法newCondition()，这个是用于获取Condition对象，该对象用于线程之间的同步，这里我们就不涉及了。

3.2 Lock接口的实现类ReentrantLock

同时，Java还提供了Lock接口的实现类ReentrantLock。从名字上就可以看出，这是一个可重入锁。该类的实现，依赖于其中的一个内部抽象类Sync，该类有两个具体的实现NonfairSync和FairSync。一个用于实现非公平锁，一个用于实现公平锁。具体的获取锁和释放锁的逻辑，其实都在Sync类及其两个子类中。
ReentrantLock是怎样实现可重入的呢？在ReentrantLock中，会有一个变量用来保存当前持有锁的线程对象。（实际上是在Sync对象中持有该变量，为了叙述方便，后面不再详细区分，有兴趣的可以自己看看源码。）

protected final boolean tryAcquire(int acquires) {
         final Thread current = Thread.currentThread(); //获取当前线程
         int c = getState(); //获取当前同步状态的值
         if (c == 0) { //当前同步状态没有被任何线程获取的时候
             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;
}

上面的代码主要是一个if...else...语句。主体的逻辑是：

• 如果当前锁没有给任何线程持有，则直接获取锁（获取锁的方式使用的是compareAndSetState，底层实际上使用的是Compare And Swap（CAS）机制来实实现的）。获取成功则返回true来表示获取锁成功。
• 如果当前锁已经被其他线程持有，那么判断持有锁的线程是否是当前线程，如果是的话，则增加锁的计数，返回true，表示获取锁成功。
• 如果前面两条都没有成功，则返回false，表示获取锁失败。

可重入锁的释放也不是立即直接释放，而是每次减少计数，直到计数为0。如下面的代码所示：

protected final boolean tryRelease(int releases) {
            int c = getState() - releases;
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
            if (c == 0) {
                free = true;
                setExclusiveOwnerThread(null);
            }
            setState(c);
            return free;
        }

在实例化ReentrantLock类的时候，可以传入一个boolean类型的参数，用于指定是需要公平锁还是非公平锁（默认是非公平锁）。

通常来说，该类的使用方式如下：

private Lock lock = new ReentrantLock();   // 默认使用非公平锁

public void someMethodUsingLock(){
  ......
  lock.lock();
  try{
     ......
  } catch (Exception e){
    ......
  } finally {
    lock.unlock();
  }
} 

上面的代码中，我们没有将lock.lock()这一行代码放在try中，是因为如果放在try中，并且在执行这一行代码的时候抛出了异常，那么就会进入finally的代码块中，会执行lock.unlock()，但是实际上当前线程可能并没有获取到锁，执行unlock又会抛出异常。

可重入特性实现了，那么公平/非公平又是怎么实现的？公平和非公平在tryLock(long time, TimeUnit unit)这个方法中有不同。我们一直跟踪到具体实现，让我们看看代码：

//非公平锁的实现代码
            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;

//公平锁的实现代码
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                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;

可以看到，唯一的不同就是一个调用，公平锁在获取锁之前，调用了!hasQueuedPredecessors()，先判断是否有其他的线程已经在排队了。

3.3 读写锁接口ReadWriteLock

在最开始的一篇文章中，我们已经提到了读写锁，并且说读写锁其实是一个组合锁。我们来看看Java中给出的ReadWriteLock接口：

public interface ReadWriteLock {
   Lock readLock();

   Lock writeLock();
}

在Java给出的实现类ReentrantReadWriteLock中，分别实现了ReadLock和WriteLock类。它们的不同在于，在ReadLock的中，获取锁的代码是

public void lock() {
    sync.acquireShared(1);
}

但是在WriteLock中，获取锁的代码是

public void lock() {
    sync.acquire(1);
}

从名字上就可以看出，一个是共享锁，一个是排他锁。具体的实现方式，大家可以自己去看看源代码。

3.4 乐观读写锁StampedLock

前面我们介绍的这些锁的实现，都是悲观锁，包括上面的ReentrantReadWriteLock。在ReentrantReadWriteLock中，在读的时候是不能写的，在写的时候也是不能读的。

在Java 8中，又引入了另外一种读写锁，StampedLock。这个锁和前面的ReentrantReadWriteLock的不同之处在于，StampedLock中，如果有线程获取了读锁，正在读取数据，另外一个线程可以获取写锁来写数据。 因此这种锁是一种乐观锁（至少在这种情况下是）。但是乐观锁带来的问题是读取的数据可能不一致，因此需要额外的代码来判断。大致的代码如下：

StampedLock stampedLock = new StampedLock();
......
long stamp = stampedLock.tryOptimisticRead(); // 获得一个乐观读锁
.......   //读取数据，可能是读取多个数据
if (!stampedLock.validate(stamp)) { // 检查乐观读锁后是否有其他写锁发生
   //说明读取过程中有写入操作，因此可能读取到错误的数据
    stamp = stampedLock.readLock(); // 获取一个悲观读锁
    try {
        ......  //重新读取数据
    } finally {
        stampedLock.unlockRead(stamp); // 释放悲观读锁
    }
}

3.5 小结

Java中提供了一些锁的接口和实现类，包括普通的Lock接口，ReadWriteLock接口，并且提供了相应的实现ReentrantLock，ReentrantReadWriteLock，StampedLock。这些锁可以通过chu'shi'h