我们知道，java.util.concurrent.locks包下的Lock和Condition接口的语义是用来替代JDK1.5之前使用synchronize和Object.wait、Object.notify、Object.notifyAll组合，Effective Java一书中说过，JDK1.5及其以后，你几乎没有任何理由去选择使用synchronize和Object.wait、Object.notify、Object.notifyAll组合，除非是为了维护之前的代码。
除了Lock和Condition这两个接口，和锁相关的还有读写锁ReadWriteLock接口，这个会单独介绍，本文关注的是Lock和Condition。
我们先看看Lock接口的定义：
void lock();
void lockInterruptibly() throws InterruptedException;
boolean tryLock();
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
void unlock();
Condition newCondition();
可以看出，与synchronize相比，Lock的语义更加丰富，synchronize和Lock（的实现）都是可重入，但synchronize不会响应中断信号，也不能做到限时等待，它只会干等、无线等，这无法满足某些场景下的需求，所以，在你希望做到可中断等、可中断限时等、尝试获取锁时，你该考虑使用Lock的实现。
可重入锁ReentrantLock是Lock接口的直接实现，它也借助了AQS（关于AQS介绍，可以参考另一篇博文：http://manzhizhen.iteye.com/blog/2305890），我们接下来还是先从Sync说起，和信号量Semaphore（可以参考另一篇博文：http://manzhizhen.iteye.com/blog/2307298）一样，Sync是ReentrantLock中实现了AQS的内部类，我们这里先给出Sync的实现：
abstract static class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = -5179523762034025860L;
// 之所以这里没有实现关键的lock操作，是因为不同的策略（公平和非公平）有不同的lock方式
abstract void lock();
/** 看名字就知道是非公平策略下尝试获取锁所调用的操作 */
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
// c==0表明现在还没有线程来获取这把锁
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");
// 再次获取锁的许可，这里需要将许可数添加到state中
setState(nextc);
return true;
}
return false;
}
/** 无需多说，释放锁的通用操作*/
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
// 如果此时state值为0，说明此时该线程已经和该锁脱离关系了，所以锁的拥有者得设置成null
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
/** 判断当前线程是否是获取该锁的线程*/
protected final boolean isHeldExclusively() {
return getExclusiveOwnerThread() == Thread.currentThread();
}
final ConditionObject newCondition() {
return new ConditionObject();
}
/** 返回锁的拥有者线程*/
final Thread getOwner() {
return getState() == 0 ? null : getExclusiveOwnerThread();
}
/** 当前线程持有该锁的次数*/
final int getHoldCount() {
return isHeldExclusively() ? getState() : 0;
}
/** 当state为0，表明已经没有线程持有该锁*/
final boolean isLocked() {
return getState() != 0;
}
private void readObject(java.io.ObjectInputStream s)
throws java.io.IOException, ClassNotFoundException {
s.defaultReadObject();
setState(0); // reset to unlocked state
}
}
从ReentrantLock的Sync的实现来看，我们得到两个重要信息：1.只能有一个线程拥有该锁，所以ReentrantLock是使用AQS的独占模式。2.锁可以被拥有者线程重复持有，即可重入，并用AQS中state来记录拥有者线程当前持有该锁的次数，tryAcquire一次则state+1，tryRelease一次则state-1，所以当state为0时，表明该锁目前没有被任何线程持有。
我们已经知道，像信号量Semaphore一样，ReentrantLock对于资源的抢占机制也有两种：公平和非公平，在ReentrantLock中，也是在创建ReentrantLock对象时就决定的，运行期间不可修改，默认是非公平的，我们看下ReentrantLock的构造方法：
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
这段代码和信号量Semaphore的构造函数几乎一模一样，所以，很显然FairSync代表公平策略的实现，而NonfairSync代表非公平的实现，而且FairSync和NonfairSync都继承于上面提到的Sync。
从NonfairSync的实现，我们可以看出，在ReentrantLock的实现中，当AQS的state为0时，表示锁没有被线程使用，一旦有线程成功将state修改成1，则该线程则成为锁的拥有者，其他线程只要等state重新变成0时，才有机会去重新尝试占有该锁。锁的拥有者线程可以重复获取该锁，每获取一次，state都会加1，每释放一次，state都会减1，知道最终state重新变成0，即拥有者线程彻底放弃该锁。
我们先来看看默认的非公平NonfairSync的实现：
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}
可以看出，有了Sync，NonfairSync变得异常简单，它实现了Sync中没有实现的lock方法，lock方法会先看state值是否为0，为0表明该锁还没被线程拥有，所以立马将其设为1（是个CAS过程），如果成功，则把当前线程设置成独占锁的拥有者，如果失败或者state根本不为0，则说明当前线程可能没有抢锁成功或者当前线程不是第一次持有该锁了（可重入性），此时则会调用AQS的独占获取资源的方法acquire(acquire(1);)，在AQS的博文中我提到过，对于独占访问，实现类只需要提供tryAcquire方法的实现即可，至于独占获取资源中的获取资源尝试、排队等待等相关操作都是AQS提供的，这里还是给出AQS中acquire的代码：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
在这里，acquire先会调用我们自己tryAcquire方法的实现，如果获取资源数成功，则返回，否则则以独占的方式进入队列中等待，而我们NonfairSync实现的tryAcquire方法是直接调用Sync中的nonfairTryAcquire实现，上面已经给出了代码和注释，这里不再解释。还记得上面说过的Lock接口中定义的lock方法吗？Sync中定义的lock操作就是为其准备的，我们看看ReentrantLock中的lock实现就知道了：
public void lock() {
sync.lock();
}
虽然API上说Lock接口的lock语义是阻塞的，但我们知道，ReentrantLock的锁是独占的，如果是锁的拥有者，自然可以重复获取锁而不需要等待，如果不是锁的拥有者，则只能乖乖的进入AQS的队列中，只有当state为0时，队列中线程才有机会。tryAcquire方法是是使用AQS独占模式必须实现的方法，在NonfairSync中它是直接调用Sync的nonfairTryAcquire实现。
我们再来看看公平的FairSync的内部实现：
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
// 对于公平策略，当state为0时，不能直接去尝试作为锁的拥有者，因为有可能队列中还有线程在等
if (c == 0) {
// 如果队列中没有线程且将state由0设置成1成功，则说明已经成功拥有该锁
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
// 拥有该锁后，将拥有者线程设置成当前线程
setExclusiveOwnerThread(current);
return true;
}
}
// 当前线程本来就是锁的拥有者，则直接给state值+1
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
// 这里之所有没有用CAS操作给state设值，是因为当锁找到拥有者后，只有拥有者线程能修改state
setState(nextc);
return true;
}
return false;
}
}
和NonfairSync中的lock方法相比，FairSync的lock是直接调用AQS中的acquire操作，而没有经过compareAndSetState(0, 1)的CAS操作，因为对于公平策略来说，即使这时碰巧锁的拥有者放弃了锁的使用权，它也不能通过CAS操作尝试去获取该锁，因为有可能AQS的队列中还有线程同样也在等待这个机会，所以不能直接让它走NonfairSync的lock中的CAS这一步。因为AQS中的acquire方法会先调用tryAcquire，所以在tryAcquire不能光去看state是否为0，即使state为0当前线程也不能去尝试拥有该锁，所以tryAcquire还通过调用AQS中的hasQueuedPredecessors方法来看队列中是否有排队线程，如果没有，才去使用CAS来尝试获取该锁（compareAndSetState(0, acquires)），当此线程在此时队列中没有等待线程却还争夺锁失败或者当此线程不是锁的拥有者线程时，tryAcquire会返回false，于是AQS的acquireQueued操作直接让它去排队了（acquireQueued(addWaiter(Node.EXCLUSIVE), arg))），排队的这部分操作在AQS的博文中有简单描述，这里不再重复。
到目前为止，获取锁的公平和非公平策略都描述完了，释放锁的通用操作在Sync部分已经通过tryRelease实现，所以对于公平和非公平的策略，释放锁的步骤是一样的。关于锁，我们还剩一个话题，就是条件Condition！
我们直接看ReentrantLock内部的newCondition操作的实现：
public Condition newCondition() {
return sync.newCondition();
}
可见，它直接调用了Sync中的newCondition，这部分代码已经在前面给出，它直接新建了一个AQS中的条件对象ConditionObject返回了，所以ReentrantLock中的条件完全依赖了AQS中条件的实现，我在AQS中的博文已经阐述这里我们也不再多说。
ReentrantLock的核心操作就描述到这里。