rspec/rules/S2442/java/rule.adoc

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