为什么递归获取（可重入）锁？

Question

ReentrantLock allows a thread to acquire the same lock recursively, so that a lock count is incremented and decremented on successive lock/unlock. Whereas the lock count has to be decremented to zero before it is released to other threads.

Why or under what circumstances would I write code to acquire a lock recursively?

The only point I can see in having the feature is to make it convenient for us to write recursive code, where a method (which in the course of its execution acquires a lock) is called recursively.

Are there any other situations where recursive/repeated acquisition of a lock by a thread may be useful ?

Clarification of the question:

• Please ignore the lock being reentrant. Just so happens that recursivity is provided by reentrant lock.
• I am referring to the recursive feature of a lock
• Please do not answer with why use reentrant lock.
• Please do not answer with "recursivity is not the main feature of reentrant lock"
• I want to know what situations require the recursive acquisition of a lock, regardless if the lock is reentrant or not.

Answer 1

Might as well search better: this should be helpful

A use case for re-entrant locking:

A (somewhat generic and contrived) example of an application for a re-entrant lock might be:

1. You have some computation involving an algorithm that traverses a graph (perhaps with cycles in it). A traversal may visit the same node more than once due to the cycles or due to multiple paths to the same node.

2. The data structure is subject to concurrent access and could be updated for some reason, perhaps by another thread. You need to be able to lock individual nodes to deal with potential data corruption due to race conditions. For some reason (perhaps performance) you don't want to globally lock the whole data structure.

3. You computation can't retain complete information on what nodes you've visited, or you're using a data structure that doesn't allow 'have I been here before' questions to be answered quickly.

4. An example of this situation would be a simple implementation of Dijkstra's algorithm with a priority queue implemented as a binary heap or a breadth-first search using a simple linked list as a queue. In these cases, scanning the queue for existing insertions is O(N) and you may not want to do it on every iteration.

In this situation, keeping track of what locks you've already acquired is expensive. Assuming you want do the locking at the node level a re-entrant locking mechanism alleviates the need to tell whether you've visited a node before. You can just blindly lock the node, perhaps unlocking it after you pop it off the queue.