Affects: 5.2.6.RELEASE

The following scenario triggers deadlock:

  • Run non-main threads that invoke a method of @Repository bean in @PostConstruct block.
  • The method throws an exception.
  • Wait the non-main threads to be completed in @PostConstruct block.

This is a sample project to demonstrate it: https://github.com/izeye/spring-boot-throwaway-branches/tree/post-construct-deadlock

Just running it will trigger deadlock.

I'm not sure if this is unsupported usage or bug.

Comment From: izeye

On second thought, my scenario seems to be better suited to use ApplicationStartedEvent, so feel free to close this if it's unsupported or illegal usage.

See https://github.com/izeye/spring-boot-throwaway-branches/tree/post-construct-deadlock-application-listener

Comment From: izeye

Sorry for back and forth, but ApplicationStartedEvent doesn't seem to work for my scenario.

I want a hook before application start-up, but handling it in ApplicationListener.onApplicationEvent() doesn't seem to block application start-up. I also want application to fail to start by throwing an exception, but it doesn't seem to be the case, either.

Comment From: jhoeller

For such a scenario, your bean should either implement SmartInitializingSingleton.afterSingletonsInstantiated() or rely on the context refresh event: ApplicationListener<ContextRefreshedEvent> or @EventListener(ContextRefreshedEvent.class). Those phases are meant for post-initialization work, so you could easily trigger your asynchronous repository tasks from there. And both variants would would cause the application startup to fail, while still coming after all regular singleton initialization and therefore outside of any container lock.

Alternatively, you may implement the (Smart)Lifecycle interface and integrate with the container's overall lifecycle management, including an auto-startup mechanism, a pre-destroy stop step, and potential stop/restart callbacks.

I'll turn this into a documentation ticket for such purposes.