Deadlock in DefaultListableBeanFactory/DefaultSingletonBeanRegistry [SPR-10020]

[spring-projects-issues]

Glyn Normington opened SPR-10020 and commented

A user of Gemini Blueprint (nee Spring DM) has raised a bug ([1]) about a deadlock which appears to be caused by the combination of DefaultListableBeanFactory and DefaultSingletonBeanRegistry. I'm not sure which version of Spring framework they were using, but I checked the code at HEAD and the deadlock still appears to be possible.

The deadlock is easy to see in the bug description and involves two threads.

1. The thread "EclipseGeminiBlueprintExtenderThread-20" has synchronised on ConcurrentHashMap@3b38bbfa in DefaultListableBeanFactory.resetBeanDefinition while calling destroySingleton which then blocks waiting for LinkedHashMap@9c772ae.

2. The thread "Gemini Blueprint context shutdown thread" has synchronised on LinkedHashMap@9c772ae in DefaultSingletonBeanRegistry.destroySingletons while calling destroySingleton which results in a call to removeSingleton which then blocks waiting for ConcurrentHashMap@3b38bbfa.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=384080

---

Affects: 3.1.3, 3.2 RC1

Reference URL: https://bugs.eclipse.org/bugs/show_bug.cgi?id=384080

Issue Links:

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

[spring-projects-issues]

Glyn Normington commented

Thanks Juergen!

Also, from the user who raised the Blueprint bug:

(In reply to comment #4)

(In reply to comment #3)

A fix has been scheduled for Spring framework 3.2 RC2 and 3.1.4.

Perfect - thanks a lot for the effort!