java之ReentrantLock详解

前言

如果一个代码块被synchronized修饰了，当一个线程获取了相应的锁，并执行该代码块时，其他线程便只能一直等待，等待获取锁的释放，现在有这么一种情况，这个获取锁的线程由于要等待IO或者其他原因（比如调用sleep方法）被阻塞了，但是又没有释放锁，其他线程只能干巴巴地等着，在这种情况下，非常影响程序执行效率

所以Lock应运而生，可以不让等待的线程一直等待下去（比如只等待一定的时间或者能够响应中断）

一、Lock接口

（1）与synchronzed区别

synchronized是JVM层面的内置锁，而Lock则是java层面的显示锁，Lock提供了一种可重入的、可轮询的、定时的以及可中断的锁获取操作。

采用synchronized不需要用户去手动释放锁，当synchronized方法或者synchronized代码块执行完之后，系统会自动让线程释放对锁的占用；而Lock则必须要用户去手动释放锁，如果没有主动释放锁，就有可能导致出现死锁现象。

（2）lock接口源码详解

public interface Lock {
void lock();
void lockInterruptibly() throws InterruptedException;
Condition newCondition();
boolean tryLock();
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
void unlock();
}

lock()、tryLock()、tryLock(long time, TimeUnit unit)和lockInterruptibly()是用来获取锁的。unLock()方法是用来释放锁的。 newCondition()方法返回一个Condition对象

lock()：此方法是平常使用得最多的一个方法，就是用来获取锁。如果锁已被其他线程获取，则进行等待。

Lock lock = ...;
lock.lock();
try{
//处理任务
}catch(Exception ex){

}finally{
    lock.unlock();   //释放锁
}

tryLock()：此方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败（即锁已被其他线程获取），则返回false，也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。

Lock lock = ...;
if(lock.tryLock()) {
    try{
         //处理任务
     }catch(Exception ex){

     }finally{
         lock.unlock();   //释放锁
    }
}else {
//如果不能获取锁，则直接做其他事情
}

tryLock(long time, TimeUnit unit)：此方法和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false。如果如果一开始拿到锁或者在等待期间内拿到了锁，则返回true。

lockInterruptibly()方法比较特殊，当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。也就使说，当两个线程同时通过lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。

二、ReentrantLock

（1）模拟可中断的锁获取

Lock中的lockInterruptibly() 可以在获得锁的同时保持对中断的响应，但是内置锁synchronized却很难实现这个功能。

synchronized

如下程序，创建一任务，假设该任务需要执行很长时间才能结束（使用死循环来模拟时长）。现在有两个线程竞争该资源的内置锁，在等待一段时间后，想要终止线程t2的锁获取等待操作，使用t2.interrupt(); 尝试中断线程t2。遗憾的是，此时t2根本不会响应这个中断操作，它会继续等待直到获得资源锁。

public class InterruptedLockTest implements Runnable{
public synchronized void doCount(){
    //使用死循环表示此操作要进行很长的一段时间才能结束
    while(true){}
}

@Override
public void run() {
    doCount();
}
}

public static void main(String[] args) throws InterruptedException {
    InterruptedLockTest test = new InterruptedLockTest();

    Thread t1 = new Thread(test);
    Thread t2 = new Thread(test);

    t1.start();
    t2.start();

      //等待两秒，尝试中断线程t2的等待
    TimeUnit.SECONDS.sleep(2);
    t2.interrupt();

    //等待1秒，让 t2.interrupt(); 执行生效
    TimeUnit.SECONDS.sleep(1);
    System.out.println("线程t1是否存活：" + t1.isAlive());
    System.out.println("线程t2是否存活：" + t2.isAlive());
}

console打印：
线程t1是否存活：true
线程t2是否存活：true

Lock

public class LockDemo implements Runnable {
@Override
public void run() {
    try {
        doCount();
    } catch (InterruptedException e) {
        System.out.println("被中断....");
    }
}
Lock lock = new ReentrantLock();

public void doCount() throws InterruptedException {
    lock.lockInterruptibly();
    try {
        while (true){

        }
    }catch (Exception e){

    }finally {
        lock.unlock();
    }
}

public static void main(String[] args) throws InterruptedException {
    LockDemo lockDemo = new LockDemo();

    Thread t1 = new Thread(lockDemo);
    Thread t2 = new Thread(lockDemo);

    t1.start();
    t2.start();

    TimeUnit.SECONDS.sleep(2);
    t2.interrupt();

    //等待1秒，让 t2.interrupt(); 执行生效
    TimeUnit.SECONDS.sleep(1);
    System.out.println("线程t1是否存活：" + t1.isAlive());
    System.out.println("线程t2是否存活：" + t2.isAlive());
}
}

console打印：
被中断....
线程t1是否存活：true
线程t2是否存活：false

（2）模拟可轮询（避免死锁）

相比于synchronized内置锁的无条件锁获取模式，Lock提供了tryLock() 实现可定时和可轮询的锁获取模式，这也使Lock具有更完善的错误恢复机制。在内置锁中，死锁是一个很严重的问题，造成死锁的原因之一可能是，锁获取顺序不一致导致程序死锁。比如说，线程1持有A对象锁，正在等待获取B对象锁；线程2持有B对象锁，正在等待获取A对象锁。这样，两个线程都会由于获取不到想要的锁而陷入死锁的境地。解决办法可以是，两个线程要么同时获取两个锁，要么一个锁都不获取。Lock 的可定时和可轮询锁就可以很好的满足该条件，从而避免死锁的发生

synchronized死锁问题

public class TestDeadLock implements Runnable{
int flag ;
static Object o1 = new Object();
static Object o2 = new Object();

@Override
public void run() {
	if(flag==0){
		synchronized (o1) {
			try {
				Thread.sleep(500);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
			synchronized (o2) {
				System.out.println("flag==0");
			}
		}
	}
	else if (flag==1){
		synchronized (o2) {
			try {
				Thread.sleep(500);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
			synchronized (o1) {
				System.out.println("flag==1");
			}
		}
	}
}

public static void main(String[] args) {
	TestDeadLock td1 = new TestDeadLock();
	TestDeadLock td2 = new TestDeadLock();
	td1.flag = 0;
	td2.flag = 1;
	Thread t1 = new Thread(td1);
	Thread t2 = new Thread(td2);
	t1.start();
	t2.start();
}

}

ReentrantLock可轮询

// 资源类
public class Resource {
    //资源总和
    private int resourceNum;
    // 显示锁
    public Lock lock = new ReentrantLock();

    public Resource(int resourceNum){
        this.resourceNum = resourceNum;
    }
    //返回此资源的总量
    public int getResourceNum(){
        return resourceNum;
    }
}

public class LockTest1 {
  //传入两个资源类和预期操作时间，在此期间内返回两个资源的数量总和
public int getResource(Resource resourceA, Resource resourceB, long timeout, TimeUnit unit)
      throws InterruptedException {
    // 获取当前时间，算出操作截止时间
    long stopTime = System.nanoTime() + unit.toNanos(timeout);

    while(true){
        try {
            // 尝试获得资源A的锁
            if (resourceA.lock.tryLock()) {
                try{
                    // 如果获得资源A的锁，尝试获得资源B的锁
                    if(resourceB.lock.tryLock()){
                        //同时获得两资源的锁，进行相关操作后返回
                        return getSum(resourceA, resourceB);
                    }
                }finally {
                    resourceB.lock.unlock();
                }
            }
        }finally {
            resourceA.lock.unlock();
        }

        // 判断当前是否超时，规定-1为错误标识
        if(System.nanoTime() > stopTime)
            return -1;

        //睡眠1秒，继续尝试获得锁
        TimeUnit.SECONDS.sleep(1);
    }
}

// 获得资源总和
public int getSum(Resource resourceA,Resource resourceB){
    return resourceA.getResourceNum()+resourceB.getResourceNum();
}
}

（3）公平锁

背景

CPU在调度线程的时候是在等待队列里随机挑选一个线程，由于这种随机性所以是无法保证线程先到先得的（synchronized控制的锁就是这种非公平锁）。但这样就会产生饥饿现象，即有些线程（优先级较低的线程）可能永远也无法获取cpu的执行权，优先级高的线程会不断的强制它的资源。那么如何解决饥饿问题呢，这就需要公平锁了。

公平锁可以保证线程按照时间的先后顺序执行，避免饥饿现象的产生。但公平锁的效率比较地，因为要实现顺序执行，需要维护一个有序队列。

// 也可以指定公平性
public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}
//默认创建非公平锁
public ReentrantLock() {
    sync = new NonfairSync();
}

Demo

package com.jalja.base.threadTest;

import java.util.concurrent.locks.ReentrantLock;

public class LockFairTest implements Runnable{
//创建公平锁
private static ReentrantLock lock=new ReentrantLock(true);
public void run() {
    while(true){
        lock.lock();
        try{
            System.out.println(Thread.currentThread().getName()+"获得锁");
        }finally{
            lock.unlock();
        }
    }
}
public static void main(String[] args) {
    LockFairTest lft=new LockFairTest();
    Thread th1=new Thread(lft);
    Thread th2=new Thread(lft);
    th1.start();
    th2.start();
}
}

console打印：
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁

分析结果可看出两个线程是交替执行的，几乎不会出现同一个线程连续执行多次。

三、Synchronized与Lock的区别

锁类型

• 可重入锁：在执行对象中所有同步方法不用再次获得锁

• 可中断锁：在等待获取锁过程中可中断

• 公平锁： 按等待获取锁的线程的等待时间进行获取，等待时间长的具有优先获取锁权利

• 读写锁：对资源读取和写入的时候拆分为2部分处理，读的时候可以多线程一起读，写的时候必须同步地写

区别

类别	synchronized	Lock
存在层次	Java的关键字，在jvm层面上	是一个类
锁的释放	1、以获取锁的线程执行完同步代码，释放锁 2、线程执行发生异常，jvm会让线程释放锁	在finally中必须释放锁，不然容易造成线程死锁
锁的获取	假设A线程获得锁，B线程等待。如果A线程阻塞，B线程会一直等待	分情况而定，Lock有多个锁获取的方式，具体下面会说道，大致就是可以尝试获得锁，线程可以不用一直等待
锁状态	无法判断	可以判断
锁类型	可重入 不可中断 非公平	可重入 可中断 可公平（两者皆可）
性能	少量同步	大量同步

关于读写锁

我们知道，当多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作也会发生冲突现象，但是读操作和读操作不会发生冲突现象。但是如果采用synchronized关键字实现同步的话，就会导致一个问题，即当多个线程都只是进行读操作时，也只有一个线程在可以进行读操作，其他线程只能等待锁的释放而无法进行读操作。因此，需要一种机制来使得当多个线程都只是进行读操作时，线程之间不会发生冲突。同样地，Lock也可以解决这种情况 (解决方案：ReentrantReadWriteLock) 。