java多线程：ReentrantLock

在java中，除了用synchronized控制线程之外，还可以用ReentLock来控制。

synchronized简单方便，但是适用场景比较单一，局限比较多。ReentrantLock则灵活得多，具有时间锁等待、可中断锁等功能。

synchronized是JVM实现的，而Lock是代码层面实现的。
synchronized封装了线程信息，便于调试，而Lock则并不知道自己当前所在线程是哪一个。

需要注意的是，synchronized自己实现了锁的释放，所以我们执行完操作时，并不需要特意去释放锁，而Lock并没有，所以我们需要在拿到锁之后，需要在finally中执行锁的释放，如果忘记了，很容易出现问题。

另外，从性能方面来说，高并发的情况，Lock的性能好过synchronized。

简单介绍下ReentrantLock的使用

lock

尝试获取锁，如果拿不到，则一直等待，效果等同于synchronized

Lock lock = new ReentrantLock();
//创建一个重入锁
lock.lock();
//申请锁，此步骤往下都是锁住范围
try{
  //拿到锁了，执行操作
}finally{
  lock.unlock();
  //释放锁，在执行完操作之后，手动释放锁
}

tryLock

尝试获取锁，如果拿不到，则不等待锁的释放，直接执行另一操作

Lock lock = new ReentrantLock();
if (lock.tryLock()) {   
    try {   
        // 拿到锁了，执行操作   
    } finally {   
        lock.unlock();   
    }   
} else {   
// 没拿到锁，执行操作 
} 

tryLock还有一个重载方法，可以传入等待时间

Lock lock = new ReentrantLock();
if (lock(5, TimeUnit.SECONDS)) {  
  //试图在五秒内获取锁，若获取不到，返回false
    try {   
        // 拿到锁了，执行操作   
    } finally {   
        lock.unlock();   
    }   
} else {   
// 没拿到锁，执行操作 
} 

lockInterruptibly

在synchronized中，如果申请的对象锁被其他线程获取了，那么此线程会一直等待直到对象锁被释放，并且无法终止等待。那么在Lock中，lockInterruptibly方法表示，申请锁，并且可以中断申请。

public class SleepThread extends Thread{
    
    private ReentrantLock lock;
    
    public SleepThread(ReentrantLock lock){
        this.lock=lock;
    }
    
    @Override
    public void run() {
        super.run();
        lock.lock();
        try {
            sleep(100000);
          //拿到锁之后睡觉
        } catch (InterruptedException e) {
            e.printStackTrace();
        }finally{
            lock.unlock();
        }
    }
}

public class InterruptiblyThread extends Thread{
    
    private ReentrantLock lock;
    
    public InterruptiblyThread(ReentrantLock lock){
        this.lock=lock;
    }
    
    @Override
    public void run() {
        super.run();
        try {
            lock.lockInterruptibly();
             //申请锁，此过程可以被中断
            try{
                
            }finally{
                lock.unlock();
            }
        } catch (InterruptedException e) {
            //阻塞被唤醒并被要求处理中断
            //抓住或者抛出中断
            System.out.println("我被中断啦");
        }
        
    }
}

public static void main(String[] args) {
        ReentrantLock lock=new ReentrantLock();
        Thread sleep=new SleepThread(lock);
        Thread inter=new InterruptiblyThread(lock);
        
        sleep.start();
        inter.start();
        inter.interrupt();
    }

我被中断啦

等待与唤醒

在synchronized中，线程通信用Object的wait、notify、notifyAll方法来实现。并且对象锁的唤醒与等待，是一一对应的。这种情况下，如果我只想唤醒其中某部分线程，那就必须用到多个对象锁了。

Lock的本身实现了线程的通信方法，通过Condition的await、signal、signalAll来分别对应Object的方法。并且一个Lock可以和多个Condition关联。

举个栗子：

ReentrantLock lock = new ReentrantLock(true);
Condition empty = lock.newCondition();
Condition full = lock.newCondition();

public void lockConsume() {
  // 如果队列空了，则消费者等待
  if (TaskQueue.getInstance().isEmpty()) {
    lock.lock();
    try {
      if (TaskQueue.getInstance().isEmpty()) {
        // 生产者唤醒，这里只能唤醒由full.await进入等待的线程
        full.signal();
        try {
          //消费者等待
          empty.await();
        } catch (InterruptedException e) {
          // TODO Auto-generated catch block
          e.printStackTrace();
        }
      }
    } finally {
      lock.unlock();
    }
  } else {
    //消费
    TaskQueue.getInstance().getTask();
  }
}

private void lockProduce() {
  // 如果队列满了，生产者暂停
  if (TaskQueue.getInstance().isFull()) {
    lock.lock();
    try {
      if (TaskQueue.getInstance().isFull()) {
        // 消费者唤醒，这里同样只能唤醒由empty.await进入等待的线程
        empty.signal();
        try {
          //生产者暂停
          full.await();
        } catch (InterruptedException e) {
          e.printStackTrace();
        }
      }
    } finally {
      lock.unlock();
    }
  } else {
   //生产
    Bean b = new Bean();
    TaskQueue.getInstance().addTask(b);
  }
}

我用两个Condition控制了多个线程，而Lock却只有一个。Condition的方法和Object并没有什么功能上的不同，只不过更加灵活。

公平性（FIFO）

大家可能注意到上面等待与唤醒中举的栗子，初始化Lock的时候和之前的栗子不同，传入了一个布尔参数，这个参数就是用来控制Lock的公平性，即是否先入先出（默认为false）。

如果Lock是公平的，那么线程执行的顺序会严格按照请求锁的顺序依次获得锁，而如果不是，则线程可能比其他先请求锁的线程先得到锁。

Condition和Lock是绑定的，所以Condition也有Lock的公平性，Condition按照await的顺序一一唤醒。这里Condition按照自己的await队列唤醒之后，添加到Lock申请锁的队列中，依然按照FIFO获得锁。

从性能上来说，公平性比非公平性的性能低，因为JVM无法根据条件调度线程，只能严格执行队列顺序。