Unreleased lock¶

ID: java/unreleased-lock
Kind: problem
Security severity: 5.0
Severity: error
Precision: medium
Tags:
   - reliability
   - security
   - external/cwe/cwe-764
   - external/cwe/cwe-833
Query 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 example java.util.concurrent.locks.ReentrantLock, then the number of locks must match the number of unlocks in order to fully release the lock.

Any class that has both lock and unlock methods is considered a lock type. However, classes with names ending in “Pool” are excluded, as they typically manage a collection of resources.

Recommendation¶

It is recommended practice always to immediately follow a call to lock with a try block and place the call to unlock inside the finally block. Beware of calls inside the finally block that could cause exceptions, as this may result in skipping the call to unlock.

Example¶

The typical pattern for using locks safely looks like this:

public void m() {
   lock.lock();
   // A
   try {
      // ... method body
   } finally {
      // B
      lock.unlock();
   }
}

If any code that can cause a premature method exit (for example by throwing an exception) is inserted at either point A or B 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.

© GitHub, Inc.
Terms
Privacy