What do a non-blocking lock attempt (tryLock) and a timed lock acquisition give you that a plain blocking acquire does not, and what goes wrong when they are used carelessly?

## The semantics Three acquisition modes matter: | Mode | Blocks? | Returns | |---|---|---| | `acquire()` | until granted | nothing — you hold it | | `tryAcquire()` | never | true (held) / false (not held) | | `tryAcquire(timeout)` | up to the deadline | true / false | The crucial change is control flow: a blocking acquire has one outcome, so callers write no failure logic. The `try` variants have two, and the second one is a design decision — retry, degrade, fail the request, or escalate. ## Use 1 — breaking potential deadlock cycles Deadlock needs four conditions to hold at once; one of them is **hold-and-wait**. A blocking acquire while already holding a lock is hold-and-wait made concrete. A timed or non-blocking attempt breaks it: ``` acquire(A) if (not tryAcquire(B)): release(A) // give up everything sleep(randomBackoff()) // desynchronise retry ``` This is the standard technique when a consistent global lock order cannot be established — for example transferring between two accounts identified only at runtime, where the natural order differs per call. Ordering locks by a stable key is still the better fix when available; try-and-back-off is what you use when it is not. ## Use 2 — bounded latency and load shedding In a request-serving system, an unbounded acquire converts lock contention into unbounded queueing: threads pile up invisibly, the latency tail explodes, and thread pools saturate. A timed acquire converts it into an explicit, measurable failure: return a cached value, return 'busy', or route elsewhere. That is a deliberate choice to trade a small error rate for a bounded p99. ## Use 3 — cancellation and health A timed acquire gives cancellation points: a shutdown routine that must not hang, a watchdog that reports 'lock held longer than X', or a diagnostic that samples how often acquisition fails. Failed-attempt counts and wait-time histograms are among the cheapest contention signals you can collect. ## The failure modes **Livelock.** Threads that fail, immediately retry, fail again, and repeat make progress-free noise. Because they retry in lockstep after each collision, they can collide indefinitely. The fix is randomised exponential backoff, exactly as in network collision avoidance: sleep a random interval that grows with the retry count. Without randomisation, symmetric threads resynchronise; without a bound, a starving thread never gives up. **Unwritten failure paths.** `if (tryLock()) { ...work... }` with no `else` silently skips the work. This is a real and common bug: the code compiles, tests pass under no contention, and under load the operation quietly does not happen. Every try must have a considered alternative — including 'fall back to a blocking acquire with a deadline'. **Try-as-spin.** A tight `while (!tryLock()) {}` loop burns a core and, on a single-core or oversubscribed system, can prevent the holder from being scheduled to release it. Spinning is a legitimate strategy but with a bounded spin count then a park, which is what a proper adaptive lock already does internally. **Fairness interaction.** On a fair lock, plain acquire queues, but an untimed `tryAcquire` typically succeeds only if the lock is *free*, and in some designs it barges ahead of queued waiters. Mixing barging tries into a fair lock quietly reintroduces the starvation that fairness was chosen to prevent. **Correct release discipline.** The acquire result must gate the release: releasing a lock you failed to acquire is an error, and forgetting to release on the success path is a leak. The safe shape is: attempt, and only on success enter a try/finally that releases.