Sam Brannen opened SPR-11420 and commented

Status Quo

The overloaded flag in MethodOverride is a mutable property that is only intended to be used "to optimize runtime performance" (from the Javadoc), specifically limited to the implementation of ReplaceOverride.matches().

The overloaded flag is, however, currently used to determine equality of and calculate hash codes for MethodOverride instances.

Its value is potentially changed from true (the default) to false in AbstractBeanDefinition.validate(). As a consequence, given two bean definitions A and B that represent the exact same bean definition metadata for a bean that relies on method injection (perhaps loaded via separate application contexts in the same VM), if A has been validated and B has not, then A.equals(B) will potentially return false, which is not acceptable behavior.

Note that AbstractBeanDefinition.equals() includes an equality check for MethodOverrides.

Deliverables

  1. [x] Stop including the overloaded flag in equals() and hashCode() for MethodOverride.

Affects: 3.0 GA

Issue Links: - #15411 Method injection causes memory leak ("is depended on by") - #15411 Method injection causes memory leak

Backported to: 3.2.8

Comment From: spring-projects-issues

Sam Brannen commented

Fixed as described in the comments for GitHub commits 9534245 (4.0.2) and 9f77ef4 (3.2.8):

Exclude overloaded from equals & hashCode in MethodOverride

Prior to this commit, the inclusion of the 'overloaded' flag in the implementations of equals() and hashCode() in MethodOverride could lead to adverse effects in the outcome of equals() in AbstractBeanDefinition.

For example, given two bean definitions A and B that represent the exact same bean definition metadata for a bean that relies on method injection, if A has been validated and B has not, then A.equals(B) will potentially return false, which is not acceptable behavior.

This commit addresses this issue by removing the 'overloaded' flag from the implementations of equals() and hashCode() for MethodOverride.

Comment From: spring-projects-issues

Sam Brannen commented

Changed priority to major since it has been determined that this bug was actually the cause of the memory leak for method injected beans (see #15411).