Unreleased lock¶
ID: java/unreleased-lockKind: problemSecurity severity: 5.0Severity: errorPrecision: mediumTags: - reliability - security - external/cwe/cwe-764 - external/cwe/cwe-833Query suites: - java-security-extended.qls - java-security-and-quality.qls
Click to see the query in the CodeQL repository
When a thread acquires a lock it must make sure to unlock it again; failing to do so can lead to deadlocks. If a lock allows a thread to acquire it multiple times, for examplejava.util.concurrent.locks.ReentrantLock, then the number of locks must match the number of unlocks in order to fully release the lock.
Recommendation¶
It is recommended practice always to immediately follow a call tolock with atry block and place the call tounlock inside thefinally block. Beware of calls inside thefinally block that could cause exceptions, as this may result in skipping the call tounlock.
Example¶
The typical pattern for using locks safely looks like this:
publicvoidm(){lock.lock();// Atry{// ... method body}finally{// Block.unlock();}}
If any code that can cause a premature method exit (for example by throwing an exception) is inserted at either pointA orB then the method might not unlock, so this should be avoided.
References¶
Java API Specification:java.util.concurrent.locks.Lock,java.util.concurrent.locks.ReentrantLock.
Common Weakness Enumeration:CWE-764.
Common Weakness Enumeration:CWE-833.