«1. Введение

В Java 11 появился No-Op сборщик мусора под названием Epsilon, который обещает минимальные накладные расходы на сборку мусора.

В этом коротком руководстве мы рассмотрим, как работает Epsilon, и упомянем распространенные варианты использования.

2. Быстрый практический опыт

Давайте начнем с того, что запачкаем руки и попробуем Epsilon GC!

Сначала нам понадобится приложение, создающее мусор: 

class MemoryPolluter {

    static final int MEGABYTE_IN_BYTES = 1024 * 1024;
    static final int ITERATION_COUNT = 1024 * 10;

    static void main(String[] args) {
        System.out.println("Starting pollution");

        for (int i = 0; i < ITERATION_COUNT; i++) {
            byte[] array = new byte[MEGABYTE_IN_BYTES];
        }

        System.out.println("Terminating");
    }
}

Этот код создает в цикле одномегабайтные массивы. Поскольку мы повторяем цикл 10240 раз, это означает, что мы выделяем 10 гигабайт памяти, что, вероятно, больше, чем доступный максимальный размер кучи.

Мы также предоставили несколько вспомогательных отпечатков, чтобы увидеть, когда приложение завершает работу.

Чтобы включить Epsilon GC, нам нужно передать следующие аргументы VM: 

-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC

И когда мы запускаем приложение, мы получаем следующую ошибку: 

Starting pollution
Terminating due to java.lang.OutOfMemoryError: Java heap space

Однако, когда мы запускаем то же приложение со стандартными параметрами VM он завершается нормально: 

Starting pollution
Terminating

Почему первый запуск не удался? Кажется, что даже самые простые сборщики мусора могут очистить детскую игру, которую мы только что продемонстрировали!

Итак, давайте взглянем на концепции Epsilon GC, чтобы понять, что только что произошло.

3. Как работает Epsilon GC

Epsilon — сборщик мусора без операций.

JEP 318 поясняет, что «[Epsilon]… обрабатывает выделение памяти, но не реализует никакого фактического механизма освобождения памяти. Как только доступная куча Java будет исчерпана, JVM завершит работу».

Таким образом, это объясняет, почему наше приложение завершилось с ошибкой OutOfMemoryError.

Но возникает вопрос: зачем нам сборщик мусора, который не собирает никакого мусора?

В некоторых случаях мы знаем, что доступной кучи будет достаточно, поэтому мы не хотим, чтобы JVM использовала ресурсы для выполнения задач GC.

Некоторые примеры таких случаев (также из связанного JEP):

    Тестирование производительности Тестирование нехватки памяти Тестирование интерфейса ВМ Чрезвычайно короткоживущие задания Улучшение задержки последнего сброса Улучшение пропускной способности последнего сброса

4. Заключение

В этой короткой статье мы узнали об Epsilon, автономном сборщике мусора, доступном в Java 11. Мы узнали о последствиях его использования и рассмотрели некоторые случаи, когда он может быть полезен.

Как обычно, примеры доступны на GitHub.