rspec/rules/S2276/java/rule.adoc

71 lines
1.8 KiB
Plaintext

== Why is this an issue?
In a multithreaded environment, a thread may need to wait for a particular condition to become true.
One way of pausing execution in Java is `Thread.sleep(...)`.
If a thread that holds a lock calls `Thread.sleep(...)`, no other thread can acquire said lock.
This can lead to performance and scalability issues, in the worst case leading to deadlocks.
== How to fix it
Call `wait(...)` on the monitor object instead of using `Thread.sleep(...)`.
While `wait(...)` is executed, the lock is temporarily released and hence other threads can run in the meantime.
=== Code examples
==== Noncompliant code example
[source,java,diff-id=1,diff-type=noncompliant]
----
public void doSomething(){
synchronized(monitor) {
while(notReady()){
Thread.sleep(200); // Noncompliant, any other thread synchronizing on monitor is blocked from running while the first thread sleeps.
}
process();
}
...
}
----
==== Compliant solution
[source,java,diff-id=1,diff-type=compliant]
----
public void doSomething(){
synchronized(monitor) {
while(notReady()){
monitor.wait(200); // Compliant, the current monitor is released.
}
process();
}
...
}
----
== Resources
* https://wiki.sei.cmu.edu/confluence/x/YTdGBQ[CERT, LCK09-J.] - Do not perform operations that can block while holding a lock
ifdef::env-github,rspecator-view[]
'''
== Implementation Specification
(visible only on this page)
=== Message
Replace the call to "Thread.sleep(...)" with a call to "wait(...)".
'''
== Comments And Links
(visible only on this page)
=== on 15 Feb 2016, 17:17:18 Ann Campbell wrote:
This RSpec exlicitly _not_ expanded to cover full scope of CERT, LCK09-J. because the other operations _can_ lead to problems (but may not), whereas for `sleep` there is a problem sure.
endif::env-github,rspecator-view[]