40 lines
921 B
Plaintext
40 lines
921 B
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++`` throws away the power of the object, and is just silly. Instead, such objects should be locked and unlocked using ``++tryLock()++`` and ``++unlock()++``.
|
|
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,java]
|
|
----
|
|
Lock lock = new MyLockImpl();
|
|
synchronized(lock) { // Noncompliant
|
|
//...
|
|
}
|
|
----
|
|
|
|
|
|
=== Compliant solution
|
|
|
|
[source,java]
|
|
----
|
|
Lock lock = new MyLockImpl();
|
|
lock.tryLock();
|
|
//...
|
|
----
|
|
|
|
|
|
== 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)
|
|
|
|
include::message.adoc[]
|
|
|
|
endif::env-github,rspecator-view[]
|