Почему рекомендуется Java 10, если вы используете G1 GC?
Java 10 сокращает время полной GC-паузы, итеративно улучшая существующий алгоритм.
-XX:ParallelGCThreads
Как я понял, G1 не запускает циклы сбора одновременно с нашим приложением. Это по-прежнему будет периодически приостанавливать приложение, и при увеличении размера кучи паузы Full GC увеличиваются.
Тогда как это улучшить производительность? Кто-нибудь может объяснить это?
2 ответа
Фактически, Java 11 рекомендуется, если вы используете G1GC, потому что было проделано немало работ, чтобы уменьшить его занимаемую площадь и снизить паузы по сравнению с 10.
В списке рассылки hotspot-gc-use было сделано краткое описание различных улучшений, сделанных в 11, 10 и 9 для G1GC, вы можете найти их по этой ссылке: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2018-June/002759.html
Краткое резюме из этого поста в списке:
[...] Я хотел бы отметить, что в целом, с G1, по сравнению с JDK8, можно получить на 60% меньшее время паузы "бесплатно" на процессорах x64 (вероятно, больше на ARM/PPC из-за упомянутых конкретных изменений) на сильно уменьшенном следе памяти.
Потому что только в Java 10 G1GC стал полностью параллельным в цикле полной остановки GC. Согласно JEP 307: Parallel Full GC для G1 это улучшает задержку сценария наихудшего случая:
Сборщик мусора G1 предназначен для того, чтобы избежать полных сборок, но когда одновременные сборки не могут восстановить память достаточно быстро, произойдет возврат полного GC. Текущая реализация полного GC для G1 использует однопоточный алгоритм mark-sweep-compact. Мы намерены распараллелить алгоритм mark-sweep-compact и использовать то же количество потоков, что и в коллекциях Young и Mixed. Количество потоков можно контролировать с помощью параметра -XX:ParallelGCThreads, но это также влияет на количество потоков, используемых для коллекций Young и Mixed.