Slow prototype bean creation when migrating spring-boot 2.3.5 -> 2.4.1

[nixel2007]

Affects: Spring Framework 5.3.2

---

I have a project (console based, environment=NONE, only base spring boot starter) with a lot of prototype bean creations at application runtime (not startup), ~15k of beans. I have one interface and near 150 different implemantions of it marked with

@Component
@Primary
@Scope("prototype")

@Configuration has @Bean-method, some kind of object provider, which get bean of concrete class (not interface):

@Configuration
@RequiredArgsConstructor
public class DiagnosticConfiguration {

  private final ApplicationContext applicationContext;

  @Bean
  @Scope("prototype")
  public <T extends BSLDiagnostic> T diagnostic(Class<T> clazz) {
    return applicationContext.getBean(clazz);
  }

}

On spring boot 2.3.5 15000 of diagnostic calls take 12 seconds. On spring boot 2.4.1 - more than 75 seconds. no changes to application code or configs, just dependency bump.

On flame graph I discovered problem (synchonized issue) at CommonAnnotationBeanPostprocessor.findResourceMetadata
https://postimg.cc/3ywf5B6Q

Comparison of:
2.3.5: https://postimg.cc/HVdnQYLn
2.4.1: https://postimg.cc/KKw4LtKh

Looks like all bean creations on 2.3.5 took metadata from cache, while all creations at 2.4.1 have "cache miss" and are forced to recreate metadata.

I've asked about this at spring-boot gitter and was redirected here by @wilkinsona.

P.S. I'll try to provide some demo-project, need some time to reproduce it.

[jhoeller]

Could you debug into it and see what causes the cache misses specifically? What kind of cache key is being computed, and how does needsRefresh behave?

[sbrannen]

P.S. I'll try to provide some demo-project, need some time to reproduce it.

Yes, a demo project would be useful.

We are very interested in seeing how your prototype-scoped BSLDiagnostic bean (object provider) is used in practice and what it's being used to achieve.

[jhoeller]

Just noticed that your @Bean method delegates to ApplicationContext.getBean underneath, which is rather unexpected. From a Spring container perspective, this is a central managed bean definition on top of different underlying managed beans. The prototype bean definition will have a constantly changing bean type here, so indeed we might replace the cache entry every time since we don't expect the bean type of a specific bean definition to change all the time.

From that perspective, you might not actually see a 5.2->5.3 regression but rather the effect of a recent fix that got backported to 5.2.x as well: #26019 - but you might not have encountered it in the latest 5.2.x release yet. I'm afraid this fix restores correct behavior; I highly recommend reachitecting your lookup approach to let Spring's container do its per-bean type management.

[jhoeller]

Could you please try Framework 5.2.12 / Boot 2.3.7 as well, confirming that you're seeing the same performance difference there?

In any case, our previous behavior there was clearly broken for changing bean types with new metadata elements to discover, once the first bean type did not expose any metadata elements at all. We could cache metadata for all occurring bean types of the same bean definition but that'd really be against the grain of our bean definition model. I'd rather recommend a custom lookup method that delegates to ApplicationContext.getBean, with that lookup method not being marked as a managed bean definition itself (given that there is nothing for the container to manage, just unnecessary metadata discovery overhead).

[wylgithub]

very nice demo！

[nixel2007]

@sbrannen

We are very interested in seeing how your prototype-scoped BSLDiagnostic bean (object provider) is used in practice and what it's being used to achieve.

I can link real project :)

repo - https://github.com/1c-syntax/bsl-language-server, some docs in english - https://1c-syntax.github.io/bsl-language-server/en)

It is a Language Server Protocol implementation for 1C:Enterprise Platform internal language. One of its components is a static alanysis tool, implemented via "diagnostics" ("inspections" in terms of IntelliJ IDEA)

All diagnostics implements base interface BSLDiagnostic - https://github.com/1c-syntax/bsl-language-server/blob/develop/src/main/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/BSLDiagnostic.java and annotated with DiagnosticMetadata (https://github.com/1c-syntax/bsl-language-server/blob/develop/src/main/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/metadata/DiagnosticMetadata.java) which marks them as @Component

For example: https://github.com/1c-syntax/bsl-language-server/blob/develop/src/main/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/CompilationDirectiveLostDiagnostic.java

DiagnosticConfiguration is located here https://github.com/1c-syntax/bsl-language-server/blob/develop/src/main/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/infrastructure/DiagnosticConfiguration.java

It is called from DiagnosticsConfiguration (see s in DiagnosticS) - https://github.com/1c-syntax/bsl-language-server/blob/develop/src/main/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/infrastructure/DiagnosticsConfiguration.java

Main goal of DiagnosticsConfiguration (with s) is to create set of BSLDiagnostic interface implemantaion instances for "DocumentContext" - object (prototype bean also) that represents data of each text document in workspace. Diagnostic are filtred by several conditions -
https://github.com/1c-syntax/bsl-language-server/blob/89c5cc2bcd97e56007d88c5d87a02d65277fb163/src/main/java/com/github/_1c_syntax/bsl/languageserver/diagnostics/infrastructure/DiagnosticsConfiguration.java#L75-L82

These conditions depend on data in DocumentContext, so every DocumentContext gets it's own list of BSLDiagnostic implementation types which are then instantiated via DiagnosticConfiguration (w/o s).

sorry if my explanations seem confusing :(

[nixel2007]

@jhoeller

What kind of cache key is being computed

key is a bean string identifier (camel-cased class name)

[nixel2007]

@jhoeller

Could you please try Framework 5.2.12 / Boot 2.3.7 as well, confirming that you're seeing the same performance difference there?

yes, I see the same regression on Boot 2.3.7.

[nixel2007]

I'd rather recommend a custom lookup method that delegates to ApplicationContext.getBean, with that lookup method not being marked as a managed bean definition itself (given that there is nothing for the container to manage, just unnecessary metadata discovery overhead).

oh yes, it works! I've removed @Bean from diagnostic method and flame graph looks normal now.

Thank you so much! problem is solved and issue can be closed. May be 10bff05 deserves some mention in changelog, migration guide or logs.