Skip to main content
Journey Uncommon Logo
JourneyUncommon
hardJavaAQS internalsSingle-choice MCQ

A custom AQS lock implements tryAcquire/tryRelease and exposes only acquire()/release(). A maintainer adds a tryLock(timeout) by calling tryAcquireNanos(). Without changing tryAcquire, why might a thread that times out and abandons the wait still leave the queue in a state that delays the next waiter, and what method exists precisely to prevent it?

// inside acquireQueued / doAcquireNanos, on timeout: // the node is left in the CLH queue // AQS calls this on timeout/interrupt: cancelAcquire(node);