Asynchronous initialization of Spring beans

[thorgits]

As the most people's problems, we have come to the same confusion. Our project has about 1,000 beans, but the startup time has been close to 10 minutes. Every time we fix a bug and do an integrated deployment, it takes a long time to wait. There are two Suggestions could be taken into consideration.

1. On the basis of existing source code, the initialization of beans with init method or afterPropetiesSet left to the thread pool, but the dependency safety must be ensured, such as A->B, but B is not initialized. We can give each Bean a proxy, ensure B initialized at first through the way of intercepting the proxy's methods.

2. Static analysis of dependencies between beans generates multiple graphs.

• Calculate Strongly Connected Component(SCC) of each Directed acyclic graph (DAG) reference the Tarjan algorithm
• Each SCC subgraph as a specific node
• Generate a parallel execution schedule based on topological sort.

Issue Links:
#13410 Parallel bean initialization during startup [SPR-8767]
#19487 Asynchronous initialization of beans during startup [SPR-14920]

[snicoll]

@thorgits thanks for sharing the idea.

Our project has about 1,000 beans, but the startup time has been close to 10 minutes.

Would you be able to share more details as what those 1000 beans are doing? Have you considered using lazy initialization? Either by tagging beans for which your code is very costly or globally. If you are using Spring Boot, Spring Boot 2.2 will have an option available to you via a configuration property. But you could apply the same thing to your local project by registering this bean factory post processor to the context.

There are other initiatives as well such as dedicated bootstrap mode for JPA/Hibernate but I don't know if that's applicable to your project.

[thorgits]

@snicoll thanks for your suggestions.
Most beans are service or RPC service, and some services may depend on RPC service for loading, so lazy initialization solves part of the problem.

[jhoeller]

Closing this as a duplicate of #13410 and #19487 for further purposes. We are going to reconsider our options there for 6.2 or otherwise for 7.0.