Inspired by #22929, it turns out that our web scope implementations remove the destruction callbacks after removing the instance attribute themselves. This exposes a potential race condition where we might remove a newly registered destruction callback from some other thread that triggered re-creation of the same scoped bean in the meantime. It is safer and in line with the semantics of scoped destruction callbacks to remove the destruction callbacks first so that once the instance is being removed, some other thread may immediately register a new destruction callback.

That aside, as pointed out in #22929, ServletContextScope should use synchronization for its destructionCallbacks data structure for immediate thread-safe visibility of the current state in case of lazy bean initialization at runtime (beyond the startup thread).