50 lines
1.1 KiB
Plaintext
50 lines
1.1 KiB
Plaintext
== Why is this an issue?
|
|
|
|
`java.util.concurrent.locks.Lock` offers far more powerful and flexible locking operations than are available with `synchronized` blocks.
|
|
So synchronizing on a `Lock` instance throws away the power of the object, as it overrides its better locking mechanisms.
|
|
Instead, such objects should be locked and unlocked using one of their `lock` and `unlock` method variants.
|
|
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,java,diff-id=1,diff-type=noncompliant]
|
|
----
|
|
Lock lock = new MyLockImpl();
|
|
synchronized(lock) { // Noncompliant
|
|
// ...
|
|
}
|
|
----
|
|
|
|
|
|
=== Compliant solution
|
|
|
|
[source,java,diff-id=1,diff-type=compliant]
|
|
----
|
|
Lock lock = new MyLockImpl();
|
|
if (lock.tryLock()) {
|
|
try {
|
|
// ...
|
|
} finally {
|
|
lock.unlock();
|
|
}
|
|
}
|
|
----
|
|
|
|
|
|
== Resources
|
|
|
|
* https://wiki.sei.cmu.edu/confluence/x/qjdGBQ[CERT, LCK03-J.] - Do not synchronize on the intrinsic locks of high-level concurrency objects
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
=== Message
|
|
|
|
Synchronize on this "Lock" object using "acquire/release".
|
|
|
|
|
|
endif::env-github,rspecator-view[]
|