Утечка памяти в загрузочном приложении Spring (2.0.3.RELEASE)

Question

У нас утечка памяти в приложении Spring при высокой нагрузке (6 млн. Запросов в день), обслуживающем несколько конечных точек отдыха. 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. 20000 экземпляров com.mysql.jdbc.ConnectionPropertiesImpl $ BooleanConnectionProperty!

Путь к 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. Heapdump также показывает некоторые недоступные объекты. Подсчитайте 128 249, потребляющих 7 МБ, основные из которых:

<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

После анализа heapdumps не совсем очевидно, есть ли на самом деле какая-либо утечка памяти или это обычное поведение JVM. Мы использовали образ докера с oracle jre 8, который последний раз обновлялся 2 года назад. Мы перешли на openjdk, и теперь поведение памяти кажется гораздо более стабильным.