Почему рекомендуется Java 10, если вы используете G1 GC? - PullRequest
0 голосов
/ 25 декабря 2018

Java 10 сокращает время полной GC-паузы за счет итеративного улучшения существующего алгоритма.

-XX:ParallelGCThreads

Как я понял, G1 не запускает циклы сбора данных одновременно с нашим приложением.Это по-прежнему будет периодически приостанавливать приложение, и при увеличении размера кучи паузы Full GC увеличиваются.

Тогда как это улучшает производительность?Кто-нибудь может объяснить это?

Ответы [ 2 ]

0 голосов
/ 22 января 2019

На самом деле, 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 из-за упомянутых конкретных изменений), с очень уменьшенным объемом памяти.

0 голосов
/ 25 декабря 2018

Потому что только в Java 10 G1GC стал полностью параллельным в цикле полной остановки GC.В соответствии с JEP 307: параллельный полный GC для G1 это улучшает задержку в худшем случае:

Сборщик мусора G1 предназначен для избежания полных сборок, но при одновременном одновременномколлекции не могут восстановить память достаточно быстро, произойдет полное восстановление GC.Текущая реализация полного GC для G1 использует однопоточный алгоритм mark-sweep-compact.Мы намерены распараллелить алгоритм mark-sweep-compact и использовать то же количество потоков, что и в коллекциях Young и Mixed.Количество потоков можно контролировать с помощью параметра -XX: ParallelGCThreads, но это также повлияет на число потоков, используемых для коллекций Young и Mixed.

...