一、ReentrantLock重入锁
1、ReentrantLock重入锁简介
ReentrantLock可以完全替代synchronized关键字。在JDK5.0的早期版本中，ReentrantLock的性能远远好于synchronized，但是凶JDK6.0开始synchronized上做了大量优化，使得两者性能差距并不大。
重入锁使用java.until.concurrent.locks.ReentrantLock类来实现。ReenterLock.java展示了简单的.ReentrantLock使用案例。
public class ReenterLock implements Runnable
{
public static ReentrantLock lock = new ReentrantLock();
public static int i = 0;
@Override
public void run()
{
for (int j = 0; j < 10000000; ++j)
{
lock.lock(); //对临界区加锁
try
{
++i;
}
finally
{
lock.unlock(); //退出临界区时必须释放锁
}
}
}
public static void main(String[] args) throws InterruptedException
{
Thread t1 = new Thread(new ReenterLock());
Thread t2 = new Thread(new ReenterLock());
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(i);
}
}
从上面的代码可以看到，与synchronized相比，ReentrantLock有着显式的操作过程。开发人员必须手动指定何时加锁，何时释放锁。因此ReentrantLock对逻辑控制的灵活性远好于synchronized。但是必须注意，在退出临界区时，一定要释放锁。否则其他线程就没机会再访问临界区了。
ReentrantLock之所以叫重入锁，是因为这种锁是可以反复进入的。当然，这里的反复仅仅局限于一个线程。
如下面代码展示：
lock.lock(); //对临界区加锁
lock.lock();
try
{
++i;
}
finally
{
lock.unlock(); //退出临界区时必须释放锁
lock.unlock();
}
在这种情况下，一个线程连续两次获得通一把锁，这是允许的，如果不允许的话，那么第二个线程在第2次获得锁时，将会和自己产生死锁。但是值得注意的是，如果一个线程多次获得锁，那么在释放锁的时候，也必须释放相同的次数，如果释放锁的次数多，那么就会得到一个java.lang.IllegalMonitorStateException异常，反之，如果释放的锁次数少了，那么相当于线程还持有这个锁，其他线程也无法进入临界区。
2、中断响应
当使用synchronized来对临界区加锁，如果一个线程在等待锁，那么结果只有两种情况，要么它获得锁继续执行，要么它就保持等待。但是如果使用重入锁，就会提供另一种选择，那就是线程可以被中断。也就是说在等待锁的过程中，程序可以根据需要取消对锁的请求。
下面的代码IntLock.java会产生一个死锁，但是得益于锁中断，我们可以很轻易的解决这个死锁。
public class IntLock implements Runnable
{
public static ReentrantLock lock1 = new ReentrantLock();
public static ReentrantLock lock2 = new ReentrantLock();
int lock;
/**
* 控制加锁顺序，方便构造死锁
* @param lock
*/
public IntLock(int lock)
{
this.lock = lock;
}
@Override
public void run()
{
try
{
if (lock == 1)
{
lock1.lockInterruptibly();
try
{
Thread.sleep(500);
}
catch (InterruptedException e) {}
lock2.lockInterruptibly();
}
else
{
lock2.lockInterruptibly();
try
{
Thread.sleep(500);
}
catch (InterruptedException e) {}
lock1.lockInterruptibly();
}
}
catch (InterruptedException e)
{
e.printStackTrace();
}
finally
{
if (lock1.isHeldByCurrentThread())
{
lock1.unlock();
}
if (lock2.isHeldByCurrentThread())
{
lock2.unlock();
}
System.out.println(Thread.currentThread().getId() +":线程退出");
}
}
public static void main(String[] args) throws InterruptedException
{
IntLock r1 = new IntLock(1);
IntLock r2 = new IntLock(2);
Thread t1 = new Thread(r1);
Thread t2 = new Thread(r2);
t1.start();
t2.start();
Thread.sleep(1000);
//中断其中一个线程
t2.interrupt();
}
}
线程t1和t2启动后，t1先占用lock1，再占用lock2；t2先占用lock2，再占用lock1。因此很容易形成t1和t2之间的相互等待。在这里对锁的请求，统一使用lockInterruptibly()方法。这是一个可以对中断进行响应的锁申请动作，即在等待锁的过程中，可以响应中断。
当代码执行到Thread.sleep(1000)时，主线程处于休眠，此时，这两个线程处于死锁的状态，当执行到t2.interrupt()时，由于t2被中断，故t2会放弃对lock1的申请，同时释放已获得的lock2，这个操作导致t1线程可以顺利得到lock2而继续执行下去。
执行上述代码，可以看到以下输出：
可以看到，中断后，两个线程双双退出。但真正完成工作的只有t1，而t2线程则放弃其任务直接退出，释放资源。
3、锁申请等待限时
除了等待外部通知之外，要避免死锁还有另外一种方法，那就是限时等待。对于线程来说，通常我们无法判断为什么一个线程迟迟拿不到锁。也许是因为锁死了，也许因为产生了饥饿。但如果给定一个等待时间，让线程自动放弃，那么对系统来说是有意义的。我们可以使用tryLock()方法进行一次限时等待。
下面代码TimeLock.java展示了限时等待锁的使用
public class TimeLock implements Runnable
{
public static ReentrantLock lock = new ReentrantLock();
@Override
public void run()
{
try
{
if (lock.tryLock(5, TimeUnit.SECONDS))
{
Thread.sleep(6000);
}
else
{
System.out.println("get lock failed!");
}
}
catch (InterruptedException e)
{
e.printStackTrace();
}
finally
{
if (lock.isHeldByCurrentThread())
{
lock.unlock();
}
}
}
public static void main(String[] args)
{
TimeLock tl = new TimeLock();
Thread t1 = new Thread(tl);
Thread t2 = new Thread(tl);
t1.start();
t2.start();
}
}
在这里，tryLock()方法接收两个参数，一个表示等待时长，另外一个表示计时单位。这里的单位设置为秒，时长是5，表示线程在这个锁请求中，最多等待5秒。如果超过五秒还没有得到锁，就会返回false。如果成功获得锁，则返回true。
在本例中，由于占用锁的线程会持有锁长达6秒，故另一个线程无法再5秒的等待时间内获得锁，因此，请求会失败。
ReentrantLock.tryLock()方法也可以不带参数直接运行。在这种情况下，当前线程会尝试获得锁，如果锁并未被其他线程占用，则申请锁会成功，并立即返回true。如果锁被其他线程占用，则当前线程不会进行等待，而是立即返回false。这种方式不会引起线程等待，因此不会产生死锁。
4、公平锁
大多数情况下，锁的申请都是非公平的。举个例子，线程1首先请求了锁A，接着线程2也请求了锁A。那么当锁A可用时，是线程1可以获得锁还是线程2可以获得锁呢？这是不一定的。系统只是会从这个锁的等待队列中随机挑选一个，因此不能保证其公平性。而公平的锁，则不是这样，它会按照时间的先后顺序，保证先到者先得，后到者后得。公平锁的一大特点是：它不会产生饥饿现象。只要你排队，最终还是可以等到资源的。如果我们使用synchronized关键字进行锁控制，那么产生的锁就是非公平的。而重入锁允许我们对其公平性进行设置。它有一个如下的构造函数：
public ReentrantLock(boolean fair)
当参数fair为true时，表示锁时公平的。但是实现公平锁必须要牺牲一定的性能，因为需要维护一个有序的队列，因此默认情况下，锁是非公平的。如果没有特别的要求，也不需要使用公平锁。下面的代码可以很好的突出公平锁的特点：
public class FairLock implements Runnable
{
//当参数fair为true时，表示锁是公平的。默认为false，非公平
public static ReentrantLock fairLock = new ReentrantLock(true);
@Override
public void run()
{
while (true)
{
try
{
fairLock.lock();
System.out.println(Thread.currentThread().getName() + " 获得锁");
}
finally
{
fairLock.unlock();
}
}
}
public static void main(String[] args)
{
FairLock r1 = new FairLock();
Thread t1 = new Thread(r1, "Thread_t1");
Thread t2 = new Thread(r1, "Thread_t2");
t1.start();
t2.start();
}
}
执行代码，会看到如下输出结果：
因为代码会产生大量输出，这里只截取部分进行说明。在这个输出中，很明显可以看到，两个线程基本上是交替获得锁的，几乎不会发生一个线程连续多次获得锁的可能，从而公平性也得到了保证。但是如果使用不公平锁，那么情况就会不一样，部分输出如下：
可以看到，根据系统的调度，一个线程会倾向于再次获取已经持有的锁，这种分配方式是高效的，但是无公平性可言。
5、总结
（1）ReentrantLock 几个重要方法
- lock():获得锁，如果已经被占用，则等待。
- lockInterruptibly():获得锁，但优先响应中断。
- tryLock():尝试获得锁，如果成功，返回true，失败返回false。该方法不等待，立即返回。
- tryLock(long time, TimeUnit unit):在给定时间内尝试获得锁。
- unlock():释放锁。
（2）重入锁实现中包含的三要素
- 原子状态：原子状态使用CAS操作来存储当前锁的状态，判断锁是否已经被别的线程持有。
- 等待队列：所有没有请求到锁的线程，会进入等待队列进行等待，待有线程释放锁后，系统就能从等待队列中唤醒一个线程，继续工作。
- 阻塞原语park()和unpark()，用来挂起和恢复线程。没有得到锁的线程会被挂起。
