Сборка "мусора" и потоки
AFAIK, когда GC делает свою вещь блоки VM все рабочие потоки - или по крайней мере когда он уплотняет "кучу". Имеет место это в современном implementions CLR и JVM (Производственные версии по состоянию на январь 2010)? Не предоставляйте основные ссылки на GC, поскольку я понимаю элементарные работы.
Я предполагаю, что глобальная блокировка имеет место как тогда, когда уплотнение происходит, ссылки могли бы быть недопустимыми в течение периода перемещения, и кажется самым простым только заблокировать всю "кучу" (т.е. косвенно путем блокирования всех потоков). Я могу вообразить больше устойчивых механизмов, но KISS часто преобладает.
Если бы я являюсь неправильным, на мой вопрос ответило бы простое объяснение стратегии, используемой для уменьшения блокирования. Если мое предположение корректно, обеспечьте некоторое понимание по следующим двум вопросам:
Если это - действительно поведение, как тяжелым механизмам предприятия нравится JBOSS, и Glassfish поддерживают последовательно высокий уровень TPS? Я сделал некоторое гугление на JBOSS, и я ожидал находить что-то на Apache как средство выделения памяти удовлетворенным для веб-обработки.
Перед лицом архитектуры NUMA-esque (потенциально ближайшее будущее) это походит на бедствие, если процессы не являются зависящими от ЦП потоком и выделением памяти.
6 ответов
Ответ заключается в том, что это зависит от используемых алгоритмов сборки мусора. В некоторых случаях вы правы, что все потоки останавливаются во время GC. В других случаях вы неверны в этом сборе мусора продолжаются, пока работают нормальные потоки. Чтобы понять, как GC достигнет этого, вам нужно подробное понимание теории и терминологии сборщиков мусора, в сочетании с пониманием конкретного коллектора. Это просто не поддается простому объяснению.
О да, и стоит указать, что многие современные коллекторы не имеют фазы уплотнения Per-SE. Скорее они работают, копируя живые объекты в новое «пространство» и обнуляя старое «пространство», когда они сделаны.
Если я неверный, мой вопрос будет дан ответом простом объяснением стратегии, используемой для минимизации блокировки.
Если вы действительно хотите понять, как работают сборщики мусора, я рекомендую:
- « Коллекция мусора: алгоритмы для автоматического динамического управления памятью« Ричард Джонс.
- «Справочник по сборке мусора: искусство автоматического управления памятью» Ричард Джонс, Antony Hosking и Eliot MOSS
... и остерегайтесь, чтобы найти точные, подробные, публичные описания внутренних докладов производственных мусорных коллекторов нелегко. (Хотя в случае Hotspot GC вы можете посмотреть на исходный код ...)
Редактировать: В ответ на комментарий ОП ...
«Кажется, это как я думал - - Нет смысла «остановить мир». »
это зависит. В случае Java 6 одновременный коллектор , есть две паузы во время маркировки корней (включая стеки), а затем маркировка / копирование других объектов продолжается параллельно. Для других видов одновременного коллектора используются барьеры чтения или записи, в то время как коллектор работает в ситуациях захвата, где коллектор и потоки приложений в противном случае будут мешать друг другу. У меня нет своей копии [Джонса] здесь прямо сейчас, но я также вспоминаю, что можно сделать «остановить мир» интервал незначительным ... по стоимости более дорогих операций указателя и / или не собирая все мусор.
Существует ряд алгоритмов GC, доступных с Java, не все из которых блокирует все текущие потоки. Например, вы можете использовать -xx: + USECONCMARMSWEEPGC, который работает одновременно с приложением (для сбора конфета поработанности).
Вы правы, что сборщик мусора придется приостановить все потоки приложения. Эта время паузы может быть изменена с помощью Sun JVM, используя одновременный коллектор, который претендует на некоторые работы, не останавливая приложение, но он должен приостановить поток приложений.
См. Здесь http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gc И здесь http://java.sun.com/javase /technologies/hotspot/gc/gc_tuning_6.html#cms Для получения подробной информации о том, как Sun JVM управляет сборной мусором в последних JVMS.
Для веб-приложений я не думаю, что это проблема. Поскольку пользовательские запросы должны быть завершены в течение небольшого количества времени <1S любые временные объекты, выделенные для обслуживания, запрос не должен выходить из молодого поколения (предоставляя его соответствующим образом), где они убираются очень эффективно. Другие данные с более длинными жизненными циклами, такие как пользовательские сеансы, будут зависать дольше и могут повлиять на время, потраченные на основные события GC.
В приложениях высоких TPS Обычная стратегия - запускать несколько экземпляров сервера приложений либо на одном или отдельном аппаратном обеспечении, используя аффинность сеанса и загрузки. При этом индивидуальный размер кучи на JVM остается меньше, что сократило время паузы для GC при выполнении основной коллекции. В целом база данных становится бутылкой, а не приложением или JVM.
Самое близкое, что вы можете найти в концепции веб-специфического распределения памяти в J2EE - объединение объекта / экземпляра, которое выполняется структурами и сертию приложения. Например, в JBoss у вас есть бассейны EJB и соединительные базы данных. Однако эти объекты обычно объединяются из-за более высокого качества создания, а не накладные расходы на сборку.
Я считаю, что IBM выполнила некоторые исследования по улучшению производительности GC в многоядерных системах, которые включают в себя работу по снижению или устранению проблемы «все остановки».
E.g. видеть: Параллельный, инкрементный и одновременный GC для серверов (PDF)
или Google что-то вроде «Одновременная сборка мусора IBM»
Современное состояние коллекции современного мусора для Java до сих пор связано с эпизодическими паузами "остановить мир". G1 GC, представленный на Java 6u14, делает большую часть своей работы одновременно, однако, когда память действительно мала, и ей нужно сжать кучу, тогда она должна быть уверена, что никто не будет связываться с кучей под ней. Это требует, чтобы ничто больше не могло продолжаться. Чтобы узнать больше о G1 GC, посмотрите презентацию от Sun.
Насколько мне известно, когда сборщик мусора делает свое дело, виртуальная машина блокирует все запущенные потоки - или, по крайней мере, когда он уплотняет кучу. Так ли обстоит дело с современными реализациями CLR и JVM (производственные версии по состоянию на январь 2010 г.)?
И JVM Sun Hotspot, и среда CLR Microsoft имеют параллельные сборщики мусора, которые останавливают мир только на короткие этапы (чтобы -согласованный снимок глобальных корней, из которых доступны все данные в реальном времени), а не для всех циклов сбора. Я не уверен в их реализации уплотнения, но это очень редкое явление.
Если это действительно так, то как тяжеловесные корпоративные движки, такие как JBOSS и Glassfish, поддерживают стабильно высокую скорость TPS?
Задержка этих движков на порядки больше, чем время, необходимое для остановки мира. Кроме того, задержки указываются как, например, 95-й процентиль, что означает, что задержка будет ниже указанного временного интервала в 95% случаев. Таким образом, уплотнения вряд ли повлияют на указанные задержки.