可重入锁,从字面来理解,就是可以重复进入的锁。
可重入锁,也叫做递归锁,指的是同一线程外层函数获得锁之后,内层递归函数仍然有获取该锁的代码,但不受影响。
在JAVA环境下ReentrantLock和synchronized都是可重入锁。
synchronized是一个可重入锁。在一个类中,如果synchronized方法1调用了synchronized方法2,方法2是可以正常执行的,这说明synchronized是可重入锁。否则,在执行方法2想获取锁的时候,该锁已经在执行方法1时获取了,那么方法2将永远得不到执行。
可重入锁在什么场景使用呢?
可重入锁主要用在线程需要多次进入临界区代码时,需要使用可重入锁。具体的例子,比如上文中提到的一个synchronized方法需要调用另一个synchronized方法时。
可重入锁的实现原理是怎么样的?
加锁时,需要判断锁是否已经被获取。如果已经被获取,则判断获取锁的线程是否是当前线程。如果是当前线程,则给获取次数加1。如果不是当前html" target="_blank">线程,则需要等待。
释放锁时,需要给锁的获取次数减1,然后判断,次数是否为0了。如果次数为0了,则需要调用锁的唤醒方法,让锁上阻塞的其他线程得到执行的机会。
下面是一个用synchronized实现的例子:
public class ReentrantTest implements Runnable { public synchronized void get() { System.out.println(Thread.currentThread().getName()); set(); } public synchronized void set() { System.out.println(Thread.currentThread().getName()); } public void run() { get(); } public static void main(String[] args) { ReentrantTest rt = new ReentrantTest(); for(;;){ new Thread(rt).start(); } } }
整个过程没有发生死锁的情况,截取一部分输出结果如下:
Thread-8492
Thread-8492
Thread-8494
Thread-8494
Thread-8495
Thread-8495
Thread-8493
Thread-8493
set()和get()同时输出了线程名称,表明即使递归使用synchronized也没有发生死锁,证明其是可重入的。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对小牛知识库的支持。如果你想了解更多相关内容请查看下面相关链接
书中解释了在上面的代码中...“因为Widget和LoggingWidget中的doSomething方法都是同步的,所以在继续之前,每个方法都试图获取小部件上的锁。” 我运行了上面的代码来观察内部锁。上面的引文似乎暗示线程在Widget对象上获得了一个内在锁,但我观察到的是线程在LoggingWidget上获得了一个锁。我不知道如何核实收购数量,所以无法观察到这一点。 这本书是可以互换地使用lo
(1)都是可重入锁; (2)ReentrantLock内部是实现了Sync,Sync继承于AQS抽象类。Sync有两个实现,一个是公平锁,一个是非公平锁,通过构造函数定义。AQS中维护了一个state来计算重入次数,避免频繁的持有释放操作带来的线程问题。 (3)ReentrantLock只能定义代码块,而Synchronized可以定义方法和代码块; 4、Synchronized是JVM的一个内部
主要内容:1 什么是Java可重入锁,2 Java可重入锁的优势,3 Java可重入锁的例子1 什么是Java可重入锁 根据Sun公司的说法,Java锁是可重入的,这意味着,如果从方法中调用方法,则Java线程可以将同一把锁用于不同的同步方法。 2 Java可重入锁的优势 它避免了单线程死锁。 3 Java可重入锁的例子 让我们通过以下示例了解Java可重入锁: 在此类中,m和n是同步方法。m() 方法在内部调用n() 方法。 现在让我们在线程上调用m() 方法。在下面给出的类中,我们使
为什么java可重入锁不会导致死锁?
本文向大家介绍java乐观锁原理与实现案例分析,包括了java乐观锁原理与实现案例分析的使用技巧和注意事项,需要的朋友参考一下 本文实例讲述了java乐观锁原理与实现。分享给大家供大家参考,具体如下: 简单说说乐观锁。乐观锁是相对于悲观锁而言。悲观锁认为,这个线程,发生并发的可能性极大,线程冲突几率大,比较悲观。一般用synchronized实现,保证每次操作数据不会冲突。乐观锁认为,线程冲突可能
API文档说明: 这个类的构造函数接受一个可选的公平性参数。当设置为true时,在争用状态下,锁倾向于授予对等待时间最长的线程的访问权限。 注意,锁的公平性并不能保证线程调度的公平性。因此,使用公平锁的许多线程中的一个可以连续多次获得它,而其他活动线程没有进展,并且当前没有持有锁。 我无法理解第2点: 如果一个线程连续多次获得锁,那么根据第1点,其他线程将等待更长时间,这确实意味着它们下次将获得锁