概述
1、API在JDK的java.util.concurrent.locks下。
2、不是Java关键字，是接口。
3、ReentrantLock是JDK唯一实现了Lock接口的类。
public interface Lock {//获取锁void lock();//可以响应中断的锁void lockInterruptibly() throws InterruptedException;//尝试获取锁boolean tryLock();//尝试获取锁，如果拿不到会等待time的时间boolean tryLock(long time, TimeUnit unit) throws InterruptedException;//释放锁void unlock();
}四个获取锁方法
lock()
是平常使用得最多的一个方法，就是用来获取锁。如果锁已被其他线程获取，则进行等待。
由于在前面讲到如果采用Lock，必须主动去释放锁，并且在发生异常时，不会自动释放锁。因此一般来说，使用Lock必须在try{}catch{}块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被被释放，防止死锁的发生。
实例：http://blog.csdn.net/zengmingen/article/details/53257891
tryLock()
是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败（即锁已被其他线程获取），则返回false，也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。
实例：http://blog.csdn.net/zengmingen/article/details/53259279
tryLock(long time, TimeUnit unit)
和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false。如果如果一开始拿到锁或者在等待期间内拿到了锁，则返回true。
实例：http://blog.csdn.net/zengmingen/article/details/53259394
lockInterruptibly()
比较特殊，当通过这个方法去获取锁时，如果其他线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。也就使说，当两个线程同时通过
lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。
【注意：等待的那个线程B可以被中断，不是正在执行的A线程被中断。
注意，当一个线程获取了锁之后，是不会被interrupt()方法中断的。
因此当通过lockInterruptibly()方法获取某个锁时，如果不能获取到，只有进行等待的情况下，是可以响应中断的。
而用synchronized修饰的话，当一个线程处于等待某个锁的状态，是无法被中断的，只有一直等待下去。】
实例：http://blog.csdn.net/zengmingen/article/details/53260650
Lock和synchronized的选择
1）Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现。2）synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生。
而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁。
3）Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；
4）通过Lock可以知道有没有成功获取锁，而synchronized却无法办到。
5）Lock可以提高多个线程进行读操作的效率。
在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized。在具体使用时要根据适当情况选择。
