第三章-JDK并发包-ReentrantLock几个重要的方法整理

package com.bjut.TheWorldOfConcurrent.Chapter3;

import java.util.concurrent.locks.ReentrantLock;
/**
*  ReentrantLock:
*   lock()： 获得锁，如果所已经被占用，则等待
*   lockInterruptibly()：获得锁，但优先相应中断
*   tryLock()：尝试获得锁，如果成功，返回true，失败返回false。该方法不等待，立即返回
*   tryLock(long time, TimeUnit unit): 在给定时间内尝试获得锁
*   unLock()：释放锁
* */
public class FairLock implements Runnable {
    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();
    }
}

 

ReentrantLock起源

在1.5的时候，synchronized关键的性能不是很好，这也是concurrent并发包出现的一种潜在原因，而新出现的ReentrantLock重入锁的性能那时比synchronized好太多，也提供了更加灵活、细粒度的同步操作。（在jdk1.6开始，jdk在synchronized上做了大量的优化，使得两者差距并不大，并且并发包出错性高，通常使用synchronized即可）

 

lock/unlock

重入锁是synchronized功能的一种扩展，它和synchronized一样能同步执行方法或者代码块，除此之外，它还能指定释放锁对象。通过lock方法来加锁，通过unlock来解锁，这两个方法签名如下：

lock
public void lock()
// 获取锁。
// 如果该锁没有被另一个线程保持，则获取该锁并立即返回，将锁的保持计数设置为 1。
// 如果当前线程已经保持该锁，则将保持计数加 1，并且该方法立即返回。
// 如果该锁被另一个线程保持，则出于线程调度的目的，禁用当前线程，并且在获得锁之前，该线程将一
// 直处于休眠状态，此时锁保持计数被设置为 1。



public void unlock();
// 释放重入锁，并将保持计数减1

lockInterruptibly响应中断，获得锁，但优先响应中断

对于synchronized关键字来说，如果一个线程在等待锁，那么它就只有两种情况：获得锁继续执行/保持等待。而对于重入锁来说，它还有另外一种可能，就是被中断：也就是说在等待锁的过程中，程序可以根据需要取消对锁的请求。这里主要使用了ReentrantLock对象的lockInterruptibly方法。

lockInterruptibly
public void lockInterruptibly() throws InterruptedException
1）如果当前线程未被中断，则获取锁。 

2）如果该锁没有被另一个线程保持，则获取该锁并立即返回，将锁的保持计数设置为 1。 

3）如果当前线程已经保持此锁，则将保持计数加 1，并且该方法立即返回。 

4）如果锁被另一个线程保持，则出于线程调度目的，禁用当前线程，并且在发生以下两种情况之一以
前，该线程将一直处于休眠状态： 
     1）锁由当前线程获得；或者 

     2）其他某个线程中断当前线程。 

5）如果当前线程获得该锁，则将锁保持计数设置为 1。 
   如果当前线程： 
       1）在进入此方法时已经设置了该线程的中断状态；或者 

       2）在等待获取锁的同时被中断。 

   则抛出 InterruptedException，并且清除当前线程的已中断状态。 


6）在此实现中，因为此方法是一个显式中断点，所以要优先考虑响应中断，而不是响应锁的普通获取或
重入获取。

 lockInterruptibly()和上面的第一种情况是一样的， 线程在请求lock并被阻塞时，如果被interrupt，则“此线程会被唤醒并被要求处理InterruptedException”。并且如果线程已经被interrupt，再使用lockInterruptibly的时候，此线程也会被要求处理interruptedException

 

立即返回的加锁方式:tryLock

重入锁还有一个加锁的方法：tryLock()，该方法签名及介绍如下：

tryLock    public boolean tryLock()

//还有一个带参数运行的tryLock，接受两个参数：等待时长和计时单位，超过
指定时间后还没有获得锁就会返回false，没有参数的tryLock会立即返回

仅在调用时锁未被另一个线程保持的情况下，才获取该锁。 

1）如果该锁没有被另一个线程保持，并且立即返回 true 值，则将锁的保持计数设置为 1。
即使已将此锁设置为使用公平排序策略，但是调用 tryLock() 仍将 立即获取锁（如果有可用的），
而不管其他线程当前是否正在等待该锁。在某些情况下，此“闯入”行为可能很有用，即使它会打破公
平性也如此。如果希望遵守此锁的公平设置，则使用 tryLock(0, TimeUnit.SECONDS) 
，它几乎是等效的（也检测中断）。 

2）如果当前线程已经保持此锁，则将保持计数加 1，该方法将返回 true。 

3）如果锁被另一个线程保持，则此方法将立即返回 false 值。