What does tryLock() do, and how do its non-blocking and timed forms help avoid deadlock?

## Background: blocking and deadlock A **lock** lets only one **thread** (concurrent execution path) into a guarded section at a time. The classic acquisition methods *block*: a thread that requests a held lock is suspended until the lock is free. Blocking is fine — until two threads block on each other. A **deadlock** is a permanent standstill: thread A holds lock 1 and waits for lock 2, while thread B holds lock 2 and waits for lock 1. Neither can proceed, neither will release, and both are stuck forever. The root cause here is **lock-ordering inconsistency** — different threads acquire the same locks in different orders. `synchronized` offers no escape: once it starts waiting for a monitor, it waits forever. `ReentrantLock` adds two methods that let a thread *decline to wait*. ## tryLock() — the non-blocking attempt ```java if (lock.tryLock()) { // returns immediately try { // got it — do the work } finally { lock.unlock(); // only unlock because tryLock returned true } } else { // didn't get it — do something else, skip, or retry later } ``` `tryLock()` acquires the lock **only if it is free at that instant**, returning `true`; otherwise it returns `false` instantly without blocking. The thread keeps running and can choose an alternative. (Caveat: the no-arg `tryLock()` **barges** ahead of any fairness queue — it grabs a free lock even if other threads have been waiting longer. If you set fairness, use the timed `tryLock(0, unit)` form to honor the queue.) ## tryLock(timeout, unit) — the bounded wait ```java if (lock.tryLock(500, TimeUnit.MILLISECONDS)) { try { /* work */ } finally { lock.unlock(); } } else { // gave up after 500ms } ``` This blocks like `lock()` but only up to the timeout, then returns `false`. It also throws `InterruptedException` if interrupted while waiting, so it is both *timed* and *interruptible*. Use it to bound how long an operation can stall — essential in latency-sensitive or responsive systems. ## Deadlock avoidance: the try-and-back-off pattern When you must hold two locks at once and cannot guarantee a global lock ordering, use `tryLock` to break the deadlock condition: a thread never blocks while holding another lock. Instead it *tries* each, and on any failure releases everything and retries. ```java while (true) { if (lock1.tryLock()) { try { if (lock2.tryLock()) { try { doWork(); return; // success — both held } finally { lock2.unlock(); } } } finally { lock1.unlock(); } // release lock1 if lock2 failed } Thread.sleep(random.nextInt(50)); // randomized backoff before retry } ``` Because no thread ever *waits* while holding a lock, the circular-wait condition required for deadlock cannot form. ## The new risk: livelock If two threads repeatedly grab one lock, fail the other, release, and retry **in lockstep**, they can spin forever making no progress — a **livelock** (the threads aren't blocked, they're just endlessly undoing each other). The fix is the **randomized backoff** above: random sleep before retry desynchronizes them so one wins. ## Rules to get right 1. **Only `unlock()` a lock whose `tryLock()` returned `true`.** Unlocking a lock you never acquired throws `IllegalMonitorStateException`. 2. **Still use `finally`** for every successful acquisition. 3. Prefer a **consistent global lock order** when you can arrange one — it's simpler and deadlock-free without retries; reserve `tryLock` for when ordering is impossible (e.g. locks chosen at runtime).