Lazy unlocking is also sometimes known as biased locking. This is an optimization of lock behavior that works if the assumption is valid that many locks are thread local, albeit possibly frequently taken and released. In lazy unlocking, the runtime gambles that locks are likely to remain thread local. When a lock is released for the first time, the runtime may choose not to unlock it, treating the unlock as a no-op. When the lock is later reacquired by the same thread, that lock also becomes a no-op. The worst case is, of course, if another thread tries to acquire the lazy locked monitor. In that case, it needs to be converted to a normal lock or forcefully unlocked to preserve semantics. Consequently, locks that are "ping ponging" back and forth, repeatedly being acquired and released by different threads are ill-suited for lazy unlocking.

A lazy unlocking implementation typically contains various heuristics to make it perform more optimally in a changing environment, for example, by banning its application on certain objects or certain object types that have too frequently needed to be forcefully unlocked.