prod中的一个旧的长时间运行的应用程序内存不足。在分析线程转储时,我使用保留大小进行导航,并查找具有大量保留大小的对象,以了解导致内存问题的原因(可能是泄漏,也可能是某个进程中的对象太多)。
在本例中,内存泄漏报告从jetty指向HashedSession。在查看会话时,我可以看到-app中的会话在属性中包含引用周期中相同会话的对象。
现在的问题是,我不能确定保留大小的组成部分(与总保留大小之和),以及它们来自哪里。会话中最大的大小是会话本身,而其他属性几乎没有任何东西。
Class Name | Retained Heap
----------------------------------------------------------------------------------------------------
org.eclipse.jetty.server.session.HashedSession @ 0x77d47bf70 | 201 414 144
|- _attributes java.util.HashMap @ 0x782c20250 | 201 414 056
| |- table java.util.HashMap$Node[16] @ 0x78594db98 | 201 414 008
| | |- [10] java.util.HashMap$Node @ 0x787047090 | 201 411 880
| | | |- value com.vaadin.terminal.gwt.server.WebApplicationContext @ 0x784244740| 201 411 848
| | | | |- session org.eclipse.jetty.server.session.HashedSession @ 0x77d47bf70 | 201 414 144
| | | | |- browser com.vaadin.terminal.gwt.server.WebBrowser @ 0x7832eeb68 | 400
| | | | |- applications java.util.HashSet @ 0x787a9e1a8 | 192
| | | | |- applicationToAjaxAppMgrMap java.util.HashMap @ 0x783280118 | 160
| | | | |- listeners java.util.Collections$SynchronizedList @ 0x787a9e190 | 104
----------------------------------------------------------------------------------------------------我知道我可能在做一些愚蠢的事情,但我认为通过遵循最大的保留大小(或者跳过周期的第二大),我会发现问题的真正坏处。但是我找不到任何具有相似保留大小的其他保留对象集来将我指向下一个可疑对象(除了会话的原始保留大小)。
在Java8、HotSpot JVM上运行
发布于 2019-07-20 05:20:41
是的,你遵循了从HashedSession @ 0x77d47bf70到HashedSession @ 0x77d47bf70的循环引用。但是,您并没有完全查看_attributes HashMap。里面还有什么?
您是否通过右键单击HashedSession @ 0x77d47bf70来使用"List Objects -> on“?
https://stackoverflow.com/questions/55265701
复制相似问题