== 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[]
