ServletContext atomic register of bean

[lmagyar89]

As far as I can see the registering beans to javax.servlet.ServletContext is not atomic.
Destruction callback registration has some thread-safe issues as it using not thread safe collection.

[jhoeller]

On review, our web scope implementations generally don't provide atomic bean instance guarantees, neither for request nor for session scopes and therefore arguably not for the ServletContext scope either. Even the destroy callbacks are just a scope cleanup mechanism, with the then-latest bean instance to be processed but no individual destruction guarantees for beans that got programmatically removed inbetween. If you need atomic bean instance handling, your primary choice is the singleton scope.

That said, you got a point that the destruction callback handling in ServletContextScope has a thread-safe visibility issue and needs some level of synchronization, at least if it is meant to be used for lazy bean initialization at runtime (whereas it was originally only really intended for web application startup). Even beyond that, we should consistently remove the destruction callbacks before we remove the instance attributes themselves, since otherwise we may - in a race condition - remove a newly registered destruction callback from some other thread that triggered re-creation of the same scoped bean. I'll deal with this in a separate GitHub issue, to be consistently handled across all web scope implementations.

[jhoeller]

See #23117 for consistent removal of destruction callbacks, also including basic synchronization in ServletContextScope (but just for thread-safe visibility, with no atomic bean instance guarantees).

Thanks for the pull request, in any case!