Non-singleton beans performance issue [SPR-9819]

[spring-projects-issues]

Andriy Rosa opened SPR-9819 and commented

For each method invocation for not-singleton scope bean
Interceptor got bean from bean-factory by using AbstractBeanFactory.getBean

But before getting required bean inside method getBean we have cheeking

Object sharedInstance = getSingleton(beanName);
if (sharedInstance != null && args == null) {

Inside getSingleton we have synchronized blocks.

considering that in high-load project we can have a lot of scoped-beans methods invocations, getSingleton lock all threads, and performance gone to very poor.

I'm not very good in spring-core architecture, however by my mean the most obvious solution - it push into args argument of getBean method specific arg, which will show, that we request not singleton bean for sure

P.S.: Take my apologies for my bad English.

---

Affects: 3.1.1

Issue Links:

• Threads bottlenecking in DefaultSingletonBeanRegistry when using Wicket's @SpringBean annotation for injection [SPR-5360] #10033 Threads bottlenecking in DefaultSingletonBeanRegistry when using Wicket's @SpringBean annotation for injection ("is duplicated by")
• Performance bottleneck and potential thread deadlock in DefaultSingletonBeanRegistry [SPR-8471] #13117 Performance bottleneck and potential thread deadlock in DefaultSingletonBeanRegistry
• AbstractBeanFactory#markBeanAsCreated performance issue due to lock contention [SPR-9780] #14414 AbstractBeanFactory#markBeanAsCreated performance issue due to lock contention
• DefaultSingletonBeanRegistry::getSingleton(String beanName) attempts to create bean when it shouldn't [SPR-10674] #15302 DefaultSingletonBeanRegistry::getSingleton(String beanName) attempts to create bean when it shouldn't
• Further locking optimizations for the retrieval of non-singleton beans [SPR-12250] #16864 Further locking optimizations for the retrieval of non-singleton beans

0 votes, 5 watchers

[spring-projects-issues]

Juergen Hoeller commented

We've addressed this for 3.2 now, avoiding that singletonObjects lock wherever possible (i.e. just doing an efficient ConcurrentHashMap check).

Juergen