Caching of autowire candidate metadata for lazy beans #24904
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
status: backported
An issue that has been backported to maintenance branches
type: enhancement
A general enhancement
Milestone
Affects: \5.1.10.RELEASE
Ran into a performance regression when some of the beans in my application were lazified.
Running this with Spring
5.1.10.RELEASE
.The hotspot was identified to be the synchronized lock taken in
SimpleAliasRegistry::getAliases
.See stack trace
The issue appears to be coming from the synchronized block in the following code.
Since there is a single bean factory instance, the contention makes sense to me.
However looking further down in the stack trace, I see
findAutowireCandidates
being called.The above stack frame can be seen for every invocation of a method on the several beans that were lazified.
I was hoping this gets cached the first time the resolution was needed and then it is a simple method indirection but that doesn't seem to be the case.
When I benchmarked,
findAutowireCandidates
took between 30-100 microseconds with ~50 invocations total per second on the various beans that has caused the regression.Is this a bug?
Wondering if there is a better approach to caching the candidates so that the lookup cost in not incurred for each invocation. This overhead is only seen for Lazy beans.
What possible solution(s) could be used to address the regression caused by making beans lazy?
The text was updated successfully, but these errors were encountered: