Види збирачів сміття в Java

1. Serial GC

Складання сміття підвищує ефективність роботи з пам'яттю в Java, оскільки об'єкти, що не мають посилань, видаляються з купи і звільняється місце для новостворених об'єктів.

Java віртуальна машина має вісім типів збирачів сміття. Розглянемо кожен із них у деталях.

Серійний GC – це найпростіша реалізація GC. Вона призначена для невеликих програм, що працюють в однопотокових середовищах. Усі події збирання сміття виконуються послідовно в одному потоці. Ущільнення виконується після кожного збирання сміття.

Запуск збирача призводить до події “зупинки світу”, коли вся програма припиняє роботу. Оскільки на час складання сміття вся програма заморожується, не слід вдаватися до такого в реальному житті, якщо потрібно, щоб затримки були мінімальними.

Аргумент JVM для використання послідовного збирача сміття -XX:+UseSerialGC.

2. Parallel GC

Паралельний збирач сміття призначений для програм із середніми та великими наборами даних, які виконуються на багатопотоковому або багатопроцесорному устаткуванні. Це реалізація GC за замовчуванням, і вона також відома як збирач пропускної спроможності.

Декілька потоків призначаються для малого складання сміття в молодому поколінні. Єдиний потік зайнятий основним складанням сміття у старшому поколінні.

Запуск паралельного GC також викликає “зупинку світу” і програма зависає. Така поведінка більше підходить для багатопотокового середовища, коли потрібно завершити багато завдань і допустимі тривалі паузи, наприклад при виконанні пакетного завдання.

Аргумент JVM для використання паралельного збирача сміття: -XX:+UseParallelGC.

3. CMS GC

Також відомий нам як паралельний збирач низьких пауз.

Тут для малого складання сміття задіяно кілька потоків: це відбувається через такий самий алгоритм, що і в паралельному збирачі. Основне збирання сміття багатопотокове, як і в старому паралельному GC, але CMS працює одночасно з процесами програм, щоб звести до мінімуму події “зупинки світу”.

Через це збирач CMS споживає більше ресурсів процесора, ніж інші збирачі. Якщо у вас є можливість виділити більше ЦП для підвищення продуктивності, то CMS краще за простий паралельний збирач. CMS GC не виконує ущільнення.

Аргумент JVM для використання паралельного збирача сміття з розгорткою міток: -XX:+UseConcMarkSweepGC.

4. G1 (Garbage first) GC

G1GC розробляли як заміну CMS для багатопотокових додатків, що характеризуються великим розміром купи (більше 4 ГБ). Він паралельний і конкурентний, як CMS, але під капотом працює зовсім інакше, ніж старі збирачі сміття.

Хоча G1 також діє за принципом поколінь, він не має окремих просторів для молодого і старшого поколінь. Натомість кожне покоління являє собою набір областей, що дозволяє гнучко змінювати розмір молодого покоління.

G1 розбиває купу на набір областей однакового розміру (залежно від розміру купи) та сканує їх у кілька потоків. Область під час виконання програми може неодноразово ставати як старою, так і молодою.

Після завершення етапу розмітки G1 знає, в яких областях міститься найбільше сміття. Якщо користувач зацікавлений у мінімізації пауз, G1 може обрати лише кілька областей. Якщо час паузи неважливий для користувача або межа цього часу встановлена висока, G1 пройде по більшій кількості областей.

Оскільки G1 GC ідентифікує регіони з найбільшою кількістю сміття і спочатку виконує збирання сміття в них, він і називається: "Сміття — першим".

Крім областей Едему, що вижили, та Старої пам'яті, в G1GC присутні ще два типи.

• Humongous (Велика) — для об'єктів великого розміру (понад 50% розміру купи).
• Available (Доступна) — простір, що не використовується або не виділений.

Аргумент JVM для використання збирача сміття G1: -XX:+UseG1GC.

5. Shenandoah (Шенандоа)

Shenandoah — новий GC, що вийшов у складі JDK 12. Ключова перевага Shenandoah перед G1 полягає в тому, що більшість циклу складання сміття виконується одночасно з потоками програм. G1 може евакуювати області купи лише тоді, коли програму припинено, а Shenandoah переміщає об'єкти одночасно з додатком.

Shenandoah може компактувати живі об'єкти, очищати сміття та звільняти оперативну пам'ять майже одразу після виявлення вільної пам'яті. Оскільки все це відбувається одночасно, без припинення роботи програми, то Shenandoah більш інтенсивно навантажує процесор.

Аргумент JVM для збирача сміття Шенандоа: -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC.

6. ZGC

ZGC – ще один GC, що вийшов у складі 11 і був покращений у JDK 12.

Він призначений для програм, які вимагають швидкодії та низької затримки (паузи менш ніж 10 мс) та/або задіюють дуже велику купу (кілька терабайт).

Основні цілі ZGC – низька затримка, масштабованість та простота в застосуванні. Для цього він дозволяє Java-програмі продовжувати роботу, незважаючи на те, що виконуються операції зі збирання сміття. За замовчуванням ZGC звільняє пам'ять, що не використовується, і повертає її в операційну систему.

Таким чином, ZGC приносить значне поліпшення порівняно з іншими традиційними GC, забезпечуючи надзвичайно низький час паузи (зазвичай у межах 2 мс).

Аргумент JVM для використання збирача сміття ZGC: -XX:+UnlockExperimentalVMOptions -XX:+UseZGC.