CustomLock | trust wifi -

This may not be your problem, but the code has a race condition when adding a new lock: if two threads try to lock the same (new) file, they could both create a lock for it.  Both locks would get added to the list, but only the first would be found after that.  (This assumes that the list itself is thread-safe; otherwise one of the adds could fail, loop forever, or leave the list in an inconsistent state and crash later.)

You could fix this with some synchronisation.  But a better approach might be to store the locks in a ConcurrentHashMap (keyed on the lock ID) instead of a list, and use an atomic operation such as computeIfAbsent() to create a new lock safely.  (That would also improve asymptotic performance, as it would avoid scanning a list each time.)

Also, as a matter of style, the use of apply() on the lock looks a bit awkward.  (Its usual use is for customising a newly-created object.)  I think let() would be more idiomatic there; you'd just have to change this to it inside.  Or use an old-fashioned temporary variable, of course.