接口Lock的实现类：
ReentrantLock, ReentrantReadWriteLock.ReadLock, ReentrantReadWriteLock.WriteLock
ReentrantLock
java5.0之前只有synchronize和volatile，ReentrantLock是5.0增加的。
ps：synchronize使用的监视器锁不是通过ReentrantLock实现的，是一种独特的机制。在5.0中它的性能要比ReentrantLock低很多，在6.0中它的性能也比ReentrantLock也要低一点。
ReentrantLock的独有功能：
- 可实现轮询
- 可配置为定时返回
- 可配置为响应中断
- 可配置为公平锁
注意：lock的unlock必须在finally中。
轮询和定时都是通过tryLock(time)方法来实现的。
while(true)
{
boolean success = lock.tryLock(time);
if success
{
//获得了锁
//执行代码
break;
}
}
关于公平锁：
此类的构造方法接受一个可选的公平 参数。当设置为 true 时，在多个线程的争用下，这些锁定倾向于将访问权授予等待时间最长的线程。否则此锁定将无法保证任何特定访问顺序。与采用默认设置（使用不公平锁定）相比，使用公平锁定的程序在许多线程访问时表现为很低的总体吞吐量（即速度很慢，常常极其慢），但是在获得锁定和保证锁定分配的均衡性时差异较小。不过要注意的是，公平锁定不能保证线程调度的公平性。还要注意的是，未定时的 tryLock 方法并没有使用公平设置。因为即使其他线程正在等待，只要该锁定是可用的，此方法就可以获得成功。
synchronize和ReentrantLock的选择
ReentrantLock在性能上似乎优于内置锁，但是内置锁仍然具有很大的优势。内置锁为许多开发人员所熟悉，并且简介紧凑，而且许多现有的程序都已经使用了内置锁，如果将这两种机制混合使用，那么不仅容易令人困惑，也容易发生错误。
而且synchronize更加的简单，JVM会对它有特殊的优化。
所以作者建议优先选择synchronize。
读写锁
写锁独占读写操作。读锁之间可以共享。
读写锁本身的实现会有负担，所以一般在读操作比较多的情况下使用。如果不是这种情况，最好测试后再做决定。
ReentrantReadWriteLock：
此类具有以下属性：
- 获取顺序
当设置为公平锁时，线程利用一个近似到达顺序的策略来争夺进入。当释放写入锁定后，将写入锁定分配给等待时间最长的单个写入者，如果有一个等待时间比所有写入者更长的读取者，则将读取锁定分配给读取者 set。当非公平地构造线程时，则不需要按照到达顺序进入锁定。不管是哪一种情况，如果读取者处于活动状态，而某个写入者进入锁定状态，那么在获取写入者并释放写入锁定之前，不会将读取锁定授予任何后续的读取者。我的理解：也就是说，写入锁具有优先获取锁的特权，虽然在公平锁的情况下，这个特权会削弱，但是依然有。
- 重入
此锁定允许读取者和写入者按照 ReentrantLock 的样式重新获取读取锁定或写入锁定。在写入线程保持的所有写入锁定都已经释放后，才允许写入者使用它们。
- 锁定降级
重入还允许从写入锁定降级为读取锁定，其实现方式是：先获取写入锁定，然后获取读取锁定，最后释放写入锁定。但是，从读取锁定升级到写入锁定是不可能的。
- 锁定获取的中断
读取锁定和写入锁定都支持锁定获取期间的中断。
- Condition 支持
写入锁定提供了一个 Condition 实现，对于写入锁定来说，该实现的行为与 ReentrantLock.newCondition() 提供的 Condition 实现对 ReentrantLock 所做的行为相同。当然，此 Condition 只能用于写入锁定。
读取锁定不支持 Condition，readLock().newCondition() 会抛出 UnsupportedOperationException。
- 序列化
此类行为的序列化方式与内置锁定的相同：反序列化的锁定处于解除锁定状态，无论序列化该锁定时其状态如何。