Сборщик мусора

[searinox]

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

[Dukobpa3]

В 99% случаев не нужно искать неведомую хрень которую не собрал сборщик "хотя должен был". В этих же 99% случаев нужно просто еще раз проверить код на наличие ссылок на объекты которые якобы должны были быть удалены.

Мне помогает. Сборщик тут ни при чем

[maxkar]

GC не собирает все "живые" объекты. Это все объекты из display list, загрузки (loader'ы), вроде бы - активные таймеры. Плюс все объекты, до которых по ссылках из "живых" можно дайти. В том числе - ApplicationDomain'ы, загруженые в appdomain'ы классы, сохраненные в статических полях этих классов ссылки.

И я полностью согласен с Dukobpa3 - нужно искать в коде, где не удаляются (или добавляются лишние) ссылки на объекты.

[Aquahawk]

а ещё анонимные функции часто цепляют в замыкание то что совсем не нужно. Если в коде используются анонимные функции то от них надо избавиться. Они могу быть источником оооочень больших проблем.

[ramshteks]

Aquahawk, насчет функций подтверждаю. Кстати говоря не только анонимные. Вполне возможно где-то вы храните ссылки на эти обычные функции, что тоже приводит к утечкам. Говорю по собственному опыту, такая фигня была. 4000 ссылок на методы сильно съедают память. Профилировщик вам в помощь.

[Aquahawk]

когда вы храните ссылку на метод, на самом деле это объект класса MethodClosure который хранит ссылку на объект от которого его оторвали. Итого хранение ссылки на метод какого-то объекта равносильно хранению ссылки на объект.

[gloomyBrain]

Итого хранение ссылки на метод какого-то объекта равносильно хранению ссылки на объект

Ну в общем - логично. По сути-то есть всего одна функция, которой просто передается разный this. Мне не совсем понятно, почему при таком раскладе MethodClosure занимает хоть сколько-нибудь заметную память. Ибо это структура из 2 указателей: на функццию и на объект-обладатель.

[in4core]

Кстати говоря об анонимных функциях . Частенько в приложениях бывает надо спрятать объект ( висибл = фалс ) , через некоторое время посл нажатия кнопки например. Причем приложении такая точка может быть всего одна, ну как тут не сделать setTimeout с анонимкой ?))) можно конечно и отдельную функцию написать с одной строчкой , но толку то)
А еще самый лучший вариант TweenMax.to( obj , 5 , { visible:false })

[gloomyBrain]

Нет, ты неправ! Самый лучший способ - это

TweenMax.to({}, 0.1, {onComplete: function():void {TweenMax.to({}, 0.1, {onComplete:arguments.callee})}})

[wvxvw]

На самом деле замыкание, включает в себя не 2 указателя. Оно включает в себя список (порой очень даже длинный) всех областей видимости, которые доступны там, где оно используется. Иначе не возможно было бы из функции обращаться к глобальным методам и тому, что было импортировано классом.