Если надо почистить коллекцию, что лучше - вызвать метод clear() или заменить новой пустой? Замена на новую выглядит предпочтительнее в смысле потокобезопасности. А метод clear(), который ставит null всем элементам коллекции, наверное лучше в смысле уборки мусора. 

Думаю, что это от конкретной ситуации зависит. 
Например, не всегда есть возможность заменить объект-коллекцию на новый. Если она объявлена как final, то в ходу только clear(). 
Так же, осмелюсь предположить, что замена коллекции на новую, будет работать быстрее, чем очистка методом clear() . Поскольку при очистке нужно выставить в null большое количество элементов. Поэтому, если коллекция велика, то лучше заменить её на новую. Если не очень велика или время очистки не критично, то подойдёт и clear().

Это сообщение отредактировал(а) powerOn - 11.1.2008, 22:18

COVD, правило большого пальца тут такое:

Если коллекция никому не нужна, бросаем ее и создаем новую. Сборщик мусора со временм подхватит ее и оприходует.

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

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

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

Вот так вот примерно 

Но если её предварительно почистить, то сборщику действительно будет значительно легче.

Вообще-то я всегда считал, что главная идея со сборщиком мусора заключалась в том, чтобы легче было мне, а не ему 

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



Шютка, в которой, сами знаете...

Я имел в виду буферы, в которые один поток кладет данные, а другой их все забирает. Но иногда их надо чистить третьим потоком, потому что меняются условия работы. Замена на новую мне нравится тем, что если по недосмотру другой поток что-то все еще делает в буфере, то он спокойно закончит свое дело. Перестраховка. Но вот кому быстрее ее удастся почистить - моему коду или gc? Ведь наверное gc тоже будет сначала ее чистить путем установки в null всех элементов? Действительно ли я значительно облегчу ему работу? Может он это сделает эффективнее? Одно очевидно, что чем раньше "отвязать" от коллекции содержимое, если оно подлежит уборке, тем лучше. А если содержимое не подлежит уборке? Наверное, это уже философия. 



   Но если можно помочь, разве трудно? Беда в том, что не очевидно, помогаешь или вредишь. В этом смысле клиентские приложения более чувствительны. На сервере взял и увеличил память, добавил мозгов. А клиенты все разные.


Это сообщение отредактировал(а) COVD - 11.1.2008, 23:26

Шютки шютками, а неприятный опыт имеется. Хотя вы, конечно, правы. Но здесь ситуация примерно та же, что и с пулами объектов - sun'овцы призывают не делать ничего подобного (говоря о том, что когда-нибудь операция new не будет так тормозить, а сборщик обретёт ИИ ), но... 

Да, "ни в чем себе не отказывайте", gc справится. Однако когда апплетовцев спросили как же быть, ведь нельзя для апплета указать необходимую память (-Xmx, -Xms), то ответом был призыв к экономии. 

По моему опыту общения с ребятами из Sun'а - они отчаянно призывают не делать (почти) ничего для облегчения работы gc. Утверждают, что он всегда лучше справится сам.