Related to #12149
RootBeanDefinition members (externallyManagedConfigMember, externallyManagedInitMethods,externallyManagedDestroyMethods) are initialized even if not in use.
Setting ConcurrentHashMap initial size as 0 is not good enough it still allocates a map with ~ 10 empty elements.
Should delay the initialization.
For example -
public void registerExternallyManagedConfigMember(Member configMember) {
if (externallyManagedConfigMembers == null){
externallyManagedConfigMembers = new ConcurrentHashMap<Member, Boolean>(0);
}
this.externallyManagedConfigMembers.put(configMember, Boolean.TRUE);
}
public boolean isExternallyManagedConfigMember(Member configMember) {
if (externallyManagedConfigMembers == null){
return false;
}
return this.externallyManagedConfigMembers.containsKey(configMember);
}
Looking at the current code paths that call those methods, we can conveniently reuse the existing postProcessingLock which will typically be active already when registerExternallyManaged* calls come in from the bean factory's post-processing phase. Since that's a regular synchronized lock, we can also safely lazily initialize regular HashSets for those externallyManaged* holders.
Note that with ConcurrentHashMaps, lazily initializing them introduces a race condition. Simply speaking, ConcurrentHashMaps need to be initialized as final fields, otherwise we'd need some form of synchronization for the lazy creation of each ConcurrentHashMap itself.
AdiB opened SPR-11343 and commented
Related to #12149
RootBeanDefinition members (externallyManagedConfigMember, externallyManagedInitMethods,externallyManagedDestroyMethods) are initialized even if not in use.
Setting ConcurrentHashMap initial size as 0 is not good enough it still allocates a map with ~ 10 empty elements.
Should delay the initialization.
For example -
Affects: 3.2.6, 4.0 GA
Issue Links:
Referenced from: commits d9ab6aa, a599b57
Backported to: 3.2.7
The text was updated successfully, but these errors were encountered: