Architect opened SPR-9842 and commented
My project using spring version 3.0.5 and i can see huge memory leakage in DefaultListableBeanFactory. We are not using any ConcurrentHashMap, But it looks like spring defaultListableBeanFactory using internally and is not getting garbage collected
Please let me know, how to fix this issue and it would be really helpful
Affects: 3.0.5, 3.2.13
Attachments: - mat_spring_version_4_1_2.jpg (243.02 kB) - memory lekage.jpg (19.66 kB)
8 votes, 11 watchers
Comment From: spring-projects-issues
Leela commented
seems like the inputstream in detectValidationMode method of org.springframework.beans.factory.xml.XmlBeanDefinitionReader is not being closed.
Comment From: spring-projects-issues
Guru commented
Hi, We are using springs 3.0.5 and we are due to upgrade to 3.2.x versions in our high performance applications, but while profiling saw that big objects list contains mainly DefaultListableBeanFactory," which version of springs will remove this issue ". as there is huge memory occupied by this class for each bean creation.
thanks for your support
Comment From: spring-projects-issues
John Lawrence Dowson commented
Hi,
I am also experiencing this issue, using the spring 3.2.13 release. Currently leaking about 100MB/hour. Eclipse memory analyser (MAT) shows almost all memory held by DefaultListableBeanFactory
Thanks.
Comment From: spring-projects-issues
Juergen Hoeller commented
Any hint where exactly the data structures keep piling up within DefaultListableBeanFactory?
I'd be happy to fix this for 3.2.14, but I'm afraid we just don't how those conditions arise. I could imagine caches for generated classes etc, with something leaking in the reuse of those classes... That's just a wild guess though. We've been fixing several such issues over the years, so I'm wondering what specifically is left to address here. Also, we haven't had any such reports against 4.x yet, so it might be a 3.x specific issue.
Juergen
Comment From: spring-projects-issues
John Lawrence Dowson commented
As you have added a fix for this for 4.1.6, does this mean that you have found the issue and that it is also present in the 4.x release branch?
I did investigated a bit further and found that, in my case, the memory was mostly being held by 1. beans relating to quartz jobs 2. beans held in a list (in a bean)
Issue 1 seemed to be due to the hibernate first level cache, and I have updated to close the session correctly and clear the cache. Still not sure what is causing issue 2. For now, I have upgraded to Spring 4.1.4. The release containing these changes is out on UAT at the moment, but I won't be able to confirm these changes have solved our memory issues until this goes out to our production environment (as even our load tests don't seem to pick up this leak).
Thanks,
John
Comment From: spring-projects-issues
Juergen Hoeller commented
No, there is no known issue in 4.x yet. I've only scheduled this one for 4.1.6 based on a vague assumption that it might also apply there.
Thanks for your feedback, in any case. I've seen such memory leaks as well but as you pointed out, not actually caused by the Spring core container.
I'd be happy to tweak the core container towards better memory usage in the 4.1.6 / 3.2.14 timeframe. However, at this point, it just remains unclear how we could actually optimize it.
Juergen
Comment From: spring-projects-issues
John Lawrence Dowson commented
Thanks for the update. However, I think that our domain objects referenced from the DefaultListableBeanFactory (the ones held in the list) are caused by the Spring core container as these are injected beans. This leak also first appeared after we upgraded from the 2.5.x release to 3.x, although I guess this could be due to some updates in our code base in the same release. I will report back and let you know if I still have the same problem in the 4.x branch when I have more info, and will delve deeper with MAT when I have time.
John.
Comment From: spring-projects-issues
jialechan commented
In my case, as shown in the accessory, DefaultListableBeanFactory takes up a lot of memory.
My spring version is 4.1.2.
Comment From: spring-projects-issues
John Lawrence Dowson commented
This is no longer a problem for me after upgrading to the 4.1.4 release (and fixing a hibernate 1st level cache leak related to Quartz, as previously mentioned). The memory usage profile of the app has changed quite a bit: I have had to increase the PermGen size from 128MB to 384MB and its used size oscillates between 100MB and the max, whereas previously it was pretty static at around 100MB. I have also been able to reduce the heap size from 6GB down to 4GB, and the used size now oscillates between 200MB and 2.5GB. The application has now been running for 7 days without any issues, whereas previously it would require a daily restart.
John
Comment From: hassibnkhoury
so what is the solution? i am using the latest version of spring boot 3.2.1 and still the issue of memory appears: One instance of “org.springframework.beans.factory.support.DefaultListableBeanFactory” loaded by “org.springframework.boot.loader.launch.LaunchedClassLoader @ 0xf006e300” occupies 1,025,792 (11.57%) bytes. The memory is accumulated in one instance of “org.springframework.beans.factory.support.DefaultListableBeanFactory”, loaded by “org.springframework.boot.loader.launch.LaunchedClassLoader @ 0xf006e300”, which occupies 1,025,792 (11.57%) bytes.
Keywords org.springframework.beans.factory.support.DefaultListableBeanFactory org.springframework.boot.loader.launch.LaunchedClassLoader