Sorry to bother you, I mentioned this issue a few days ago, but it was closed by you without an explanation at that time. I think it is necessary to explain to you again that the configurationClasses container does have data that should not exist. Through my modification, the existing functions will not be damaged after testing, and it is indeed helpful to read the source code.
Comment From: Evanhelovex
configurationClasses contains mainly for processing here (org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader#loadBeanDefinitions), the components scanned by @CoponentScan have been registered with the BeanDefinitionRegistry (org.springframework.context.annotation.ComponentScanAnnotationParser#parse
), so these components should not exist in the configurationClasses container.
Comment From: snicoll
Duplicate of #28072
@Evanhelovex As I've tried to indicate on several occasions, there is nothing in your report that I think it worth pursuing. Sharing a code snippet and screenshots is not how we determine that a change in the core container should be made. Rather, you should provide a sample that showcases a problem (a unit test) or a benchmark that reproduces the memory leak you're claiming.
Also, the configurationClasses map is used to validate configuration classes down the road and this has nothing to do with the bean registry.
Comment From: Evanhelovex
Thanks a lot for your answer, I see.