|
M.O.D.U.S. Метафизика одиозного деконструктивизма услаждающих структур Персональный раздел Modus-а |
|
Опции темы |
28.03.2010, 18:53 | #1 |
дитя Ренессанса
Регистрация: 29.05.2008
Сообщений: 2,346
|
Утекание, или Как положить "абсолютно надёжную систему"
Где-то в конце 80-х годов был изобретён сборщик мусора - механизм для автоматического отслеживания использования динамической памяти. Утечки памяти считались одними из самых коварных ошибок, так как поздно диагностировались. Казалось бы, в дотнете, при использовании сборщика мусора, с этой проблемой покончено.
Но возьмем следующий сценарий. Есть у нас кэш, в котором хранятся объекты, поддерживающие оповещение о смене свойств. Кэш реализован как статический словарь. Затем есть какой-то метод, который для своей создаёт коллекцию, которая подписывается на событие оповещения о смене свойств объектов, которые в ней находятся. При этом объекты берутся из кэша и кладутся в эту коллекцию. Коллекция на них автоматически подписывается. Метод отработал. Коллекция больше не нужна. Но это не значит, что она автоматически уничтожится сборщиком мусора. Сборщик мусора обнаружит, что в статическом поле лежит объект, на событие которого подписана эта коллекция, которая больше ниоткуда недоступна. Но этой подписки достаточно для того, чтобы кэш держал её, не давая сборщику мусора её прибить. Метод вызывается много раз. В итоге к закэшированным объектам подписываются всё новые экземпляры коллекций, которые уже никак не уничтожить. И всё, приехали.
__________________
Инструменты сердятся, когда на них не играют |
28.03.2010, 21:48 | #2 |
Дед Мозай
Регистрация: 03.02.2006
Адрес: Москва
Сообщений: 11,274
|
Мдя, вспоминается старый метод программинга - написал процедуру захвата памяти - сразу пишь процедуру освобождения, только потом раздвигешь строки между этими процедурами и пишешь процедуру, ради которой эту память захватывал.
__________________
При необходимости личного обращения стучитесь в скайп по нику dimontsi |
28.03.2010, 22:33 | #3 |
Старожил
Регистрация: 15.02.2007
Адрес: Екатеринбург
Сообщений: 5,750
|
WeakReference -
Представляет слабую ссылку, которая указывает на объект, но позволяет удалять его сборщику мусора. Правда остаётся проблема очистки памяти от самих WeakReference.
__________________
Пока живут растаманы из глубинки - Вавилону не устоять! Последний раз редактировалось SerejaKu; 29.03.2010 в 12:34. |
29.03.2010, 13:01 | #4 |
Шволочь. И провокатор.
Регистрация: 12.02.2006
Сообщений: 31,007
|
хх
а какого хрена в статический объект шо т поклали? буратины как есть. статика - то, что существует весь цикл жизни программы. на что гарантированно есть линк пока жива программа. а чо вы творите?
__________________
... Survivors will be shot again. |
29.03.2010, 15:32 | #5 | |
дитя Ренессанса
Регистрация: 29.05.2008
Сообщений: 2,346
|
Цитата:
__________________
Инструменты сердятся, когда на них не играют |
|
29.03.2010, 19:39 | #6 |
Шволочь. И провокатор.
Регистрация: 12.02.2006
Сообщений: 31,007
|
ну и. мусор на входе - мусор на выходе. кто сказал, что закэшированные данные доступны всю жизнь программы? они вообще умирать должны быстрее объектов - пять минут не трогали - ссылка подохла. вынести их нахрен в мемкэшед и пусть автоматом экспайрятся, если самим лень чистильщика хэша делать.
__________________
... Survivors will be shot again. |
29.03.2010, 19:41 | #7 |
Шволочь. И провокатор.
Регистрация: 12.02.2006
Сообщений: 31,007
|
не забывая обернуть begin ... ensure ... end - а то первый жеж эксэпшен обрушит всё здание
__________________
... Survivors will be shot again. |
29.03.2010, 21:33 | #8 | |
дитя Ренессанса
Регистрация: 29.05.2008
Сообщений: 2,346
|
Цитата:
Кстати, даже если просто в методе Main сделать переменную, в которую всё кэшировать - эффект будет тот же самый. Проблема не в том, что закэшированные данные не очищаются - они и не должны этого делать до потери актуальности. Проблема в том, что они держат другие объекты, которые когда-то к ним обращались, но больше не нужны.
__________________
Инструменты сердятся, когда на них не играют |
|
29.03.2010, 23:10 | #9 |
Шволочь. И провокатор.
Регистрация: 12.02.2006
Сообщений: 31,007
|
я повторю.
указатель на объект должен жить определенное время самый простой способ гарантировать жизнь не больше времени - завести два кэша, один старый второй новый. раз в пять минут чистить указатели в старом и менять указатели старого и нового кэшей. указатели на объекты пихать в новый - в том числе и из старого кэша, если найден там. начинать поиск закэшированного - в новом кэше, заканчивать в старом. примитивная конструкция придумана на ходу. пысы. посмотри, если найдешь на построение гц в смалтолке. голубая книга вроде описывала. там идей забавных и возможных ловушек описано много - в том числе лечение чистки при кольцевых ссылках - введением обязательного условия ссылки на закольцованную структуру из-за пределов кольца, а то и наличие пути к колечку от центрального словаря.
__________________
... Survivors will be shot again. |
10.11.2010, 01:15 | #10 | |
дитя Ренессанса
Регистрация: 29.05.2008
Сообщений: 2,346
|
Цитата:
Вообще, философский смысл темы состоит в том, что наличие сборщика мусора создаёт иллюзию, что утечки памяти невозможны. Пока ВНЕЗАПНО на них не напорешься. В обсуждении этого прецедента с коллегами даже прозвучала такая мысль, что при написании кода на C++ вероятность наступить на подобные грабли меньше, так как точно знаешь, что сборщика мусора нет, и за динамической памятью нужно явно следить.
__________________
Инструменты сердятся, когда на них не играют |
|