This may seem a bit strange, because generally the tryLock method is used like this:

 Lock lock = ...;
  if (lock.tryLock()) {
      try {
          // do something with lock
          runnable.run();
      } finally {
          lock.unlock();
      }
  } 

Wouldn't this really lead to some race conditions?

safeLock here is to try best to wait. In Dubbo, those actions needed safeLock can accept delay, but cannot accept skip.

Also, the patch indubbo-registry/dubbo-registry-api/src/main/java/org/apache/dubbo/registry/client/event/listener/ServiceInstancesChangedListener.java is the real code to fix #14470. The original issue is once invoke failed, submitRetryTask won't being invoked because of the code order.

i got it, thanks for your patient explanation.