Является сборщиком мусора (.net/java) проблемой для систем реального времени?

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

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

Мы еще несколько лет, но мне интересно, все еще проблема. Я читал о новом сборщике мусора в .Net 4, но он по-прежнему кажется большим черным ящиком, и вам просто нужно доверять, все будет хорошо.

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

ИЗМЕНИТЬ

спасибо за все большие ресурсы. Однако, похоже, что большинство статей/пользовательских gc-решений относятся к среде Java. Имеет ли .Net также возможности настройки или параметры для пользовательского GC?

Ответ 1

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

Более подробную информацию можно найти в Спецификации реального времени для Java на одном из подходов к достижению поведения в реальном времени с использованием Java. Идея RTSJ очень проста - не используйте кучу. RTSJ предоставляет новые разновидности объектов Runnable, которые гарантируют, что потоки не будут получать доступ к кучевой памяти любого типа. Темы могут либо обладать областью ограниченной памяти (здесь нет ничего необычного, значения уничтожаются при закрытии области) или бессмертной памяти (которая существует на протяжении всего жизненного цикла приложения). Переменные в бессмертной памяти записываются снова и снова с новыми значениями.

Благодаря использованию бессмертной памяти RTSJ гарантирует, что потоки не будут получать доступ к куче, и, что более важно, система не имеет сборщика мусора, который вытесняет выполнение программы потоками.

Более подробная информация доступна в документе "Проект Золотые ворота: к Java в пространстве в реальном времени в космосе" , опубликованный JPL и Sun.

Ответ 2

Я написал игры на Java и .NET и никогда не считал, что это большая проблема. Я ожидаю, что ваши "ужасные истории" основаны на сборщиках мусора много лет назад - технология действительно прошла долгий путь с тех пор.

Единственное, что я смущаюсь использовать Java/.NET для сбора мусора, было бы чем-то вроде встроенного программирования с жесткими ограничениями в реальном времени (например, контроллерами движения).

Однако вам нужно знать о паузах GC, и все это может помочь в минимизации риска пауз GC:

Сведение к минимуму новых распределений объектов - в то время как распределение объектов в современных системах GC чрезвычайно быстро, они вносят вклад в будущие паузы, поэтому их следует минимизировать. Вы можете использовать такие методы, как предварительное выделение массивов объектов, сохранение пулов объектов или использование распакованных примитивов.
Используйте специализированные библиотеки с низкой задержкой, такие как Javalution для сильно используемых функций и типов данных. Они разработаны специально для приложений в режиме реального времени/с низкой задержкой.
Убедитесь, что вы используете лучший алгоритм GC, если доступно несколько версий. Я слышал хорошие вещи о Sun G1 Collector для приложений с низкой задержкой. Лучшие GC-системы выполняют большую часть своих коллекций одновременно, поэтому сборку мусора не нужно "останавливать мир" очень долго, если вообще.
Настройте параметры GC соответствующим образом. Обычно существует компромисс между общей производительностью и временем паузы, возможно, вы захотите улучшить последнее за счет прежнего.

Если вы очень богаты, вы можете, конечно, купить машины с поддержкой аппаратного GC.: -)

Ответ 3

Да, мусор должен обрабатываться детерминированным образом в системах реального времени.

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

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

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

Ответ 4

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

Так получилось, что можно построить динамический распределитель памяти, который предлагает гарантии в реальном времени, но для этого требуется, чтобы распределитель выполнял некоторые тяжелые вещи, в частности, перемещал некоторые объекты в ОЗУ. Движение объекта подразумевает корректирующие указатели (прозрачно, с точки зрения кода приложения), и в этот момент распределитель находится всего на один маленький шаг от сборщика мусора.

Обычные реализации Java или .NET не предлагают сборку мусора в режиме реального времени в смысле гарантированного времени отклика, но их GC все еще сильно оптимизированы и имеют очень короткое время отклика большую часть времени. В нормальных условиях очень короткое среднее время отклика лучше, чем гарантированное время отклика ( "гарантировано" не означает "быстрый" ).

Также обратите внимание, что обычные реализации Java или .NET выполняются в операционных системах, которые также не в режиме реального времени (ОС может решить запланировать другие потоки или может агрессивно отправлять некоторые данные в файл подкачки и т.д.), и ни одно из них не является базовым оборудованием (например, типичный жесткий диск может время от времени делать "периоды перекалибровки" ). Если вы готовы терпеть случайный сбой времени из-за аппаратного обеспечения, то вы должны быть в порядке с (тщательно настроенным) сборщиком мусора JVM. Даже для игр.

Ответ 5

Это потенциальная проблема, НО...

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

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

Ответ 6

Вы ставите, что это проблема. Если вы пишете приложения с низкой задержкой, вы не можете позволить себе останавливать паузу, которые накладывают большинство сборщиков мусора. Поскольку Java не позволяет отключить GC, единственным вариантом является отсутствие мусора. Это можно сделать и было выполнено путем объединения объектов и загрузки. Я написал статью статью в блоге, где я подробно расскажу об этом.

Ответ 7

Наша компания использует большое программное обеспечение на базе .NET, которое, среди прочего, контролирует двоичные датчики через сети fieldbus. В некоторых ситуациях датчики активируются только на короткий промежуток времени (300 мс), но нашему программному обеспечению по-прежнему необходимо зафиксировать эти события, так как контролируемая система немедленно провалится при пропуске события. Недавно мы наблюдали повышенные проблемы на наших клиентских сайтах из-за того, что сборщик мусора работает для длинных временных интервалов (до 1 секунды). Мы по-прежнему пытаемся выяснить, как обеспечить соблюдение лимита времени для сборщика мусора. В заключение этой короткой истории я бы сказал, что сборщик мусора - это недостаток во временных критических приложениях.