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

[gloomyBrain]

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

А как? В Adobe Scout видно только 3 вещи - список вызовов, стоимость вызова и общее количество памяти. Весьма косвенная информация для обнаружения утечек. Вообще при наличии GC искать утечки IMHO можно только анализом собственного кода. Ну с небольшой помощью профайлера =)

[expl]

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

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

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

[СлаваRa]

тот же BitmapData.dispose() моментально освобождает память без GC, я не согласен с тем, что свои destroy()\dispose() методы вещь бессмысленная и захламляющая код.

[expl]

Мне показалось, gloomyBrain что-то еще имел вв виду, с dispose() то для BitmapData и XML понятно:
- знаешь время, когда BitmapData не нужна - вызывай dispose()
- не знаешь - не вызывай, пусть автоматом сработает
- впринципе можно выяснить, когда он не нужен, но придется написать вспомогательный код - тут уж насколько актуальны проблемы с памятью

... всё-таки BitmapData::dispose() может захламить код =/
Только не сама по себе строчка bitmapData.dispose(), а код, с помощью которого определения время вызова этой строчки (тут механизмы начиная от банальной подписки на REMOVED_FROM_STAGE до подсчета количества ссылок на bitmapData и эмуляции своего сборщика мусора)

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

Я забыл совсем, ведь был игровой проект с большим количеством ресурсов. И там не было другого выхода, как управлять "уничтожением" ресурсов вручную: не пользуется ни кто ресурсом 5 минут - сносим.
Сносим - это значит возвращаем bitmapData в пул и удаляем ссылку на ресурс из общего регистра ресурсов.
И там бло таки что-то типа посчёта ссылок на ресурс, чтобы определить, когда его перестали использовать (получила вьюшка ресурс - увеличиваем счётчик, ушла вьюшка с экрана - уменьшаем счетчик использования этого ресурса).

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

Сборка мусора сборкой мусора, а с загружаемыми ресурсами не всегда прокатывает.
Ну и с отпиской от внешних диспетчеров тоже.

... действительно, такая "оптимизация" работы GC может иметь смысл.

[wvxvw]

BitmapData.dispose() - влияет на логику программы. После того, как вы его вызовете, битмадаты больше не будет / ее нельзя будет использовать. Это никак не сравнимо с программами в "неуправляемых" рантаймах, где можно написать абсолютно корректную программу, которая, тем не менее будет течь, т.как где-то будут теряться ссылки на выделенную память.
Т.е. смотрите на задачу так: BitmapData которой не сделали dispose() - очевидно используется в программе. То, что вы ее не удалили - ну так это ошибка в логике вашей программы. Вот если бы вы ее не удалили и потеряли ссылку - вот тогда это утечка. Т.как у вашей программы пропадает шанс "реабилитироваться". А пока этого не произошло - ваша программа просто (возможно) неправильно работает.

Не может быть таких ситуаций в пользовательском коде, когда не возможно определить используется ли (нужен ли) объект или нет. Т.как их всех при создании, автоматически пронумеровали и следят за ссылками, и на уровне ГЦ проблема циклических графов не представляет существенных трудностей. Ошибка может быть только на уровне логики пользовательского кода: открыл сокет, чего-то записал в него, но не прочитал (не освободил буффер) - память занята, но это не ошибка управления памятью, а ошибка пользовательской программы: почему не прочитал / не освободил буффер?

Или, чтобы еще упростить, такой пример: создал я вектор на миллион элементов, а использовал 10 - память закончилась, но утечки в этом случае не было. Просто нерационально использован ресурс. Но программа может реабилитироваться, например, выбросив весь вектор.

[iflamberg]

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

Кстати, вот это вообще неправильно. Для таких проектов характерно то, что одинаковые объекты то рождаются на сцене, то умирают. Так зачем память освобождать, если они сейчас опять появятся? У меня в одном проекте натурально флешка подвисала каждых 10 секунд, потому что ГЦ чистил кучу удаленных объектов.
Так вот. Не надо их удалять. Отправлять их надо в пул, а потом по необходимости доставать заново. Естественно, если пул пустой - создать новую копию. Экономит процессорное время на создании объектов, и оперативную память тоже, потому что нет ненужных копий, которые ждут ГЦ.

[expl]

2 iflamberg:
Зачем удалять:
Проигралась анимация левелапа - ближайшее время её не надо будет доставать. Если не убрать - просто места не хватит под анимацию появляющихся мобов или анимацию стрельбы, например.
(суммарный объем ресурсов больше в разы среднего объема памяти - вот так вот весело)

Про пул: всё там было, и система пулов была. И уничтожение ресурса, состоящего из битмапдат значило часто покладание этих битмапок в пул, чтобы другие ресурсы распаковывали в них загруженное. Разным ресурсам назначались разные правила, определяющие когда они "не нужны" и т.д.

[KokoZzz]

2 all: развею тень сомнения.
интерфейс IDisposable просто предоставляет метод, который должен быть определен в целевом объекте. я ни в коем случае не вызываю принудительную чистку памяти при помощи ГЦ, я лишь вызываю у дочерних элементов метод dispose, а зачем чищу на эти элементы ссылки.
выглядит это так:

		public function dispose():void{
			for (var i:int = 0; i<this.numChildren; i++){
				if (this.getChildAt(i) is IDisposable){
					(this.getChildAt(i) as IDisposable).dispose();
				}
			}
			this.removeAllElements();
		}

2 expl:
а) спасибо за совет. побегу по всему проекту и уберу все анонимные функции... они, к сожалению, есть.
б) на счет отключения каких либо кусков кода: это очень трудозатратно. я нашел в целом, из-за какого объекта текет память и таким методом, и при помощи профайлера, снизил утечку памяти раз в 5, однако я просто отодвинул дату конца света. сложность в том, что я знаю объект, но не знаю что его держит.

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

2 Zebestov:
спасибо, попробую очистить XMLины. хотя я не уверен что поможет: "Объект XML сразу же становится доступным для сборки мусора", следовательно, XMLина ГЦ удалит ее из памяти, если она была правильно уничтожена. проверю в любом случае.

[wvxvw]

31 Мегабайт занят? Ну так это копейки. При том, как работает мусорщик, и принимая во внимание, что это четвертый Флекс - это слезы вообще. Дождитесь пока будет 2-3 гигабайта. Примерно в этом районе плеер обычно умирает от невозможности выделить еще памяти.
Что фундаментально плохо работает во Флексе с памятью - текстовые поля на основе FTL. Они действительно могут течь. Можно, если есть такая возможность попробовать отказаться от них, хотя бы для теста. Но не нужно этого делать пока вы своими глазами не увидите, как плеер умер от нехватки памяти. График на картинке - штатная ситуация, ничего даже такого, чтобы вызвало подозрения в нем нет.

[Котяра]

Попробуйте вручную вызвать GC в профайлере - если не освободилось - тогда может есть проблемы. Хотя тоже не факт.