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
