ReentrantLock's javadoc suggests the following usage pattern:

{code:java}
 * lock.lock(); // block until condition holds
 * try {
 * // ... method body
 * } finally {
 * lock.unlock()
 * }
{code}

Unfortunately, {{StackOverflowError}} might result in lock being **locked** when users follow the recommendations.

The attached testcase reproduces the issue.

{noformat}
% java LockVsStackOverflow
Initial lock.isLocked() state = false
OpenJDK 64-Bit Server VM warning: Potentially dangerous stack overflow in ReservedStackAccess annotated method LockVsStackOverflow.doSmth()V [1]
FAIL: lock is LOCKED in finally, however it must be unlocked since the code did use try-finally
Exception in thread "main" java.lang.StackOverflowError
at java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:173)
at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1059)
at java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494)
at LockVsStackOverflow.doSmth(LockVsStackOverflow.java:30)
at LockVsStackOverflow.doSmth(LockVsStackOverflow.java:28)
...
{noformat}

Note: "FAIL: lock is LOCKED in finally" in the output.

I tested with

{noformat}
% java -version
openjdk version "21-ea" 2023-09-19
OpenJDK Runtime Environment (build 21-ea+30-2426)
OpenJDK 64-Bit Server VM (build 21-ea+30-2426, mixed mode, sharing)
{noformat}