Inconsistent hashCode/equals implementation in AbstractPointcutAdvisor results in CGLIB-related memory leak [SPR-12556]

[spring-projects-issues]

Victor Bronstein opened SPR-12556 and commented

I suspect this is the reason for a CGLIB-related memory leak I see (resembling very close #12663), but the issue is so complicated I'm not sure.
We are creating and destroying a Spring context having a JPA entity. What we see in the dump is an instance of AdvisedSupport per context ever created, referenced by CglibAopProxy$ProxyCallbackFilter referenced by CGLIB EnhancerKey (having the matching number of instances). The EnhancerKeys are all different because the Filters are different and these are different because they have a PersistenceExceptionTranslationAdvisor whose instances are compared by advice and pointcut. The advice is PersistenceExceptionTranslationInterceptor which doesn't override equals so all instances are different.
Now judging by the hashmap structure, the hashkey of them all seem to be the same which further strengthens my hypothesis.
I couldn't tell whether the approach of hashCode or the approach of equals is correct but they are not consistent. If we take the approach of hashCode, all instances of AbstractPointcutAdvisor would be the same. However if equals implementation is the correct one, the result is a memory leak because of the advisors being referenced by CglibAopProxy$ProxyCallbackFilter instances which are strongly referenced by the CGLIB cache.

---

Affects: 3.2.12, 4.1.3

Issue Links:

• @Async with cglib based proxy causes memory leak in heap [SPR-11275] #15899 @Async with cglib based proxy causes memory leak in heap ("duplicates")
• MemoryLeak in Cglib2AopProxy.ProxyCallbackFilter [SPR-8008] #12663 MemoryLeak in Cglib2AopProxy.ProxyCallbackFilter

[spring-projects-issues]

Victor Bronstein commented

Please close this one, a more thorough investigation proved it to be the same issue as #15899.
Sorry about the fuss!

[spring-projects-issues]

Sébastien Deleuze commented

Hi Victor Bronstein, could you confirm that 3.2.12 and 4.1.3 are not affected by this issue (since #15899 has been fixed in 3.2.7 and 4.0.1) ?