Повідомлення журналу збору сміття Java

Я налаштував java на скидання інформації про збір сміття до журналів ( детальний GC ). Я не впевнений, що означають записи збору сміття в журналах. Зразок цих записів розміщений нижче. Я шукав у Google і не знайшов вагомих пояснень.

Я маю кілька обґрунтованих здогадок, але я шукаю відповіді, які дають чіткі визначення того, що означають цифри в записах, підкріплені надійними джерелами. Автоматичний +1 до всіх відповідей, в яких цитується документація про сонце. Мої запитання:

1. До чого відноситься PSYoungGen? Я припускаю, що це пов’язано з попереднім (молодшим?) Поколінням, але що саме?
2. У чому різниця між другим триплетом чисел і першим?
3. Чому ім'я (PSYoungGen) вказано для першого триплета чисел, а не для другого?
4. Що означає кожне число (обсяг пам'яті) у триплеті. Наприклад, у 109884K-> 14201K (139904K), це пам'ять до GC 109884k, а потім вона зменшується до 14201K. Яке значення має третє число? Чому нам потрібен другий набір чисел?

8109.128: [GC [PSYoungGen: 109884K-> 14201K (139904K)] 691015K-> 595332K (1119040K), 0.0454530 секунд]

8112.111: [GC [PSYoungGen: 126649K-> 15528K (142336K)] 707780K-> 605892K (1121472K), 0,0934560 секунд]

8112.802: [GC [PSYoungGen: 130344K-> 3732K (118592K)] 720708K-> 607895K (1097728K), 0,0682690 секунд]

Більшість з них пояснюється в Посібнику з налаштування GC (який вам все одно було б добре прочитати).

Параметр командного рядка дає -verbose:gcзмогу друкувати інформацію про купу та збір сміття в кожній колекції. Наприклад, ось висновок із великого серверного додатка:

[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

Тут ми бачимо дві незначні колекції, за якими йде одна велика колекція. Цифри перед стрілкою та після неї (наприклад,325407K->83000K з першого рядка) вказують на сумісний розмір живих об'єктів до і після збору сміття відповідно. Після незначних колекцій розмір включає деякі об'єкти, які є сміттям (більше не в живих), але які неможливо відновити. Ці об'єкти містяться або в генераційному режимі, або на них посилаються ті чи інші покоління.

Наступне число в дужках (наприклад, (776768K)знову з першого рядка) - це дозволений розмір купи: кількість простору, що можна використовувати для об’єктів java, не вимагаючи більше оперативної пам’яті. Зауважте, що це число не включає один з просторів, що залишилися в живих, оскільки лише один може бути використаний у будь-який момент часу, а також не включає постійне покоління, яке містить метадані, використовувані віртуальною машиною.

Останній елемент у рядку (наприклад, 0.2300771 secs) вказує час, необхідний для виконання збору; в цьому випадку приблизно чверть секунди.

Формат основної колекції в третьому рядку аналогічний.

Формат випуску, що виробляється, -verbose:gcможе змінюватися в наступних випусках.

Я не впевнений, чому у вас є PSYoungGen; ти міняв збирач сміття?

1. PSYoungGen відноситься до сміттєзбірника, який використовується для мінорного збору. PS означає паралельне відлякування.
2. Перший набір чисел - це розміри до / після молодого покоління, а другий набір призначений для всієї купи. ( Діагностування проблеми зі збиранням сміття детально визначає формат)
3. Назва вказує на покоління та колектор, про який йде мова, другий набір призначений для всієї купи.

Приклад пов'язаного повного GC також показує колектори, що використовуються для старого та постійного поколінь:

3.757: [Full GC [PSYoungGen: 2672K->0K(35584K)] 
            [ParOldGen: 3225K->5735K(43712K)] 5898K->5735K(79296K) 
            [PSPermGen: 13533K->13516K(27584K)], 0.0860402 secs]

Нарешті, розбиваючи один рядок вашого прикладу журналу:

8109.128: [GC [PSYoungGen: 109884K->14201K(139904K)] 691015K->595332K(1119040K), 0.0454530 secs]

• 107 Мб використано до GC, 14 Мб використано після GC, макс. Розмір молодого покоління 137 Мб
• Купа 675 Мб, що використовується до GC, 581 Мб купи, використані після GC, максимум розміру 1 Гбіт купи
• незначний GC відбувся 8109,128 секунди з моменту запуску JVM і зайняв 0,04 секунди

Я просто хотів зазначити, що детальний журнал GC можна отримати за допомогою

-XX:+PrintGCDetails 

параметр. Тоді ви бачите висновок PSYoungGen або PSPermGen, як у відповіді.

Також, -Xloggc:gc.logздається, генерується такий же вихід, як, -verbose:gcале ви можете вказати вихідний файл у першому.

Приклад використання:

java -Xloggc:./memory.log -XX:+PrintGCDetails Memory

Для кращої візуалізації даних ви можете спробувати gcviewer (останню версію можна знайти на github ).

Будьте уважні, щоб правильно писати параметри, я забув "+", і мій JBoss не запускався без повідомлення про помилку!