SerialOld GC с G1GC

Я считаю, что это операция Full GC в G1. Раньше он был последовательным до JDK 10, теперь он параллельный после интеграции JEP 307. Это также видно по продолжительности этих фаз: почти 4 секунды по сравнению с обычными циклами G1.

См. Источник: G1 Full GC использовалSerialOldTracer для отчетности, теперь он использует G1FullTracer. Таким образом, до JDK 10 он должен был сообщать "SerialOld" для Full GC, теперь он должен сообщать "G1Full".

Как уже было сказано ранее, это связано с полным сборщиком мусора, но для тех, кто не знаком с концепцией, я постараюсь уточнить:

Полный сборщик мусора происходит только в том случае, если G1GC каким-то образом не успевает за ним или что-то / кто-то явно запросил его. Вместо короткой (субсекундной) в основном параллельной сборки мусора у вас теперь есть аварийный откат к классической сборке мусора, которая может занять много секунд (в зависимости от использования кучи).

См. Советы по настройке, например:

Совет по настройке сборщика мусора Oracle Java SE версии 9

Чтобы определить, что вызвало полный сборщик мусора, вы (или кто-либо другой в той же ситуации) можете включить ведение журнала сборщика мусора. (Например: -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:<file-path> до Java 9 и начиная с Java 9: ​​-Xlog:gc*:file=<file-path>). Если вы убедитесь, что журнал GC записывается в быстрое хранилище, см .: https://engineering.linkedin.com/blog/2016/02/eliminating-large-jvm-gc-pauses-caused-by-background-io-traffic