Утечка памяти. больше методов решения.

[KokoZzz]

добрый день формучане! тема заезженная, параллельных много, однако решения проблемы найти не удается.

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

что я делаю:
1. для всех возможных слушателей установил викреференсы.
2. уничтожаю все слушатели по мере уничтожения родителя
3. реализовал для всех потенциальных классов интерфейс IDisposable: чистит объекты, при уничтожении родителя
4. использовал вик референс для вьюх и контроллеров (спасибо http://dtf.ru/articles/read.php?id=51967)
5. прошерстил статичные классы, ссылок на потенциальные объекты нет.
6. профайлил приложение: память забивается! потенциальный объект: DashBoardView. держат его какие то функции, как их найти я не понимаю. (к слову, GC отрабатывает, но объекты не выгружает)

вопросы:
1. какие еще существуют стандартные средства борьбы с утечками
2. могут ли Embed картинки удерживать объект?
3. как узнать, какие же точно функции держат мой объект и не отдают во врата GC на съедение? в аттаче скриншот профайлера и дэшборда с функциями.


p.s. не исключено что я где то не удалил слушатель или ссылку. но проект слишком большой, чтобы перелопачивать его построчно.

заранее спасибо!

[expl]

7. Убрать _все_ _без исключения_ анонимные функции из проекта - на одном после оной операции потребление памяти упало с 800 до 200 метров. (плюс-минус - я не помню точные цифры уже)

А эти викреференсы - как парашют для экипажа пассажирского лайнера - вроде 2-4 человека спасутся - это лучше, чем все 100 погибнут, но надо ли так мотивировать экипаж спасать пассажиров? Т.е. все эти мягкие ссылки c одной стороны уменьшают пагубные эффекты от утечек, но с другой - маскируют места, где Вы забыли отписаться и возникают уже другие проблемы - со срабатыванием листнера пока его GC не соберёт, хотя он не нужен.

реализовал для всех потенциальных классов интерфейс IDisposable: чистит объекты, при уничтожении родителя

Интересно, как он их чистит? Пример кода просто.

По поводу методов поиска утечек - самый тупой способ - это отключаем подозрительные блоки кода и смотрим что происходит с памятью. Как только получили резкое изменение - начинаем плясать от кода, который отключили.
Например, если есть подозрение, что память течёт из-за объектов на сцене - не надо гадать, просто перестаём их создавать вообще и смотрим что меняется - ничего не меняется? - создаём, но не добавляем на сцену и т.д.

[wvxvw]

для всех возможных слушателей установил викреференсы.

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

реализовал для всех потенциальных классов интерфейс IDisposable: чистит объекты, при уничтожении родителя

Верните все как было. Это самое неудачное, что только можно придумать в рантайме с управляемой памятью, особенно, принимая во внимание то, что у вас нет настоящих ссылок на объекты. Вы хотите написать свой ГЦ с блек джеком и нянями-массажистками? И при этом не можете решить проблемы ГЦ уже существующего? Попробуйте реалистичнее оценить ваши шансы на успех.

Что мы видим на картинке? Это ситуация когда возникла ошибка out of memory? Пока вы не получите out of memory, или аналогичную / сопутствующую ошибку утечка памяти не доказана / не установлена. Может просто вашей программе действительно нужно больше ресурсов.
Даже после того, как вы получите соответствующую ошибку, нужно проанализировать ситуацию. Не каждая такая ошибка свидетельствует об неправильно используемой памяти. Возможно, вашей программе нужно больше ресурсов - и вам нужно пересмотреть стратегию получения ресурсов, но никак не очистку.

Существуют типичные причины, где, зачастую, могут произойти утечки. Например, не остановленный Timer никогда не освободит память, даже если все ссылки на него в пользовательском коде уничтожены. Вообще все события такого плана - потенциальные подозреваемые.
LocalConnection так же, если его явно не уничтожать, может привести к подобным результатам. В остальных случаях нужно начинать с анализа пользовательского кода и смотреть на то как часто создаются и уничтожаются экземпляры выбранного класса. Найти такие, которые не уничтожаются в предполагаемый срок и попытаться установить причину.

[iflamberg]

Верните все как было. Это самое неудачное, что только можно придумать в рантайме с управляемой памятью, особенно, принимая во внимание то, что у вас нет настоящих ссылок на объекты. Вы хотите написать свой ГЦ с блек джеком и нянями-массажистками? И при этом не можете решить проблемы ГЦ уже существующего? Попробуйте реалистичнее оценить ваши шансы на успех.

Чего? А как же рекомендации типа: "если вы хотите, что ГЦ отчистил память от объекта, то отпишите все слушатели, занулите все ссылки на другие объекты". Ну и как моему объекту определить, что вот оно, "пришло твое время". На мой взгляд только так - вызовом какой-нибудь функции destroy из интерфейса IDestructable. Какие еще варианты?

[caseyryan]

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

Не могу поверить, что это говорит старожил форума..
Может я не правильно понял ход мысли здесь, но как можно рекомендовать отказ от "уборки за собой"?

[Zebestov]

System.disposeXML() еще частенько забывают.

[expl]

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

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

чистит объекты, при уничтожении родителя

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

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

[wvxvw]

Подробнее о том, почему не нужно пытаться своими силами организовать ГЦ:
- у вас технически нет необходимой информации (вы не можете построить граф в котором арками являутся связи "на А ссылаются из Б", либо вам нужно будет все вызовы new заворачивть в функцию, которая будет следить за созданием таких связей. Т.как код ОПа зависит от четрвертого Флекса (килотонны AS3 кода, в которых эта стратегия не применялась), то вы не сможете это правило сделать глобальным - скорее всего пользовательский код не составляет и десяти процентов от всего кода программы.
- У вас технически нет возможности очистить память. Управляемый рантайм потому и управляемый, что напрямую работать с памятью выделенной рантаймом вам никто не даст. Тому есть множество причин, и вдаваться в подробности сейчас нет смысла, но самое главное - это безопасность и возможность рантайма применять какие либо стратегии по работе с памятью не принимая во внимание пользовательский код. Пример (теоретический) такой возможности: вы создали массив на 100000 элементов и положили туда всего 10. Рантайм зная, что вы грязными руками не полезете в память помещать или убирать элементы может себе позволить либо выделять память по мере необходимость, либо разрешить другим объектам использовать выделенную, но пока что не востребованную память. Подобных техник существует множество.
- Добавив код который якобы что-то очищает, вы создаете "шум" - бесполезный текст программы, который затрудняет чтение программы, и располагает к появлению ошибок по причине невнимательности.

Утечка памяти в управляемом рантайме - это проблема в логике кода. Правильный код не может создавать утечки. Следовательно, чтобы нейтрализовать утечку нужно найти и исправить ошибку в пользовательском коде.
Конечно, это правило верно только в том случае, если доказано, что рантайм работает всегда правильно - к сожалению, в рантайме могут быть неинтуитивные моменты, или просто ошибки, которые приводят к утечкам (как уже упоминалось выше - таймер и т.п.), поэтому их тоже нужно проверить.

[gloomyBrain]

wvxvw чертовски прав.
Делать собственные dispose-методы стоит только в приложении утечек нет с целью дополнительной оптимизации срабатывания GC (если Вы верите, что Ваш труд кто-то заметит).

[Sintesis]

А скаутом разве нельзя утечку обнаружить?