2023-05-03 11:06:20 +02:00
== Why is this an issue?
2021-04-28 16:49:39 +02:00
``++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()++``.
2021-04-28 18:08:03 +02:00
2023-05-03 11:06:20 +02:00
=== Noncompliant code example
2021-04-28 16:49:39 +02:00
2022-02-04 17:28:24 +01:00
[source,java]
2021-04-28 16:49:39 +02:00
----
Lock lock = new MyLockImpl();
synchronized(lock) { // Noncompliant
//...
}
----
2021-04-28 18:08:03 +02:00
2023-05-03 11:06:20 +02:00
=== Compliant solution
2021-04-28 16:49:39 +02:00
2022-02-04 17:28:24 +01:00
[source,java]
2021-04-28 16:49:39 +02:00
----
Lock lock = new MyLockImpl();
lock.tryLock();
//...
----
2021-04-28 18:08:03 +02:00
2023-05-03 11:06:20 +02:00
== Resources
2021-04-28 16:49:39 +02:00
* https://wiki.sei.cmu.edu/confluence/x/qjdGBQ[CERT, LCK03-J.] - Do not synchronize on the intrinsic locks of high-level concurrency objects
2021-04-28 18:08:03 +02:00
2021-09-20 15:38:42 +02:00
ifdef::env-github,rspecator-view[]
'''
== Implementation Specification
(visible only on this page)
2023-05-25 14:18:12 +02:00
=== Message
Synchronize on this "Lock" object using "acquire/release".
2021-09-20 15:38:42 +02:00
endif::env-github,rspecator-view[]