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

kemsky, я оставил комент в вашем блоге.
http://compile4fun.wordpress.com/201...weakreference/
Ответ мне совершенно не понятен =)
Предлагаю перенести дискуссию сюда.

все просто, например, есть класс, который дергает сервер, нам нужно чтобы в это время пользовательский интерфейс был залочен. передаете в этот класс сылку на дисплейобъект и все происходит автоматически. Если использовать weakReference, вручную очищать эту ссылку не потребуется и она не будет препятствовать сборке мусора. Если же не испльзовать weakReference, то сборщик мусора должен будет разруливать циклические ссылки, а с этим есть проблемы.

В свою очередь, хочу спросить какие советы адоби вам помогают решать проблемы с памятью :)

Еще бы написали: пишите как хотите и не парьтесь.

Во первых далеко не у все есть возможность и желание использовать flash builder.
Во вторых flash плеер действительно работает не очевидным образом.
Вы можете сделать все, чтобы тот или иной компонент был удален. Но для того, чтобы в этом убедится вы должны будете вызвать System.gc() . MemoryController был собран по мотивам блогов gscinner.com, написанных аж 2006 году и тогда еще такого метода в System не было и поэтому использовался хак, с классами LocalConnection. С тех пор изменилось совсем немного, если не считать библеотеки flash.sampler.

Однако даже благодаря ей вы до сих пор будете испытывать определенные трудности при попытке отследить утечки памяти.

Было бы правильно научить :
1 все EventDispatcher ы в один присест отписываться от событий.
2. объекты определять какое количество жестких ссылок связано с объектом и главное где были объявлены эти ссылки.
3. научить DisplayObject ы корректно уничтожаться (автоматически отсоединять себя и всех потомков, отписываться от событий, обнулять все жестские ссылки на себя и выпихивать их из массивов и кешей)

Ну, право, велосипеды тоже имеют право быть! Поддерживаю начинания.

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

@kemsky. Бегло посмотрел Ваш блог. Понравилось про совсем не "Дви́гатель Сти́рлинга".

dimarik, вас тоже спросить про советы адоби? Пока terbooter готовит ответ, может быть вы поможете? =)
назначение слабых ссылок разжевано на википедии

На своей памяти помню только одну такую необходимость, да и то в коде BloodHound'a.

Для расширения кругозора - для чего там?

А где-то он в идиотизмах писал о трике с текстовым полем, чтобы при неудачной загрузке в него картинки не бросалось исключение.

А, перехват Loader`а. Ну в любых патчах выходит имеет смысл использовать weakReference.