What does Thread.sleep() do, and how does it differ from Object.wait() regarding locks?

## Threads and pausing A **thread** is an independent path of execution inside a program. The JVM can run many threads, and the OS **scheduler** decides which thread runs on a CPU core at any moment. Sometimes you want a thread to stop running for a while — to wait, to slow down a loop, to back off and retry. ## What `Thread.sleep` does `Thread.sleep(long millis)` is a **static** method, meaning it always acts on **the thread that calls it** (the *currently executing* thread). It tells the scheduler: "don't run me again for at least `millis` milliseconds." During that time the thread is in the **`TIMED_WAITING`** state (one of Java's thread states, meaning it is paused but will wake up on its own after a timeout). After the time elapses the thread becomes **`RUNNABLE`** again, but it does not necessarily run *immediately* — it just becomes eligible. So the real pause can be **longer** than requested (never shorter on a correct JVM). ```java Thread.sleep(1000); // pause this thread ~1 second ``` ## A lock / monitor — the key term In Java, every object has an associated **monitor** (also called an *intrinsic lock*). A `synchronized` block or method **acquires** that monitor on entry and **releases** it on exit, guaranteeing only one thread is inside the protected region at a time. ## The critical difference: sleep keeps locks `sleep` is **lock-agnostic**: if the sleeping thread is currently inside a `synchronized` block, it **keeps holding the monitor the whole time it sleeps**. No other thread can enter that synchronized region until the sleeper wakes up *and* exits the block. This is a common bug — sleeping while holding a lock serializes everyone. `Object.wait()` is different. It is an instance method that **must** be called while you already hold that object's monitor (else you get `IllegalMonitorStateException`). `wait()` **atomically releases** the monitor and parks the thread; another thread can now enter the synchronized region, change state, and call `notify()`/`notifyAll()` on the same object to wake the waiter. When the waiter wakes, it **re-acquires** the monitor before continuing. So `wait/notify` is a **coordination** mechanism ("wait until a condition holds"), whereas `sleep` is just a **timed pause**. ## Other differences - `sleep` is **static** (`Thread.sleep`), `wait` is an **instance** method on any object. - Both throw **`InterruptedException`** — another thread can call `interrupt()` to wake them early; you must handle that checked exception. - `wait` typically lives in a **loop** that re-checks the condition (to guard against *spurious wakeups* — waking with no notification). `sleep` does not need that. ## When to use which Use `sleep` for back-off, polling delays, simple timing — but **never while holding a lock you don't need**. Use `wait/notify` (or higher-level tools like `BlockingQueue`, `Condition`, `CountDownLatch`) when a thread must wait for *another* thread to make a condition true.