Right now, if two different threads invoke LockImpl.tryLock() on the same LockImpl instance, only one of them will obtain the lock, however both will attempt to update the AtomicReference<Thread> holder. Therefore the LockImpl may be left with a null holder value, even if the lock is actually held by another thread.

Similar issues might occur with the other methods (lock(), lockInterruptibly(), etc)

This can be worked around by obtaining new LockImpl instances on every use. In our use case we were caching the LockImpl instances for each lock name, so that's why we came across this.