RSPEC-2276 - "wait(...)" should be used instead of "Thread.sleep(...)" when a lock is held

If Thread.sleep(...) is called when the current thread holds a lock, it could lead to performance and scalability issues, or even worse to deadlocks because the execution of the thread holding the lock is frozen. It’s better to call wait(...) on the monitor object to temporarily release the lock and allow other threads to run.

Noncompliant Code Example

public void doSomething(){
  synchronized(monitor) {
    while(notReady()){
      Thread.sleep(200);
    }
    process();
  }
  
}

Compliant Solution

public void doSomething(){
  synchronized(monitor) {
    while(notReady()){
      monitor.wait(200);
    }
    process();
  }
  
}

https://rules.sonarsource.com/java/RSPEC-2276

Start with the RSPEC-2276 description and its noncompliant and compliant Java examples. Identify the static-analysis entry point for detecting Thread.sleep(...) while a lock is held, then verify that the reported case recommends wait(...) on the monitor object and that the rule handles the documented example.