О выключении сборщиков мусора в Java

Question

Недавно я слышал, как Кирк Пеппердин говорил об изменении сборщиков мусора для повышения производительности, но что именно это означает и что делает один сборщик мусора лучше или отличнее другого?

Answer 1

Вы задаете два вопроса:

Что означает изменение сборщиков мусора в Java для повышения производительности?

Это огромная тема, и, как и некоторые другие респонденты, я призываю вас немного почитать. Я рекомендую Java SE 6 HotSpot [tm] Настройка сборки мусора виртуальной машины от Sun. Информация ниже в основном поступает оттуда. Java-статья с турбонаддувом, рекомендуемая в другом ответе, старше.

Вкратце, одна из многих опций, которые мы имеем при запуске JVM, - это выбрать сборщик мусора, которых в настоящее время три:

• Последовательный сборщик (выбирается с опцией -XX: + UseSerialGC) - он использует один поток для выполнения всей работы по сбору, и все ждет, пока это произойдет.
• Параллельный коллектор (выбирается с помощью опции -XX: + UseParallelGC) - он выполняет параллельные второстепенные коллекции (молодого поколения), но во время основных коллекций все ждет.
• Параллельный сборщик (выбирается с помощью опции -XX: + UseConcMarkSweepGC) - это позволяет выполнять большинство операций сбора во время работы приложения.

Что делает один сборщик мусора лучше другого?

Ваше приложение делает. У каждого из сборщиков мусора есть «сладкое пятно» - диапазон профилей применения, для которых он является лучшим сборщиком.

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

В этом случае вам нужно задать следующие вопросы: 1) ваше приложение работает на однопроцессорной машине или на нескольких? 2) Вас больше волнует «минимизация времени паузы» или «максимизация пропускной способности»? То есть, если бы вам пришлось выбирать между приложением, которое никогда не приостанавливалось, но выполняло меньше работы в целом, по сравнению с выполнением большего объема работы в целом, но время от времени приостанавливало, что бы вы выбрали?

Грубо говоря, как отправная точка:

• На Multi -процессорной машине, в основном связанной с минимизацией времени паузы , вы склонны использовать коллектор Concurrent (рассмотрите возможность включения инкрементного режима)
• На Multi -процессорной машине, в основном связанной с максимизацией пропускной способности , вы склонны использовать коллектор Parallel (рассмотрите возможность включения параллельного сжатия)
• На однопроцессорном -процессорном компьютере с небольшими наборами данных (примерно до 100 МБ) вы, как правило, будете использовать Serial коллектор
• На одномоментном -процессорном компьютере, который в основном связан с максимизацией пропускной способности , вы, как правило, будете использовать Serial коллектор
• На одномоментном -процессорном компьютере, который в основном связан с минимизацией времени паузы , вы, как правило, используете коллектор Concurrent (рассмотрите возможность включения инкрементного режима)

Опять же, виртуальная машина делает довольно хорошую работу по выбору коллектора для вас, и вам лучше не переопределять это, если и до тех пор, пока вы не обнаружите, что он работает недостаточно хорошо для вашего приложения.

Answer 2

Некоторые коллекторы лучше для пропускной способности, другие лучше для времени отклика. Разница, как правило, заключается в том, как сборщик решает приостановить приложение. Некоторые, такие как CMS, используют несколько проходов для сортировки мусора перед остановкой приложения. Эта сортировка может происходить в фоновом потоке во время работы приложения и, таким образом, не мешать вашему приложению так сильно, как та, которая «останавливает мир» при выполнении GC.

Редактировать

Проверьте этот документ по солнцу . Кроме того, примерно на полпути внизу есть симпатичное изображение, показывающее сборщик меток по умолчанию против коллектора CMS. Картинка стоит тысячи слов, но статья тоже хорошо читается;) Также стоит прочитать все документы о новом сборщике G1.

Answer 3

Основная проблема заключается в том, что способ, которым Java-программа видит память (вы называете «новый MyObject» и вот так, и когда вы закончите с этим, вы просто забываете об этом), не очень хорошо отображается в базовой операционной системе. и оборудование.

Задача сборщика мусора состоит в том, чтобы идентифицировать те области памяти, которые не используются объектом, и «плавить» их вместе, чтобы получить БОЛЬШУЮ область памяти, из которой могут быть выделены новые объекты. Это очень смутно сформулировано в спецификации Java. КАК это делается, скорее всего, для обеспечения максимальной гибкости для разработчиков этой важной задачи.

Существует несколько подходов с преимуществами и недостатками. Обычно вам нужен сборщик мусора, который может работать в фоновом режиме с частотой отбрасывания объектов, так как единственный способ его догнать - остановить программу во время догоняющего. Это дает очень плохой пользовательский опыт.

Типичная тенденция для объектов Java заключается в том, что они либо живут очень короткое время (текущий блок или метод), либо очень долго. Современные сборщики мусора имеют дело с этим, имея несколько пулов, так что молодые объекты обрабатываются иначе, чем старые объекты.