1

Одиночная нить устраняет множество осложнений, связанных с многопоточным приложением.Настройки GC для однопоточного приложения

Мне было интересно, существуют ли конфигурации сборщиков мусора, которые могут использовать однопоточное приложение?

Сейчас я использую UseConcMarkSweepGC, incrementalMode GC настройки на Ява Runtime Environment построить: Java 1.6.0_22-b04

+0

Не уверен, что это действительно имеет значение? Настройка GC очень специфична для приложений, и потоковая передача не обязательно актуальна. У вас в настоящее время проблемы с GC? Какие проблемы? Как выглядит ваша объектная модель? и т. д. ... все это имеет значение намного больше, чем однопоточное или многопоточное. – Taylor

+0

@ Тейлор Проблема: Выполнение профилирования Я вижу, что куча имеет много генерируемых строк. Я думал, если я увеличу ParallelGCThreads, тогда GC в целом будет обрабатывать процессор вместо приложения во время ConcurrentMarkingPhase CMS, но время GC может быть уменьшено. Так что для одного приложения с потоком это может быть проблемой? В этой мысли я думал, есть ли какие-нибудь хорошие настройки, подходящие для одного Threaded-приложения –

+0

вам нужны эти строки? такие же строки были созданы? может быть, может содержать некоторые в слабых ссылках или автоматически отбрасывая карту, как будто? – tgkprog

ответ

1

Если JVM запускается на однотридовой машине, он не будет использовать сложные барьеры памяти требуется для многоядерных процессоров, что позволяет сэкономить некоторый процессорный цикл.

Но JVM по своей сути многопоточен, даже если у вас есть только один поток, есть еще другие потоки, поддерживающие JVM.

Так что ответ, алгоритм GC не оптимизирован для однопоточных приложений.

+0

Согласитесь, будут потоки JVM (по крайней мере, основной, если это не gui), но большая часть действия будет в пользовательском потоке. a – tgkprog

+0

@tgkprog Настройка GC индивидуальна для каждого приложения и является многопоточным не является важным фактором. Если вы ищете помощь в настройке GC, опубликуйте свои журналы GC и цель состояния, которую вы хотите достичь (например, максимальная продолжительность паузы) –

0

Стратегии GC не зависят от того, как вы закодировали приложение, а на оборудовании, которое у вас есть.

Например, если у вас есть только один процессор доступной, то вы не должны позволить CMS по двум причинам:

  • он будет воровать это только процессорное время из вашего приложения, так что вы будете иметь STW пауз
  • Это означает, что накладные расходы будут параллельными, что означает, что ваше приложение будет остановлено дольше.

В этом случае вы должны включить SerialGC (или ParallelGC, это не имеет значения на одной машине ЦП).

Теперь, если у вас есть N ядра доступны, но ваше приложение использует только один, вы можете установить -XX:ConcGCThreads=N-1 и -XX:ParallelGCThreads=N-1 (в зависимости от GC вы используете), так что виртуальная машина полностью использует преимущества вашего оборудования.

Обратите внимание, что перед установкой любого флага вы должны включить журналы GC, используя -Xloggc:gc.log -XX:+PrintGCDetails, и после каждой новой конфигурации проверить, что оно улучшило время отклика/пропускную способность вашего приложения.

Источник: http://jvm-options.tech.xebia.fr/

 Смежные вопросы

  • Нет связанных вопросов^_^