18、彻底理解ReentrantLock可重入锁的使用

柔光的暖阳◎ 2023-06-11 03:11 16阅读 0赞

java除了使用关键字synchronized外,还可以使用ReentrantLock实现独占锁的功能。而且ReentrantLock相比synchronized而言功能更加丰富，使用起来更为灵活，也更适合复杂的并发场景。这篇文章主要是从使用的角度来分析一下ReentrantLock。

**一、简介**

ReentrantLock常常对比着synchronized来分析，我们先对比着来看然后再一点一点分析。

（1）synchronized是独占锁，加锁和解锁的过程自动进行，易于操作，但不够灵活。ReentrantLock也是独占锁，加锁和解锁的过程需要手动进行，不易操作，但非常灵活。

（2）synchronized可重入，因为加锁和解锁自动进行，不必担心最后是否释放锁；ReentrantLock也可重入，但加锁和解锁需要手动进行，且次数需一样，否则其他线程无法获得锁。

（3）synchronized不可响应中断，一个线程获取不到锁就一直等着；ReentrantLock可以相应中断。

ReentrantLock好像比synchronized关键字没好太多，我们再去看看synchronized所没有的，一个最主要的就是ReentrantLock还可以实现公平锁机制。什么叫公平锁呢？也就是在锁上等待时间最长的线程将获得锁的使用权。通俗的理解就是谁排队时间最长谁先执行获取锁。

字数写的多可能大家都会烦，干脆直接上代码演示。

**二、使用**

**1、简单使用**

我们先给出一个最基础的使用案例，也就是实现锁的功能。

public class ReentrantLockTest { 
    	private static final Lock lock = new ReentrantLock();
    	public static void main(String[] args) { 
    		new Thread(() -> test(),"线程A").start();
    		new Thread(() -> test(),"线程B").start();	
    	}
    	public static void  test()  { 
    		try { 
    			lock.lock();
    			System.out.println(Thread.currentThread().getName()+"获取了锁");
    			TimeUnit.SECONDS.sleep(2);
    		} catch (InterruptedException e) { 
    			e.printStackTrace();
    		}finally { 
    			System.out.println(Thread.currentThread().getName()+"释放了锁");
    			lock.unlock();
    		}	
    	}
    }

在这里我们定义了一个ReentrantLock，然后再test方法中分别lock和unlock，运行一边就可以实现我们的功能。这就是最简单的功能实现，代码很简单。我们再看看ReentrantLock和synchronized不一样的地方，那就是公平锁的实现。

**2、公平锁实现**

对于公平锁的实现，就要结合着我们的可重入性质了。公平锁的含义我们上面已经说了，就是谁等的时间最长，谁就先获取锁。

public class ReentrantLockTest2 { 
    	private static final Lock lock = new ReentrantLock(true);
    	public static void main(String[] args) { 
    		new Thread(() -> test(),"线程A").start();
    		new Thread(() -> test(),"线程B").start();	
    		new Thread(() -> test(),"线程C").start();	
    		new Thread(() -> test(),"线程D").start();	
    		new Thread(() -> test(),"线程E").start();	
    	}
    	public static void  test()  { 
    		for(int i=0;i<2;i++) { 
    			try { 
    				lock.lock();
    				System.out.println(Thread.currentThread().getName()+"获取了锁");
    				TimeUnit.SECONDS.sleep(2);
    			} catch (InterruptedException e) { 
    				e.printStackTrace();
    			}finally { 
    				lock.unlock();
    			}	
    		}
    	}
    }

首先new一个ReentrantLock的时候参数为true，表明实现公平锁机制。在这里我们多定义几个线程ABCDE，然后再test方法中循环执行了两次加锁和解锁的过程。

![在这里插入图片描述][20191028161651258.png]

**3、非公平锁实现**

非公平锁那就随机的获取，谁运气好，cpu时间片轮到哪个线程，哪个线程就能获取锁，和上面公平锁的区别很简单，就在于先new一个ReentrantLock的时候参数为false，当然我们也可以不写，默认就是false。直接测试一下

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70]

**4、响应中断**

响应中断就是一个线程获取不到锁，不会傻傻的一直等下去，ReentrantLock会给与一个中断回应。在这里我们举一个死锁的案例。

首先我们定义一个测试类ReentrantLockTest3。

public class ReentrantLockTest3 { 
        static Lock lock1 = new ReentrantLock();
        static Lock lock2 = new ReentrantLock();
        public static void main(String[] args) 
            					throws InterruptedException { 
            Thread thread = new Thread(new ThreadDemo(lock1, lock2));
            Thread thread1 = new Thread(new ThreadDemo(lock2, lock1));
            thread.start();
            thread1.start();
            thread.interrupt();//是第一个线程中断
        }
    }

在这里我们定义了两个锁lock1和lock2。然后使用两个线程thread和thread1构造死锁场景。正常情况下，这两个线程相互等待获取资源而处于死循环状态。但是我们此时thread中断，另外一个线程就可以获取资源，正常的执行了。

static class ThreadDemo implements Runnable { 
            Lock firstLock;
            Lock secondLock;
            public ThreadDemo(Lock firstLock, Lock secondLock) { 
                this.firstLock = firstLock;
                this.secondLock = secondLock;
            }
            @Override
            public void run() { 
                try { 
                    firstLock.lockInterruptibly();
                    TimeUnit.MILLISECONDS.sleep(50);
                    secondLock.lockInterruptibly();
                } catch (InterruptedException e) { 
                    e.printStackTrace();
                } finally { 
                    firstLock.unlock();
                    secondLock.unlock();
                    System.out.println(Thread.currentThread().getName()
                                       +"获取到了资源，正常结束!");
                }
            }
        }

我们运行测试一下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 1]

**5、限时等待**

这个是什么意思呢？也就是通过我们的tryLock方法来实现，可以选择传入时间参数,表示等待指定的时间,无参则表示立即返回锁申请的结果:true表示获取锁成功,false表示获取锁失败。我们可以将这种方法用来解决死锁问题。

首先还是测试代码，不过在这里我们不需要再去中断其中的线程了，我们直接看线程类是如何实现的。

static class ThreadDemo implements Runnable { 
            Lock firstLock;
            Lock secondLock;
            public ThreadDemo(Lock firstLock, Lock secondLock) { 
                this.firstLock = firstLock;
                this.secondLock = secondLock;
            }
            @Override
            public void run() { 
                try { 
                	if(!lock1.tryLock()) { TimeUnit.MILLISECONDS.sleep(10);}
                	if(!lock2.tryLock()) { TimeUnit.MILLISECONDS.sleep(10);}      
                } catch (InterruptedException e) { 
                    e.printStackTrace();
                } finally { 
                    firstLock.unlock();
                    secondLock.unlock();
                    System.out.println(Thread.currentThread().getName()+"正常结束!");
                }
            }
        }

在这个案例中，一个线程获取lock1时候第一次失败，那就等10毫秒之后第二次获取，就这样一直不停的调试，一直等到获取到相应的资源为止。

当然，我们可以设置tryLock的超时等待时间**tryLock**(long timeout,TimeUnit unit)，也就是说一个线程在指定的时间内没有获取锁，那就会返回false，就可以再去做其他事了。

一个线程获取lock1时候第一次失败，那就等10毫秒之后第二次获取，就这样一直不停的调试，一直等到获取到相应的资源为止。

OK，到这里我们就把ReentrantLock常见的方法说明了，所以其原理，还是主要通过源码来解释。而且分析起来还需要集合AQS和CAS机制来分析。我也会在下一篇文章来分析。感谢大家的持续关注和支持。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 2]

[20191028161651258.png]: /images/20230531/725498a437a4467eb81590d55f20f5c6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70]: /images/20230531/16dde9f99a3d40418789032e9528ea16.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 1]: /images/20230531/16f8c5ed1e3240a48e07bea34edcbded.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 2]: /images/20230531/12bef53cdcc94c4f8ad6361f41b06a61.png