ReentrantLock可重入锁的使用场景（转）

摘要

从使用场景的角度出发来介绍对ReentrantLock的使用，相对来说容易理解一些。

场景1：如果发现该操作已经在执行中则不再执行（有状态执行）

a、用在定时任务时，如果任务执行时间可能超过下次计划执行时间，确保该有状态任务只有一个正在执行，忽略重复触发。
b、用在界面交互时点击执行较长时间请求操作时，防止多次点击导致后台重复执行（忽略重复触发）。

以上两种情况多用于进行非重要任务防止重复执行，（如：清除无用临时文件，检查某些资源的可用性，数据备份操作等）

?


1

private ReentrantLock lock = new ReentrantLock();

?


1

2

3

4

5

6

7

8

9

10

11

                if (lock.tryLock()) {  //如果已经被lock，则立即返回false不会等待，达到忽略操作的效果 

 

                    try {

 

                       //操作

 

                    } finally {

                        lock.unlock();

                    }

 

                }

 

 

 

 

场景2：如果发现该操作已经在执行，等待一个一个执行（同步执行，类似synchronized）

这种比较常见大家也都在用，主要是防止资源使用冲突，保证同一时间内只有一个操作可以使用该资源。
但与synchronized的明显区别是性能优势（伴随jvm的优化这个差距在减小）。同时Lock有更灵活的锁定方式，公平锁与不公平锁，而synchronized永远是公平的。

这种情况主要用于对资源的争抢（如：文件操作，同步消息发送，有状态的操作等）

ReentrantLock默认情况下为不公平锁

 

?


1

2

private ReentrantLock lock = new ReentrantLock(); //参数默认false，不公平锁

private ReentrantLock lock = new ReentrantLock(true); //公平锁

?


1

2

3

4

5

6

7

8

try {

    lock.lock(); //如果被其它资源锁定，会在此等待锁释放，达到暂停的效果

 

   //操作

 

} finally {

    lock.unlock();

}

不公平锁与公平锁的区别：

公平情况下，操作会排一个队按顺序执行，来保证执行顺序。（会消耗更多的时间来排队）
不公平情况下，是无序状态允许插队，jvm会自动计算如何处理更快速来调度插队。（如果不关心顺序，这个速度会更快）

 

场景3：如果发现该操作已经在执行，则尝试等待一段时间，等待超时则不执行（尝试等待执行）

这种其实属于场景2的改进，等待获得锁的操作有一个时间的限制，如果超时则放弃执行。
用来防止由于资源处理不当长时间占用导致死锁情况（大家都在等待资源，导致线程队列溢出）。

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

                try {

                    if (lock.tryLock(5, TimeUnit.SECONDS)) {  //如果已经被lock，尝试等待5s，看是否可以获得锁，如果5s后仍然无法获得锁则返回false继续执行

 

 

                        try {

 

 

                            //操作

 

 

                        } finally {

                            lock.unlock();

                        }

 

 

                    }

                } catch (InterruptedException e) {

                    e.printStackTrace(); //当前线程被中断时(interrupt)，会抛InterruptedException                 

                }

 

  

  

 <div>

 

 

  

  

 </div>

<span></span>

 

场景4：如果发现该操作已经在执行，等待执行。这时可中断正在进行的操作立刻释放锁继续下一操作。

synchronized与Lock在默认情况下是不会响应中断(interrupt)操作，会继续执行完。lockInterruptibly()提供了可中断锁来解决此问题。（场景2的另一种改进，没有超时，只能等待中断或执行完毕）

这种情况主要用于取消某些操作对资源的占用。如：（取消正在同步运行的操作，来防止不正常操作长时间占用造成的阻塞）

?


1

2

3

4

5

6

7

8

9

try {

    lock.lockInterruptibly();

    //操作

 

} catch (InterruptedException e) {

    e.printStackTrace();

} finally {

    lock.unlock();

}

 

可重入概念

若一个程序或子程序可以“安全的被并行执行(Parallel computing)”，则称其为可重入（reentrant或re-entrant）的。即当该子程序正在运行时，可以再次进入并执行它（并行执行时，个别的执行结果，都符合设计时的预期）。可重入概念是在单线程操作系统的时代提出的。

http://my.oschina.net/noahxiao/blog/101558

 

时间： 2024-11-03 03:52:44

ReentrantLock可重入锁的使用场景（转）的相关文章

银行取款[多线程]{使用重入锁Lock接口ReentrantLock锁确保线程同步}

经典例子:老婆(朱丽叶)老公(罗密欧),使用银行卡和存折,或者网银等,同时对同一账户操作的安全问题.  此处用多线程实现,同时取款的模拟实现,使用使用Lock接口ReentrantLock锁确保线程同步,查看取款安全隐患问题,代码如下: -----------------------------------------------------------------------------------------------------------------------------------

Java锁的种类以及辨析（四）：可重入锁

作者:山鸡 锁作为并发共享数据,保证一致性的工具,在JAVA平台有多种实现(如 synchronized 和 ReentrantLock等等 ) .这些已经写好提供的锁为我们开发提供了便利,但是锁的具体性质以及类型却很少被提及.本系列文章将分析JAVA下常见的锁名称以及特性,为大家答疑解惑. 四.可重入锁: 本文里面讲的是广义上的可重入锁,而不是单指JAVA下的ReentrantLock. 可重入锁,也叫做递归锁,指的是同一线程 外层函数获得锁之后 ,内层递归函数仍然有获取该锁的代码,但不受影响

Java锁之可重入锁介绍_java

锁作为并发共享数据,保证一致性的工具,在JAVA平台有多种实现(如 synchronized 和 ReentrantLock等等 ) .这些已经写好提供的锁为我们开发提供了便利,但是锁的具体性质以及类型却很少被提及.本系列文章将分析JAVA下常见的锁名称以及特性,为大家答疑解惑. 四.可重入锁: 本文里面讲的是广义上的可重入锁,而不是单指JAVA下的ReentrantLock. 可重入锁,也叫做递归锁,指的是同一线程 外层函数获得锁之后 ,内层递归函数仍然有获取该锁的代码,但不受影响. 在JAV

python中threading之死锁和可重入锁

一.死锁 简单来说,死锁是一个资源被多次调用,而多次调用方都未能释放该资源就会造成死锁,这里结合例子说明下两种常见的死锁情况. 1.迭代死锁 该情况是一个线程"迭代"请求同一个资源,直接就会造成死锁: import threading import time class MyThread(threading.Thread):     def run(self):         global num         time.sleep(1)         if mutex.acqu

Python多线程编程（六）：可重入锁RLock_python

考虑这种情况:如果一个线程遇到锁嵌套的情况该怎么办,这个嵌套是指当我一个线程在获取临界资源时,又需要再次获取. 根据这种情况,代码如下: 复制代码 代码如下: ''' Created on 2012-9-8   @author: walfred @module: thread.ThreadTest6 '''    import threading  import time    counter = 0  mutex = threading.Lock()    class MyThread(thr

ReentrantLock(重入锁)以及公平性

Dedicate to Molly. 简介 ReentrantLock的实现不仅可以替代隐式的synchronized关键字,而且能够提供超过关键字本身的多种功能. 这里提到一个锁获取的公平性问题,如果在绝对时间上,先对锁进行获取的请求一定被先满足,那么这个锁是公平的,反之,是不公平的,也就是说等待时间最长的线程最有机会获取锁,也可以说锁的获取是有序的.ReentrantLock这个锁提供了一个构造函数,能够控制这个锁是否是公平的. 而锁的名字也是说明了这个锁具备了重复进入的可能,也就是说能够让

Java多线程同步问题的探究(三、Lock来了，大家都让开【1.认识重入锁】)

在上一节中,我们已经了解了Java多线程编程中常用的关键字synchronized,以及与之相关的对象锁机制.这一节中,让我们一起来认 识JDK 5中新引入的并发框架中的锁机制. 我想很多购买了<Java程序员面试宝典>之类图书的朋友一定对下面这个面试题感到非常熟悉: 问:请对比synchronized与java.util.concurrent.locks.Lock 的异同. 答案:主要相同点:Lock能完成synchronized所实现的所有功能 主要不同点:Lock有比synchroniz

PYTHON线程知识再研习D---可重入锁

不多解释,预防普通锁不正规的获取与释放 #!/usr/bin/env python # -*- coding: utf-8 -*- import threading import time class MyThread(threading.Thread): def run(self): global num time.sleep(1) if mutex.acquire(1): num += 1 msg = self.name + ' set num to ' + str(num) print m

python threading编程中的LOCK和RLOCK(可重入锁)

找到一本PYTHON并发编辑的书, 弄弄.. #!/usr/bin/env python # -*- coding: utf-8 -*- import threading import time shared_resource_with_lock = 0 shared_resource_with_no_lock = 0 COUNT = 100000 shared_resource_lock = threading.Lock() class Box(object): lock = threadin