Skip to content

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

@spring-projects-issues

Description

@spring-projects-issues
Collaborator

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:

Referenced from: commits ac4103d, 9d83281, a1538a4

Backported to: 4.0.8, 3.2.12

Activity

spring-projects-issues

spring-projects-issues commented on Sep 25, 2014

@spring-projects-issues
CollaboratorAuthor

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

spring-projects-issues commented on Oct 6, 2014

@spring-projects-issues
CollaboratorAuthor

Juergen Hoeller commented

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

Juergen

spring-projects-issues

spring-projects-issues commented on Oct 6, 2014

@spring-projects-issues
CollaboratorAuthor

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

spring-projects-issues commented on Oct 6, 2014

@spring-projects-issues
CollaboratorAuthor

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

added
status: backportedAn issue that has been backported to maintenance branches
in: coreIssues in core modules (aop, beans, core, context, expression)
on Jan 11, 2019
added this to the 4.1.2 milestone on Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

in: coreIssues in core modules (aop, beans, core, context, expression)status: backportedAn issue that has been backported to maintenance branchestype: enhancementA general enhancement

Type

No type

Projects

No projects

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @jhoeller@spring-projects-issues

      Issue actions

        Further locking optimizations for the retrieval of non-singleton beans [SPR-12250] · Issue #16864 · spring-projects/spring-framework