BeanCurrentlyInCreationException is thrown when multiple threads simultaneously try to create bean (Spring 6.2.2)

[mpwong852]

It is similar problem what is described in the issue #34186

The Spring version is "6.2.2" & Spring boot version is "3.4.2"

My application implements CommandLineRunner, and is a jar file.

The BeanCurrentlyInCreationException will be happen when I run the jar file sometime.

Below is the detail log:

2025-02-05 16:55:39,016207| INFO|TID=74|HAControllerThread|DefaultListableBeanFactory:|Creating singleton bean 'inplayIncidentDao' in thread "HAControllerThread" while other thread holds singleton lock for other beans

2025-02-05 16:55:39,065783|DEBUG|TID=1|main|DefaultListableBeanFactory:|Creating shared instance of singleton bean 'inplayIncidentDao'

Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'inplayIncidentDao': Requested bean is currently in creation: Is there an unresolvable circular reference or an asynchronous initialization dependency?

These issues occur randomly, and this problems is start from Spring Framework 6.2.x.

I never face those issue in Spring Framework 6.1.x

[mpwong852]

@jhoeller

In Spring Framework 6.2.0, the BeanCurrentlyInCreationException is 100% happen.
After your help in Spring Framework 6.2.2 467d5f3 , the issue will not 100% happen, but still occur randomly.

Do you have any idea to avoid/ignore the "BeanCurrentlyInCreationException" ?

Many thank.

[jhoeller]

You could try the latest 6.2.3 snapshot which has another revision of the locking algorithm.

Where are the other threads actually coming from in your scenario? Spring bootstrapping is generally single-threaded, just with background threads for specific beans possibly. Uncontrolled multi-threaded initialization where multiple threads try to create the same beans is generally not desirable.

Completely avoiding such exceptions in such uncontrolled multi-threaded initialization scenarios is hard. We might have to provide an option to consistently enforce strong locking again, like it was in 6.1.x (at the expense of potentially running into deadlocks which could happen there in some situations).