Spring Boot（2.0.3.RELEASE）應用程序中的內存泄漏

Question

我們在高負載（每天6m req / day）的Spring Boot應用程序中發生內存泄漏，只為少數幾個端點提供服務。 old_gen隨時間增長緩慢，並且已提交的內存達到容器限制，從而導致容器攤牌。 經過幾次堆轉儲后，我能夠找到以下內容：

1. org.apache.catalina.webresources.CachedResource使用了大量的內存，實例計數大約為12000，導致其他數量的對象（包括java.io.File）也差不多。 我嘗試禁用tomcat緩存，盡管這些類已從heapdump中刪除，但吞吐量不可避免地降低了。 對最佳做法有何建議？

2. 彈簧執行器還占用大量內存

 Class Name | Objects | Shallow Heap | Retained Heap -------------------------------------------------------------------------------------------------------------------------------- org.springframework.boot.actuate.audit.InMemoryAuditEventRepository | 1 | 24 | >= 5,670,928 org.springframework.boot.actuate.audit.AuditEvent[] | 1 | 4,016 | >= 5,670,880 org.springframework.boot.actuate.audit.AuditEvent | 1,000 | 32,000 | >= 5,666,416 org.springframework.security.oauth2.provider.authentication.OAuth2AuthenticationDetails| 1,000 | 40,000 | >= 5,319,552 -------------------------------------------------------------------------------------------------------------------------------- 

達到此水平后似乎穩定。 但是在那種情況下，對於每個請求，對象都會在數組中被替換。 代碼（InMemoryAuditEventRepository.java）如下所示，不確定-可能會導致一些泄漏。

this.events[this.tail] = event;

有什么建議嗎？ 禁用彈簧執行器？

3. 此類的17670個實例：org.springframework.security.access.method.DelegatingMethodSecurityMetadataSource $ DefaultCacheKey。 也像上課一樣穩定。 似乎與緩存有關。
4. com.mysql.jdbc.ConnectionPropertiesImpl $ BooleanConnectionProperty的20000個實例！

GC的路徑顯示：

 <pre> Class Name | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- org.apache.tomcat.util.net.NioBlockingSelector$BlockPoller @ 0xcadf60f8 NioBlockingSelector.BlockPoller-1 Thread| 16,884 | 136 | 1,080,576 | 920 '- contextClassLoader org.springframework.boot.loader.LaunchedURLClassLoader @ 0xc8018578 | 16,884 | 80 | 1,080,576 | 4,333,096 '- classes java.util.Vector @ 0xc82b5c90 | 16,884 | 32 | 1,080,576 | 2,706,712 '- elementData java.lang.Object[20480] @ 0xca1a5dd0 | 16,884 | 81,936 | 1,080,576 | 2,706,680 '- [7996] class com.mysql.jdbc.NonRegisteringDriver @ 0xc9b94bd8 | 16,884 | 112 | 1,080,576 | 7,272 '- connectionPhantomRefs java.util.concurrent.ConcurrentHashMap @ 0xc9b94ed8 | 16,884 | 64 | 1,080,576 | 6,528 '- table java.util.concurrent.ConcurrentHashMap$Node[256] @ 0xcc905b78 | 16,884 | 1,040 | 1,080,576 | 6,464 |- [15] java.util.concurrent.ConcurrentHashMap$Node @ 0xcc963078 | 504 | 32 | 32,256 | 128 | '- val, key com.mysql.jdbc.NonRegisteringDriver$ConnectionPhantomReference @ 0xcbfa3840 | 504 | 32 | 32,256 | 48,504 | |- discovered com.mysql.jdbc.NonRegisteringDriver$ConnectionPhantomReference @ 0xcbb4ec50| 378 | 32 | 24,192 | 48,504 | |- referent com.mysql.jdbc.JDBC4Connection @ 0xcc080018 | 126 | 1,232 | 8,064 | 32,024 | '- Total: 2 entries | | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 

有什么線索嗎？

5. 堆轉儲還顯示了一些無法訪問的對象。 計數128,249消耗7MB，主要是：

 <pre> Class Name | Objects | Shallow Heap --------------------------------------------------------------------------- char[] | 21,936 | 1,988,712 int[] | 13,191 | 1,913,760 java.lang.Object[] | 12,230 | 652,176 java.lang.String | 21,936 | 526,464 java.lang.reflect.Method | 2,994 | 263,472 java.lang.ref.SoftReference | 4,051 | 162,040 java.util.LinkedHashMap$Entry | 3,873 | 154,920 java.util.HashMap$Node[] | 2,470 | 142,784 java.util.LinkedHashMap | 2,314 | 129,584 java.lang.reflect.Constructor | 1,133 | 90,640 sun.reflect.generics.tree.SimpleClassTypeSignature| 2,776 | 66,624 java.util.ArrayList | 2,735 | 65,640 --------------------------------------------------------------------------- 

誰能提出建議（使用MAT）如何查看這些對象的值，如何進行追蹤？

還有其他建議嗎？

Answer 1

在分析了堆轉儲之后，如果實際上有任何內存泄漏或者這是JVM的通常行為，則不是很明顯。 我們將docker image與oracle jre 8一起使用，該鏡像最近更新於2年前。 我們更改為openjdk，現在內存行為似乎更加穩定。