AbstractApplicationEventMulticaster#getApplicationListeners() should have double check for 'this.retrieverCache.get(cacheKey)' within synchronized block [SPR-10351]

[spring-projects-issues]

Artem Bilan opened SPR-10351 and commented

In the multi-threaded publishing events environment AbstractApplicationEventMulticaster#supportsEvent() may be invoked twice (or more) for the same event type: from first Thread, who builds cache entry in the synchronized block, and from second (and so on), who is waiting synchronization monitor.

---

Issue Links:

• Performance bottleneck and potential thread deadlock in DefaultSingletonBeanRegistry [SPR-8471] #13117 Performance bottleneck and potential thread deadlock in DefaultSingletonBeanRegistry

[spring-projects-issues]

Juergen Hoeller commented

We opted for a different tradeoff back in Spring Framework 3.2 GA already: We keep the locks as short as possible, accepting the potential for concurrent creation of cache entries in order to optimize for high-load scenarios with a pre-populated cache. Have a look at the latest code there.

Juergen

[spring-projects-issues]

Artem Bilan commented

Thanks, Juergen, I got it.
Of course, I can live with recreating the same cache entry in the multi-threaded environment, because it is still here.
However, it sounds like LockRegistry may have value here: https://jira.springsource.org/browse/INT-2909.
WDYT?