-
Notifications
You must be signed in to change notification settings - Fork 145
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
Fixing memoryleak in multiclassloader context #167
base: master
Are you sure you want to change the base?
Conversation
…s sure, it can be collected when multiple classloaders are used.
I have been looking into your code and it is not quite clear to me what problem you are trying to solve. The provided modifications look problematic to me. From the commit history I can see that you also provided fixes for the fixes. So the fix itself caused new problems. |
Sadly I don't know a way, to dynamically create classes during Runtime - then it would be possible to write a unit-test for the leak. The leak is a bit specific because it only happens in an environment where classloaders are created and removed - for example when plugins can be dynamically loaded/unloaded. One Version didn't work, because it's not sufficient to make the HashMaps weak, because the Value also references the Key. Another version had a typo using the wrong HashMap. This version now seems to work and didn't cause any issues. What does the fix do? It basically counts the subscriptions, and if it reaches zero, they are explicitly unsubscribed. |
That is indeed a specific scenario - and very understandable you can't provide a unit test for this. I think that |
Keeping classes keeps the classloaders forever, introducing leaks when the classloader should be collected.