Студопедия  
Главная страница | Контакты | Случайная страница

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Модель автоматической утилизации динамической памяти, основанная на сборке мусора. Проблема недетерминизма.

Читайте также:
  1. DOM - ОБЪЕКТНАЯ МОДЕЛЬ ДОКУМЕНТА
  2. III. Интегральная математическая модель расчета газообмена в здании при пожаре
  3. V-образная модель создания архитектуры ИТС и общие этапы разработки архитектуры ИТС платной дороги.
  4. А) экономикалық-математикалық модельдеу және болжау
  5. Автотранспорт как экологическая проблема
  6. Алкоголизм как социально-педагогическая проблема
  7. Американо- британская модель
  8. Американская модель
  9. Американская модель менеджмента
  10. Американская модель управления.

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

Модель с автоматической «сборкой мусора» предусматривает лишь возможность создавать объекты, но не уничтожать их. Система сама следит за тем, на какие объекты еще имеются ссылки, а на какие уже нет. Когда объекты становятся недостижимы через имеющиеся в программе ссылки (превращаются в «мусор»), их память автоматически возвращается системе.

Эта работа периодически выполняется «сборщиком мусора» и происходит в две фазы. Сначала «сборщик мусора» находит все достижимые по ссылкам объекты и помечает их. Затем он перемещает их в адресном пространстве программы (с соответствующей корректировкой значений ссылок) для устранения фрагментации памяти.

Обход графа достижимых объектов начинается от «корней», к которым относятся все глобальные ссылки и ссылки в стеках имеющихся программных потоков. Анализируя метаданные (информацию о типах данных, которая размещается внутри выполняемых модулей), «сборщик мусора» выясняет, где внутри объектов имеются ссылки на другие объекты. Следуя по этим ссылкам, он обходит все цепочки объектов и выясняет, какие блоки памяти стали свободными. После этого достижимые по ссылкам объекты перемещаются для устранения фрагментации, а ссылки на перемещенные объекты корректируются.

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

По скорости выделения памяти эта модель сравнима со стеком, ведь выделение объекта — это по сути увеличение указателя свободной области памяти на размер размещаемого объекта. Однако по достижении этим указателем определенного предела запускается «сборка мусора», которая может потребовать много времени и привести к ощутимой задержке в работе программы. Моменты наступления таких задержек и их длительность обычно непредсказуемы. Поэтому одна из проблем «сборщика мусора» — это недетерминизм связанных с его работой задержек.

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

Другой подход к амортизации задержек используется в «сборщиках мусора» реального времени среды Java (JRTS — Java Real-Time Specification). В них дефрагментация выполняется эпизодически и лишь в самом крайнем случае, когда не может быть найден свободный блок памяти нужного размера. Кроме того, «сборка мусора» выполняется в течение фиксированных интервалов времени (квантов), которые обязательно чередуются с квантами работы программы.

В модели с автоматической «сборкой мусора» программный код завершения жизни объекта (метод Finalize, или, говоря иначе, деструктор) выполняется асинхронно в контексте «сборщика мусора». Момент и порядок вызова этого метода у того или иного объекта никак не детерминированы, что порождает проблему, если объект управляет некоторым ресурсом, например сетевым соединением. Открытие соединения происходит при создании и инициализации объекта, т. е. предсказуемо, а закрытие соединения — во время «сборки мусора», т. е. непредсказуемо и далеко не сразу после потери последней ссылки на объект. В результате лимит сетевых соединений или других ресурсов может временно исчерпаться.

Для решения указанной проблемы в среде.NET используется детерминированное завершение жизни объектов через интерфейс IDisposable. Этот интерфейс имеет единственный метод Dispose, который реализуется в объектах, управляющих ресурсами. Метод Dispose, как правило, освобождает ресурсы и отменяет работу процедуры-завершителя (метода Finalize), чтобы ускорить освобождение памяти. После вызова метода Dispose объект не уничтожается, а остается в памяти до тех пор, пока не пропадут все ссылки на него.

Применение интерфейса IDisposable на практике выявило новые проблемы. Оказалось, что после вызова метода Dispose в программе могут оставаться ссылки на объект, находящийся уже в некорректном состоянии. Программе никто не запрещает обращаться по этим физически доступным, но логически «зависшим» ссылкам и вызывать у некорректного объекта различные методы. Метод Dispose может вызываться повторно, в том числе рекурсивно. Кроме того, в программе с несколькими вычислительными потоками может происходить асинхронный вызов метода Dispose для одного и того же объекта.

Для решения проблем этого метода программистам было предписано делать следующее:

1) определять в объекте булевский флаг, позволяющий выяснить, работал ли в объекте код завершения;

2) блокировать объект внутри метода Dispose на время работы кода завершения;

3) игнорировать повторные вызовы метода Dispose, проверяя упомянутый булевский флаг;

4) в начале public-методов проверять, находится ли объект уже в завершенном состоянии, и если это так, то создавать исключение класса ObjectDisposedException.

Заканчивая критику «сборщиков мусора», укажем еще на одну серьезную проблему с ними — легальную «утечку памяти». Если в модели с ручным освобождением объектов «утечка памяти» возникает из-за невыполненных операторов delete, то в модели с автоматической «сборкой мусора» — из-за невыполненного обнуления ссылок. Такой вид «утечек памяти» характерен для программного кода, в котором одними объектами регистрируются обработчики событий в других объектах. Программисты порой забывают отключать обработчики событий, в результате ассоциированные объекты остаются в памяти, несмотря на кажущееся отсутствие ссылок на них в программе.

 

 




Дата добавления: 2015-01-30; просмотров: 48 | Поможем написать вашу работу | Нарушение авторских прав

1 | 2 | 3 | 4 | 5 | 6 | 7 | <== 8 ==> | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 |


lektsii.net - Лекции.Нет - 2014-2024 год. (0.007 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав