Java提供一系列的显示锁类，均位于java.util.concurrent.locks包中。
锁的分类： 排他锁，共享锁
- 排他锁又被称为独占锁，即读写互斥、写写互斥、读读互斥。
- Java的ReadWriteLock是一种共享锁，提供读读共享，但读写和写写仍然互斥。
Lock接口
Lock比传统线程模型中的synchronized方式更加面向对象，与生活中的锁类似，锁本身也应该是一个对象。两个线程执行的代码片段要实现同步互斥的效果，它们必须用同一个Lock对象。
public interface Lock { void lock(); void lockInterruptibly() throws InterruptedException; boolean tryLock(); boolean tryLock(long time, TimeUnit unit) throws InterruptedException; void unlock(); Condition newCondition(); }
Lock API详解
void lock();
获取锁。如果锁不可用，出于线程调度目的，将禁用当前线程，并且在获得锁之前，该线程将一直处于休眠状态。
void lockInterruptibly() throws InterruptedException;
如果当前线程未被中断，则获取锁。
如果锁可用，则获取锁，并立即返回。
如果锁不可用，出于线程调度目的，将禁用当前线程，并且在发生以下两种情况之一以前，该线程将一直处于休眠状态：
- 锁由当前线程获得；
- 其他某个线程中断当前线程，并且支持对锁获取的中断。
如果当前线程在下列情况会抛出 InterruptedException，并清除当前线程的已中断状态：
- 在进入此方法时已经设置了该线程的中断状态；
- 在获取锁时被中断，并且支持对锁获取的中断。
Condition newCondition();
返回绑定到此 Lock 实例的新 Condition 实例。
boolean tryLock();
仅在调用时锁为空闲状态才获取该锁。通常对于那些不是必须获取锁的操作可能有用。
- 若锁可用，则获取锁，并立即返回值 true。
- 若锁不可用，则此方法将立即返回值 false。
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
若锁在给定的等待时间内空闲，并且当前线程未被中断，则获取锁。
1.如果锁可用，则此方法将立即返回值 true。
2.如果锁不可用，出于线程调度目的，将禁用当前线程，并且在发生以下三种情况之一前，该线程将一直处于休眠状态：
- 锁由当前线程获得；
- 其他某个线程中断当前线程，并且支持对锁获取的中断；
- 已超过指定的等待时间
3.如果获得了锁，则返回值 true。
4.如果当前线程：
- 在进入此方法时已经设置了该线程的中断状态；或者
- 在获取锁时被中断，并且支持对锁获取的中断，则将抛出 InterruptedException，并会清除当前线程的已中断状态。
5.如果超过了指定的等待时间，则将返回值 false。如果 time 小于等于 0，该方法将完全不等待。
void unlock();
释放锁。对应于lock()、tryLock()、tryLock(xx)、lockInterruptibly()等操作，如果成功的话应该对应着一个unlock()，这样可以避免死锁或者资源浪费。
Lock的使用
Lock的lock()方法保证了只有一个线程能够执有此锁。对于任何一个lock()方法，都需要一个unlock()方法与之对应，通常情况下为了保证unlock()方法总是能够执行，unlock()方法被置于finally中。
Lock的标准适用方法如下，等价于synchronized代码块：
lock.lock();
try { //...需要保证线程安全的代码。 } finally { lock.unlock(); }
ReentrantLock
Reentrant英文意思为重入。ReentrantLock即重入锁。
ReentrantLock提供了与synchronized相同的互斥和内存可见性的保证。获得ReentrantLock的锁与进入synchronized块有着相同的内存语义，释放ReentrantLock锁与退出synchronized块有相同的内存语义。
那么为什么要创建与synchronized如此相似的东西呢？原因是synchronized在大部分情况下能够很好的工作，但是有些功能上存在着局限：
- 内部锁不能中断那些正在等待获取锁的进程，并且在请求锁失败的情况下，线程必须无限等待；
- 内部锁必须在获取它们的代码块中被释放；这很好的简化了代码，但是在某些情况下，一个更灵活的加锁机制提供了更好的活跃度和性能。
反之ReentrantLock拥有如下优点：
- ReentrantLock可以轮询和可定时的锁请求。lock.tryLock()
- ReentrantLock可中断的锁获取操作。lock.lockInterruptibly()
- jdk6之前，ReentrantLock性能优于synchronized。JDK6开始，两者性能差不多。
相对于synchronized来说，synchronized的锁的获取是释放必须在一个模块里，获取和释放的顺序必须相反，而Lock则可以在不同范围内获取释放，并且顺序无关。
ReentrantLock的特性
可重入
synchronized和ReentrantLock均有可重入性。
在使用synchronized时，一个线程请求得到一个对象锁后再次请求此对象锁，可以再次得到该对象锁。即当一个线程已经进入到synchronized方法/块中时，可以进入到本类的其他synchronized方法/块中。
对于ReentrantLock，单线程可以重复获取锁，同时一定要重复释放。
例：两次获取锁，则必须两次解锁。
ReentrantLock lock = new ReentrantLock(); lock.lock(); lock.lock(); try{ // ... }finally{ lock.unlock(); lock.unlock(); }
可中断
ReentrantLock.lockInterruptibly() 该方法与lock()方法类似，但该方法用于可中断的加锁。
在lockInterruptibly() 锁定的代码中，一旦接收到中断通知，就会抛出InterruptedException异常。
所以在被锁定的代码中ReentrantLock可以响应其他线程发起的中断通知。而被synchronized加锁的代码中，无法获取中断通知。
可限时
超时不能获得锁，就返回false，不会永久等待构成死锁。
ReentrantLock.tryLock()方法用于尝试锁定。参数为等待时间。该方法返回boolean值。若锁定成功，则返回true。锁定失败，则返回false。
公平锁
公平锁不会产生线程饥饿，锁被线程先来先得。ReentrantLock内部需要维护一个线程队列，性能稍高，如无必要，没必要使用。
public ReentrantLock(boolean fair) 是一个构造方法，fair默认为false，当设置为true时，及表示当前构造的锁是公平锁。
例：创建一个公平锁。
public static ReentrantLock fairLock = new ReentrantLock(true);
《Java并发编程实践》中说明：当需要可定时的、可轮询的与可中断的锁获取操作，公平队列，或者非块结构的锁，建议使用ReentrantLock。否则，请使用synchronized。
例：使用Lock定义一个类似于AtomicInteger的原子操作的整数类。
public class AtomicIntegerWithLock { private int value; private Lock lock = new ReentrantLock(); public AtomicIntegerWithLock() { super(); } public AtomicIntegerWithLock(int value) { this.value = value; } public final int get() { lock.lock(); try { return value; } finally { lock.unlock(); } } public final void set(int newValue) { lock.lock(); try { value = newValue; } finally { lock.unlock(); } } public final int getAndSet(int newValue) { lock.lock(); try { int ret = value; value = newValue; return ret; } finally { lock.unlock(); } } public final boolean compareAndSet(int expect, int update) { lock.lock(); try { if (value == expect) { value = update; return true; } return false; } finally { lock.unlock(); } } public final int getAndIncrement() { lock.lock(); try { return value++; } finally { lock.unlock(); } } public final int getAndDecrement() { lock.lock(); try { return value--; } finally { lock.unlock(); } } public final int incrementAndGet() { lock.lock(); try { return ++value; } finally { lock.unlock(); } } public final int decrementAndGet() { lock.lock(); try { return --value; } finally { lock.unlock(); } } public String toString() { return Integer.toString(get()); } }
ReadWriteLock 读写锁
读写锁：可以被多个读者访问或者被一个写者访问。读写锁提供读写分离功能。
public interface ReadWriteLock { Lock readLock(); Lock writeLock(); }
特性：
- 读–读不互斥：读读之间不阻塞。
- 读–写互斥：读阻塞写，写也会阻塞读。
- 写–写互斥：写写阻塞。
ReadWriteLock最大的特性就是读读共享（不互斥），例如A线程读锁正在进行读取操作，此时如果B线程请求读锁，那么B线程可以马上顺利获得读锁而无需等待，但此时如果C线程请求写锁，那么C线程需要等待锁可用。
ReadWriteLock由于提供了读读共享而增加了复杂性，所以在读写都相当频繁的场景并不能体现出性能优势，只有在读操作极多而写操作极少的场景下才能体现其性能优势。比如，一个应用系统安装完成后需要导入一批维护性的初始化数据，这些数据可以通过界面修改，但需要修改的情况极少，当系统一启动就会自动加载初始化数据到指定数据结构（如HashMap）供各个模块读取使用，那么可以为这些数据的读写加ReadWriteLock，以提高读取性能并保持数据的一致性。
ReentrantReadWriteLock 实现类
ReentrantReadWriteLock类是ReadWriteLock接口的一个实现，它与ReentrantLock类一样提供了公平竞争与不公平竞争两种机制，默认也是使用非公平竞争机制。ReentrantLock是排他锁，使用非公平竞争机制时，抢占的机会相对还是比较少的，只有当新请求恰逢锁释放时才有机会抢占，所以发生线程饥饿的现象几乎很少。然而ReentrantReadWriteLock是共享锁，或者说读读共享，并且经常使用于读多写少的场景，即请求读操作的线程多而频繁而请求写操作的线程极少且间隔长，在这种场景下，使用非公平竞争机制极有可能造成写线程饥饿。比如，R1线程此时持有读锁且在进行读取操作，W1线程请求写锁所以需要排队等候，在R1释放锁之前，如果R2,R3,…,Rn 不断的到来请求读锁，因为读读共享，所以他们不用等待马上可以获得锁，如此下去W1永远无法获得写锁，一直处于饥饿状态。所以使用ReentrantReadWriteLock类时，小心选择公平机制，以免遇到出乎预料的结果。
最后，Java5的读写锁实现有瑕疵，可能发生死锁，在Java6已经修复，所以避免使用Java5读写锁。
例：创建读锁与写锁。
private static ReentrantReadWriteLock readWriteLock=new ReentrantReadWriteLock(); private static Lock readLock = readWriteLock.readLock(); private static Lock writeLock = readWriteLock.writeLock();
例：读写锁的经典应用，实现一个简单的缓存
import java.util.HashMap; import java.util.Map; import java.util.concurrent.locks.ReadWriteLock; import java.util.concurrent.locks.ReentrantReadWriteLock; /** * 用读写锁实现的一个缓存系统，读的时候可以并发执行，当缓存中没有数据时，要到数据库中查询数据. * 此时只能写数据，不能读数据。当完数据之后，又可以并发地读取数据。这样做的话，可以提高系统的效率. */ public class MyCacheSystem { // 定义一个map用来存放要缓存起来的数据 private Map<String, Object> cache = new HashMap<String, Object>(); private ReadWriteLock rwl = new ReentrantReadWriteLock(); // 该方法中，读数据可以并发地读取，写数据与读数据，写数据与写数据之间不能并发地运行 public Object getData(String key) { // 刚进来的时候，上一把写锁 rwl.readLock().lock(); Object obj = null; try { obj = cache.get(key); if (obj == null) { // 如果数据为空，则需要到数据库中查询数据，所以这时候把读锁释放掉，上一把写锁，不能同时写数据 // 在上写锁之前，首先要把读锁释放掉 rwl.readLock().unlock(); rwl.writeLock().lock(); // 查询数据库的代码 try { // 必须重新检查obj是否为空，因为这时候，另外一个线程可能会获得写锁，从而让obj有值 if (obj == null) { obj = "查询数据库得到的数据"; } } finally { rwl.writeLock().unlock(); } // 因为前面释放了写锁，所以这里要把写锁重新锁上 rwl.readLock().lock(); } } finally { rwl.readLock().unlock(); } return obj; } }
关于读写锁的一些知识：
1．重入方面其内部的WriteLock可以获取ReadLock，但是反过来ReadLock想要获得WriteLock则永远都不要想。
2．WriteLock可以降级为ReadLock，顺序是：先获得WriteLock再获得ReadLock，然后释放WriteLock,这时候线程将保持Readlock的持有。反过来ReadLock想要升级为WriteLock则不可能。
3．ReadLock可以被多个线程持有并且在作用时排斥任何的WriteLock，而WriteLock则是完全的互斥.这一特性最为重要，因为对于高读取频率而相对较低写入的数据结构，使用此类锁同步机制则可以提高并发量。
4．不管是ReadLock还是WriteLock都支持Interrupt，语义与ReentrantLock一致。
5．WriteLock支持Condition并且与ReentrantLock语义一致，而ReadLock则不能使用Condition，否则抛出UnsupportedOperationException异常。
