Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory Leak In Removing Alias [SPR-17425] #21958

Closed
spring-projects-issues opened this issue Oct 24, 2018 · 3 comments
Closed

Memory Leak In Removing Alias [SPR-17425] #21958

spring-projects-issues opened this issue Oct 24, 2018 · 3 comments
Labels
in: core status: declined

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Oct 24, 2018

JinZhou Huang opened SPR-17425 and commented

In case that there is a bean named A, and it has an alias named B, and B has an alias named C, after alias B was removed through SimpleAliasRegistry#removeAlias(String), the pair B and C is still in the aliasMap of SimpleAliasRegistry. I think it should be considered as a kind of memory leak.


Affects: 5.0.9

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 24, 2018

Juergen Hoeller commented

Another way to see it: The C->B definition is still intact but there is no resolvable reference for B at that point. Whenever a new definition for B comes in, the C->B reference applies again. In that sense, it's a rule that keeps being registered even if it is temporarily inapplicable.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 25, 2018

JinZhou Huang commented

That is exactly a way to see this, since that this case barely happens and the C->B reference could be applied again soon. I just confused when I browsing the code, because that I just have figured out double way to treat it, either remove C->B or make C -> A.

@spring-projects-issues spring-projects-issues added type: bug status: waiting-for-triage in: core and removed type: bug labels Jan 11, 2019
@bclozel
Copy link
Member

@bclozel bclozel commented Feb 18, 2022

Closing per #21958 (comment)

@bclozel bclozel closed this as completed Feb 18, 2022
@bclozel bclozel added status: declined and removed status: waiting-for-triage labels Feb 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: declined
Projects
None yet
Development

No branches or pull requests

2 participants