Сборщик мусора в системе реального времени
Я новичок в C#/Java и планирую создать прототип для мягкой системы реального времени.
Если бы я написал приложение на C#/Java точно так же, как я делаю это на C++ с точки зрения управления памятью, то есть я явно "удаляю" объекты, которые я больше не использую, то будет ли приложение по-прежнему подвергаться воздействию сборщика мусора? Если так, как это влияет на мое приложение?
Извините, если это звучит как очевидный ответ, но, будучи новым, я хочу быть тщательным.
6 ответов
Взгляните на IBM Metronome, сборщик мусора для жестких систем реального времени.
Ваша предпосылка неверна: вы не можете явно "удалить" объекты в Java или C#, поэтому GC всегда будет влиять на ваше приложение.
Вы можете попытаться вызвать коллекцию, позвонив GC.Collect
(C#) с соответствующим параметром (например, GC.MaxGeneration
) но это все еще не гарантирует, что GC не будет работать в другие моменты во время выполнения.
Явным "удалением", если вы имеете в виду освобождение ссылки на объект, вы полагаетесь на сборщик мусора в управляемом коде C# - способы управления им см. В классе System.GC.
Если вы решите написать неуправляемый код на C#, тогда вы будете иметь больший контроль над памятью, схожий с C++, и будете отвечать за удаление созданных вами объектов, сможете использовать указатели и т. Д. Для получения дополнительной информации см. Документ MSDN - Небезопасный код и указатели (Руководство по программированию на C#).
В неуправляемом коде вы не будете зависеть от сборщика мусора и его неопределенных алгоритмов очистки.
Я не знаю, есть ли в Java эквивалентный неуправляемый режим, но эта информация Microsoft может помочь дать некоторое указание на C#/.NET, чтобы использовать его доступные функции для вашего требования иметь дело с сборщиком мусора.
В Csharp или Java вы не можете удалить объект. Вы можете только пометить их как доступные для удаления. Освобождение памяти будет выполнено сборщиком мусора. Может случиться, что сборщик мусора может не работать в течение срока службы вашего приложения. Однако это, вероятно, будет работать. Когда вашей системе не хватает ресурсов, это наиболее вероятное время, когда подпрограммы GC запускаются средой выполнения. А когда ресурсов мало, GC становится потоком с наивысшим приоритетом. Таким образом, ваше заявление будет выполнено. Однако вы можете минимизировать эффект, рассчитав правильную нагрузку и необходимые ресурсы для времени жизни вашего приложения, и не забудьте купить подходящее оборудование, которое достаточно для этого. Но вы все равно не можете просто оценить свою производительность.
Помимо только GC, управляемое приложение получает небольшие издержки по сравнению с традиционным приложением C++ из-за дополнительного уровня делегирования. И незначительное снижение производительности в первый раз, так как время запуска должно быть запущено до запуска вашего приложения.
Вот несколько ссылок для разработки систем реального времени с.net compact framework:
- IEEE - C# и.NET Framework: готовы к работе в реальном времени?
- MSDN - поведение в реальном времени.NET Compact Framework
Они оба говорят о требованиях к памяти для использования.net framework.
C# и Java не предназначены для разработки в реальном времени. Однако, как вы заметили, мягкое реальное время достижимо.
Для C# лучшее, что вы можете сделать, это реализовать шаблон finalize/dispose:
http://msdn.microsoft.com/en-us/library/b1yfkh5e(VS.71).aspx
Вы можете попросить его собрать, но, как правило, гораздо лучше определить, как это сделать.
http://msdn.microsoft.com/en-us/library/system.gc(VS.71).aspx
Для Java есть много вариантов его оптимизации:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
Наряду со сторонними решениями, такими как IBM Metronome, как отмечено выше.
Это настоящая наука в самой CS.