Код, упомянутый в этой статье, взят из примера кода, доступного в блоге Oracle, касающегося Epsilon GC.

В этой статье мы исследуем особенно интригующую опцию сборки мусора Java (GC), известную как Epsilon GC. Этот алгоритм сборки мусора примечателен своей отличительной особенностью: он не выполняет сборку мусора. Сборщик мусора Epsilon (GC) был включен в JDK 11.

Но какой смысл в сборщике мусора, если он не собирает мусор? (халявщик, ха!!)

Нет, на самом деле это весьма полезно, один из таких вариантов использования, представленный в блоге Oracle, который я немного усовершенствовал, чтобы сделать его более полезным.

Для получения более подробной информации обратитесь к оригинальному сообщению в блоге:
https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-do-nothing-garbage-collector

Сценарий использования: Epsilon GC полезен для разработчиков, которым необходимо оценить распределение памяти для определенного сегмента кода без помощи инструмента профилирования.

Основная задача Традиционные сборщики мусора могут скрывать точные показатели использования памяти, постоянно очищая объекты. Это вмешательство затрудняет определение истинного потребления памяти вашим кодом.

Epsilon GC решает эту проблему, выступая в роли неколлектора. Хотя он и не является алгоритмом сборки мусора как таковой, он служит инструментом для понимания распределения памяти, воздерживаясь от выполнения какой-либо сборки мусора, тем самым обеспечивая четкую картину использования памяти.

Примечание: важно помнить, что, поскольку Epsilon GC не освобождает память, чрезмерное выделение может привести к ошибке OutOfMemoryError (OOM) в JVM.

Ниже приведен пример кода, который будет использоваться для демонстрации эффективности Epsilon GC.:

public class EpsilonDemo {

    public static String formatSize(long v) {
        if (v 



Ожидание: 

Код выделяет 80 МБ объектов байтового типа. Мы должны иметь возможность наблюдать то же самое с операторами печати при выполнении кода.

Теперь, чтобы запустить скомпилированную версию с EpsilonGC или без него:

Работа с G1GC:

java -Xms100m -Xmx100m -XX: UseG1GC  EpsilonDemo
Starting allocations...
*** Free MEM = 102.2 MB
Completed successfully
*** Free MEM = 74.2 MB




Итак, с G1GC мы видим неверную картину распределения использования 28 МБ

Работа с EpsilonGC:

java -Xms100m -Xmx100m -XX: UnlockExperimentalVMOptions -XX: UseEpsilonGC EpsilonDemo
[0.004s][warning][gc,init] Consider enabling -XX: AlwaysPreTouch to avoid memory commit hiccups
Starting allocations...
*** Free MEM = 99.4 MB
Completed successfully
*** Free MEM = 18.7 MB 




Здесь хорошо видно использование 80,7 МБ

Надеюсь, это поможет вам понять, насколько EpsilonGC может быть очень удобен для выявления закономерностей использования памяти в вашем коде. Ваше здоровье! ?