Утечка памяти в jdk1.7.0

Мы пробовали jdk 1.7.0_02. Десять дней работы дают 420 Мб утечки памяти из следующих объектов:
- java.lang.management.MemoryUsage,
- [C (массив символов),
- java.util.HashMap $ запись,
- [Ljava.util.HashMap $ Entry (массив HashMap $ Entry),
и некоторые другие.Утечка памяти в jdk1.7.0

Это не происходит на jdk1.6.x.

Первый выход "jmap -histo: жить" Команда:

num  #instances   #bytes class name 
---------------------------------------------- 
    1:  229527  14926888 [C 
    2:  289290  13885920 java.lang.management.MemoryUsage 
    3:29  10272928 java.util.HashMap$Entry 
    4:   69923  10262184 <constMethodKlass> 
    5:   69923  9527672 <methodKlass> 
    6:   7048  7787040 <constantPoolKlass> 
    7:  241693  7734176 java.lang.String 
    8:   2038  5898408 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry; 
    9:   7048  5479056 <instanceKlassKlass> 
    10:   5954  4499552 <constantPoolCacheKlass> 
    11:   67844  4091672 [Ljava.util.HashMap$Entry; 
    12:   41250  3942848 [B 
    13:   65649  3151152 java.util.HashMap 
    14:   71891  2875640 java.util.TreeMap$Entry 
... 
Total  2320965  138000120

Последний выход "jmap -histo: жить" команда сделано через 10 дней после того, как первый:

num  #instances   #bytes class name 
---------------------------------------------- 
    1:  3147110  151061280 java.lang.management.MemoryUsage 
    2:  3178875  101724000 java.util.HashMap$Entry 
    3:  1087332  53822632 [C 
    4:  1099503  35184096 java.lang.String 
    5:  639442  31529224 [Ljava.util.HashMap$Entry; 
    6:  637247  30587856 java.util.HashMap 
    7:  629422  25176880 [Ljava.lang.management.MemoryUsage; 
    8:  314711  17623816 com.sun.management.GcInfo 
    9:   70107  10292776 <constMethodKlass> 
    10:  631864  10109824 java.util.HashMap$EntrySet 
    11:  314711  10070752 sun.management.GcInfoCompositeData 
    12:   70107  9552696 <methodKlass> 
    13:   7075  7817080 <constantPoolKlass> 
    14:  314713  7554128 [Ljava.lang.Integer; 
    15:   2048  5898744 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry; 
    16:   7075  5497200 <instanceKlassKlass> 
    17:  315792  5052672 java.lang.Integer 
    18:   47680  4912352 [B 
... 
Total  13206419  558217856

У меня также есть 8 других гистограмм, сделанных после каждого дня тестов. Они показывают линейное число объектов. Это определенно не шум. Это стабильная утечка 42 МБ в день.

Вы наблюдали подобное поведение? В каких сценариях? Как вы справились с этим?

источник

2011-12-19 Neighbour

Что вы хотите сказать? – tobiasbayer

-1 Нет вопросов; если это сообщение об ошибке: свяжитесь с Oracle. –

@CodeBrickie, вопрос: наблюдали ли вы подобное поведение? В каких сценариях? Как вы справились с этим? – Neighbour

Учитывая, что код в Java 7 немного отличается (но почти такой же), как Java 6. Я ожидаю увидеть эти очень тонкие различия. Я бы сделал снимок через два дня, чтобы увидеть, продолжает ли JVM прогреваться. Подключение большего количества клиентов мониторинга могло бы увеличить эти значения (например, в основном это объекты мониторинга).

Если это утечка памяти, при 32 К каждые два дня, это может растрачивать ~ 5 МБ после года работы и стоит менее 5 центов. Лично я считаю, что это слишком мало, чтобы беспокоиться.

источник

2011-12-19 08:50:11

Действительно, разница между числами настолько мала, что ее можно рассматривать как шум (возможно, временные объекты в определенный момент времени). Цифры вряд ли подтверждают, что существует утечка памяти. – Jesper

@ Jesper Я подозреваю, что вы правы, поэтому потребуется больше образцов (каждая неделя может быть), если вы считаете, что это стоит того. –

@Peter Lawrey, есть ошибка. В настоящее время интервал между двумя гистограммами выше составляет 10 минут, а не 2 дня. В скором времени я дам количество гистограмм с действительно большим интервалом. – Neighbour

Утечка памяти в jdk1.7.0

ответ

Смежные вопросы