An infinite wait on a parallel context.getBean()

[justinas-dabravolskas]

Hi,
singleton dependency cycle initialized on a parallel thread causes an infinite wait on this.lenientCreationFinished.await().
The bean factory must be in preInstantiationPhase=true state with a singleton lock taken while the parallel thread (e.g. spawned from @PostConstruct) calls context.getBean("beanWithCycle").
Under those conditions DefaultSingletonBeanRegistry.getSingleton is called twice for the beanWithCycle, but the second invocation gets BeanCurrentlyInCreationException that triggers this.lenientCreationFinished.await() which in turn is never notified, because bean is created by the same thread.

"Thread-0" #21 [27395] prio=5 os_prio=31 cpu=33.45ms elapsed=21.40s tid=0x000000010f857c00 nid=27395 waiting on condition  [0x000000016f9c8000]
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base@21.0.6/Native Method)
	- parking to wait for  <0x000000061f9bc410> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(java.base@21.0.6/LockSupport.java:371)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base@21.0.6/AbstractQueuedSynchronizer.java:519)
	at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base@21.0.6/ForkJoinPool.java:3780)
	at java.util.concurrent.ForkJoinPool.managedBlock(java.base@21.0.6/ForkJoinPool.java:3725)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@21.0.6/AbstractQueuedSynchronizer.java:1712)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:311)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:337)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
	at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:254)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1667)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1555)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.resolveFieldValue(AutowiredAnnotationBeanPostProcessor.java:785)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:768)
	at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:146)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:509)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1445)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:600)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:523)
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:339)
	at org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda/0x00000070010914e8.getObject(Unknown Source)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:347)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:337)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
	at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:254)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1667)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1555)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.resolveFieldValue(AutowiredAnnotationBeanPostProcessor.java:785)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:768)
	at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:146)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:509)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1445)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:600)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:523)
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:339)
	at org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda/0x00000070010914e8.getObject(Unknown Source)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:347)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:337)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:227)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveNamedBean(DefaultListableBeanFactory.java:1525)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveNamedBean(DefaultListableBeanFactory.java:1483)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveBean(DefaultListableBeanFactory.java:542)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:371)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:364)
	at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1290)
	at org.example.beans.PostConstruct.lambda$postConstruct$0(PostConstruct.java:22)
	at org.example.beans.PostConstruct$$Lambda/0x00000070010ad730.run(Unknown Source)
	at java.lang.Thread.runWith(java.base@21.0.6/Thread.java:1596)
	at java.lang.Thread.run(java.base@21.0.6/Thread.java:1583)

An example of this situation in https://github.com/justinas-dabravolskas/spring-6.2.5-infinite-wait

Regards,
Justinas

[jhoeller]

It turns out that we only tested circular references within the main bootstrap thread and between the bootstrap thread and an unmanaged thread but not within an unmanaged thread. This has been addressed through an explicit check against the original creation thread now.

This revision is available in the latest 6.2.6 snapshot. Please give it an early try!

At the same time, we advise against the use of circular references, and actually also against the use of unmanaged threads during init methods. As of 6.2, there is an @Bean(bootstrap=BACKGROUND) feature which can be used as a safer replacement. Alternatively, consider starting such custom threads in a SmartInitializingSingleton.afterSingletonsInstantiated() method or in Lifecycle.start(), both of which do not execute within the singleton lock. Last but not least, it is advisable to force early initialization of such beans that the async thread depends on through an @DependsOn declaration on the containing bean.

[justinas-dabravolskas]

Thank you for such a quick fix. I fully understand that it's not the best practice. Current breakdown is:
<=6.1 Spring resolves this cycle without issues.
6.2-6.5 runs into an infinite wait.
6.2.6 snapshot throws BeanCurrentlyInCreationException which is a significant improvement over an infinite wait. It's probably a good compromise taking into account that issue happens just during pre init phase. Just a quick thought, but is it really safe from the memory leak perspective to keep reference to the thread here?

Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'cycleComponent1': Requested bean is currently in creation: Is there an unresolvable circular reference or an asynchronous initialization dependency?
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.beforeSingletonCreation(DefaultSingletonBeanRegistry.java:515)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:304)
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:337)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
        at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:254)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1689)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1577)
        at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.resolveFieldValue(AutowiredAnnotationBeanPostProcessor.java:785)
        ... 32 more

[jhoeller]

Thanks for the immediate feedback!

Since it is cleaned up in a finally block right afterwards, this is safe as far as I can judge. For such local applicability, there is no need for weak references or the like.

As for circular references in general, if at all, they should be forced to be resolved within the ordered initialization sequence in the main bootstrap thread. That said, ideally, they should rather be made lazy through @Autowired @Lazy declarations for at least one of the injection points involved, replacing the creation-time circular reference with lazy circular interaction at runtime.

[jhoeller]

Reopening for a further revision where we enforce a circular reference exception between all thread variations now, even for unfortunate scenarios with multiple unmanaged threads which could run into a deadlock otherwise.