Closed
Description
Juergen Hoeller opened SPR-12404 and commented
Improvements based on this proposal and a few discussions with Phil:
philwebb@8c347e6
On a related but quite different note, we should also avoid synchronization for accessing current bean names. Through managing a dedicated set of manually registered singleton names (which remain stable after the registration phase), we can significantly optimize concurrent access as well as shorten the iteration needed for each autowiring attempt.
Affects: 4.1.1
Issue Links:
- ConcurrentModificationException thrown while iterating over bean definition names in DefaultListableBeanFactory#getBeansWithAnnotation(Class<? extends Annotation> annotationType) [SPR-12688] #17286 ConcurrentModificationException thrown while iterating over bean definition names in DefaultListableBeanFactory#getBeansWithAnnotation(Class<? extends Annotation> annotationType)
- ConcurrentModificationException when executing AutowireCapableBeanFactory.createBean [SPR-13493] #18071 ConcurrentModificationException when executing AutowireCapableBeanFactory.createBean
- ApplicationContext fails to load in TestNG test if previous test is annotated with @DirtiesContext [SPR-12918] #17517 ApplicationContext fails to load in TestNG test if previous test is annotated with
@DirtiesContext - Doc: DefaultListableBeanFactory is not thread-safe for manual singleton registration [SPR-12970] #17562 Doc: DefaultListableBeanFactory is not thread-safe for manual singleton registration
- Restore ability to override bean definition names in DefaultListableBeanFactory subclass [SPR-12667] #17266 Restore ability to override bean definition names in DefaultListableBeanFactory subclass
- Autowiring against a closed ApplicationContext should consistently fail [SPR-12932] #17525 Autowiring against a closed ApplicationContext should consistently fail
- getBeanDefinitionNames should not leak the frozenBeanDefinitionNames array [SPR-14897] #19463 getBeanDefinitionNames should not leak the frozenBeanDefinitionNames array