Further locking optimizations for the retrieval of non-singleton beans [SPR-12250]

[spring-projects-issues]

Juergen Hoeller opened SPR-12250 and commented

The current BeanFactory.getBean algorithm is optimized towards singleton access, always checking the singleton map for a quick check before proceeding with scope handling.

Lock-free access to non-singleton beans is equally important and seems to be easy enough to achieve: through a check on registered singleton names before going into the lock on the singleton map.

---

Affects: 3.2.11, 4.0.7, 4.1 GA

Issue Links:

• AbstractBeanFactory#markBeanAsCreated performance issue due to lock contention [SPR-9780] #14414 AbstractBeanFactory#markBeanAsCreated performance issue due to lock contention
• Non-singleton beans performance issue [SPR-9819] #14452 Non-singleton beans performance issue

Referenced from: commits ac4103d, 9d83281, a1538a4

Backported to: 4.0.8, 3.2.12

[spring-projects-issues]

Juergen Hoeller commented

In fact, after #14452, all that we still do is a quick check on the "singletonObjects" ConcurrentHashMap and an equally efficient "isSingletonCurrentlyInCreation" check, against a ConcurrentHashMap as well, both with plain bean name String keys. This is very efficient and hard to beat with any singleton names check on an additional data structure.

Let's use this issue as an opportunity for comments towards further improvements, if there are any ideas.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

As discussed in #14414, we should be able to optimize markBeanAsCreated performance through the use of putIfAbsent.

Juergen

[spring-projects-issues]

Bernhard Frauendienst commented

Unfortunately putIfAbsent is not optimized that way, it will also lock the segment (note the synchronized block in ConcurrentHashMap.java:1027 and the onlyIfAbsent check in ConcurrentHashMap.java:1037).

AFAICT the only way to reduce lock contention would be to do a get/containsKey beforehand and return early if it returns true. This creates the possibility of a race condition in which multiple threads actually put the value in the map, but this does not change semantics and is still an improvement to the current situation wrt lock contention.

[spring-projects-issues]

Juergen Hoeller commented

Good point. Addressed this through an explicit contains check before the add call now - for AbstractBeanFactory.alreadyCreated as well as AbstractAutoProxyCreator.earlyProxyReferences.

Juergen