Последовательный сборщик мусора Java работает намного лучше, чем другие сборщики мусора?

Я тестирую API, написанный на Java, который, как ожидается, минимизирует задержку при обработке сообщений, полученных по сети. Для достижения этих целей я экспериментирую с различными доступными сборщиками мусора.

Я пробую четыре разных метода, которые используют следующие флаги для управления сборкой мусора:

1) Последовательный: -XX:+UseSerialGC

2) Параллельный: -XX:+UseParallelOldGC

3) Параллельный: -XX:+UseConcMarkSweepGC

4) Параллельный/инкрементный: -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing

Я запускал каждый метод в течение пяти часов. Я периодически использовал список GarbageCollectorMXBean, предоставленный ManagementFactory.getGarbageCollectorMXBeans(), чтобы получить общее время, затраченное на сбор мусора.

Мои результаты? Обратите внимание, что «задержка» здесь — это «количество времени, которое мое приложение + API потратили на обработку каждого сообщения, извлеченного из сети».

Последовательно: 789 событий GC общей продолжительностью 1309 мс; средняя задержка 47,45 мкс, медианная задержка 8,704 мкс, максимальная задержка 1197 мкс

Параллельно: 1715 событий GC общей продолжительностью 122518 мс; средняя задержка 450,8 мкс, средняя задержка 8,448 мкс, максимальная задержка 8292 мкс

Параллельно: 4629 событий GC общей продолжительностью 116229 мс; средняя задержка 707,2 мкс, средняя задержка 9.216 мкс, максимальная задержка 9151 мкс

Инкрементальный: 5066 событий GC общей продолжительностью 200213 мс; средняя задержка 515,9 мкс, медианная латентность 9,472 мкс, максимальная латентность 14209 мкс

Я нахожу эти результаты настолько невероятными, что они граничат с абсурдом. Кто-нибудь знает, почему у меня могут быть такие результаты?

Да, и для протокола: я использую Java HotSpot(TM) 64-Bit Server VM.