spring boot(2.0.3.发行版）应用程序中的内存泄漏

Question

我们在一个高负载(6M请求/天）的spring boot应用程序中出现了内存泄漏，它为很少的restendpoint提供服务。old_gen随时间增长缓慢，提交的内存达到容器限制，导致容器摊牌。在采取了几个堆转储后，我能够找出以下几点：

>

org.apache.catalina.webresources.cachedResource使用了大量内存，实例数约为12000，导致包括java.io.file在内的其他对象的数量类似。我尝试禁用tomcat缓存，虽然这些类从堆转储中消失了，但吞吐量不可避免地下降。有什么关于最佳实践的建议吗？

spring执行器也消耗大量内存

null

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
--------------------------------------------------------------------------------------------------------------------------------

null

似乎达到这个程度后就稳定了。但在这种情况下,每个请求中的对象都被替换到数组中。代码（InMemoryAuditEventrePository.java）如下所示，不确定--可能这导致了一些泄漏。

this.events[this.tail] = event;

对此有什么建议吗？禁用spring执行器？

GC路径显示：

null

<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                                                                      |              |              |                   |              
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

null

有线索吗？

null

<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
---------------------------------------------------------------------------

null

有谁能建议一下如何看到这些对象的价值（使用MAT），如何追踪？

还有其他建议吗？

Answer 1

在分析了堆转储之后，是否真的存在任何内存泄漏或者这是JVM的通常行为并不十分明显。我们在oracle jre 8中使用docker映像，它上次更新是在2年前。我们更改为openjdk，现在内存行为似乎更加稳定。