Java 10 сокращает время пауз полного GC за счет итеративного улучшения существующего алгоритма.
-XX:ParallelGCThreads
Насколько я понял, G1 не запускает свои циклы сбора одновременно с нашим приложением. Он по-прежнему будет периодически приостанавливать приложение, а паузы полного GC увеличиваются с увеличением размера кучи.
Тогда как это улучшит производительность? Кто-нибудь может это объяснить?
На самом деле, 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 стал полностью параллельным в полном цикле сборки мусора. В соответствии с JEP 307: Parallel Full GC for G1 это уменьшает задержку в худшем случае:
Сборщик мусора G1 разработан таким образом, чтобы избежать полных сборок, но когда параллельные сборки не могут достаточно быстро освободить память, произойдет возврат к полной сборке мусора. Текущая реализация полного GC для G1 использует однопоточный алгоритм пометки-очистки-уплотнения. Мы намерены распараллелить алгоритм mark-sweep-compact и использовать то же количество потоков, что и в коллекциях Young и Mixed. Количество потоков можно контролировать с помощью параметра -XX:ParallelGCThreads, но это также повлияет на количество потоков, используемых для коллекций Young и Mixed.
