Comments 10
мы выбираем наименее худшее решение
к сожалению, вы и близко не представляете НАСКОЛЬКО все плохо!
our methodology estimates that by using GC, applications spend 7–82% more wall-clock time and 6–92% more CPU cycles relative to their intrinsic costs
https://www.linkedin.com/pulse/how-java-garbage-collection-works-sergey-derevyago-af84f
"80% more" - вдумайтесь!!
Лучше использовать 17 версию, так как в ней сделали так, чтобы java отдавала обратно в ОС неиспользуемую память. Траты на простаивающие приложения уменьшатся.
Вы всерьёз сидите на древнем, не поддерживаемом релизе 12, или он упомянут только как веха в истории с N штуками GC?
Скорее N-2, т.к. CMS уже выпилили в новой версии, а Epsilon никогда не был сборщиком мусора (это заглушка которая ничего не собирает и нужна только для тестов). По ощущениям Oracle всеми силами пытается придушить Shenandoah (в пользу перехода на ZGC), возможно Шипилев еще продержится пару LTS релизов и забьет на это дело. В статье кстати не указано что ZGC перешел на generation режим по умолчанию (который приехал из Amazon), а раньше он коммитил х3 виртуальной памяти и им невозможно было нормально пользоваться.
JDK12 упомянут в порядке ретроспективы, как версия, в которой впервые появилось 7 сборщиков. На проекте, который вдохновил статью используется JDK17.
Добавлю вот только отличное видео Алексея Шипилёва про Shenandoah.
Вас благодарю за отличную статью! Быстро и по сути прошлись по теме.
Java Highload и сборка мусора