С другой стороны Java = объекты. Сборщики мусора стали достаточно умными, чтобы запускаться только тогда, когда памяти не хватает, и достаточно быстро убирать короткоживущихе объекты. Можно выбрать сборщик мусора либо с минимальными паузами, либо с минимальным overhead по ресурсам. Про выбор можно почитать тут https://www.baeldung.com/java-choosing-gc-algorithm Перераспределение памяти по ходу работы программы и роста heap можно убрать установив одинаковые xms и xmx, тогда JRE заберёт эту память из системы «навсегда» при старте приложения. Если на сервере много памяти и вы уверены, что heap-а точно хватит на все время работы программы - есть фейковый GC, который имеет ровно одну фичу - падать когда память кончается) https://openjdk.org/jeps/318 Когда это все не работает - примерно на десятках миллионах RPS как в статье из примера выше) #java #gc #performance

G1 - долгая дорога к покорению мира)

Недавно вышла новая Java - 27-я.
Не LTS, изменений не так много, большая часть - мелкие оптимизации. Скорость работы Java - это понятная боль, не зря же появился тот же Rust. Где, кстати, нет Garbage Collector, но это уже другая история.
Так вот. Одно из значимых изменений 27 версии - G1 стал сборщиком мусора по умолчанию.
...
Так, а раньше разве не он был?

Смотрим историю G1.
Появился в Java 6.
Стал выбором по умолчанию в Java 9.
Но ... не для всех.
А только для серверных окружений. Что под этим понимается?
Не менее 2 ядер и 2 Гб памяти, доступных приложению. Т.к. в условиях ограниченных ресурсов Serial GC был эффективнее.
И вот в новой Java 27, вышедшей в сентябре 2026 года, разработчики допилили G1 настолько, что он включается сейчас по умолчанию для любых окружений.
9 лет прошло.
Такой интересный факт.

А выводы такие.
1) Java - это совместимость, это не быстро, и мы про это знаем)
2) Параметры JVM для высоконагруженных приложений лучше задавать явно. И включать в процедуру НТ.

#java #jdk #gc