Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java: Общие вопросы > Чистить ли коллекцию или заменить?

Автор: COVD 11.1.2008, 21:36

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

Автор: powerOn 11.1.2008, 22:17

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

Автор: Stampede 11.1.2008, 22:34

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

Автор: w1nd 11.1.2008, 22:54

Цитата(Stampede @  11.1.2008,  22:34 ) Если коллекция никому не нужна, бросаем ее и создаем новую. Сборщик мусора со временм подхватит ее и оприходует. Но если её предварительно почистить, то сборщику действительно будет значительно легче.

Автор: Stampede 11.1.2008, 23:12

Цитата(w1nd @  11.1.2008,  12:54 ) Но если её предварительно почистить, то сборщику действительно будет значительно легче.  Вообще-то я всегда считал, что главная идея со сборщиком мусора заключалась в том, чтобы легче было мне, а не ему  Если продолжать следовать вашей логике, можно из жалости к ресурсам отказаться от механизма исключений и вернуться к повальной практике анализа кода возврата. Но можно пойти и еще дальше! Компилятор, вот не кого не распространилось еще наше милосердие! Облегчим ему работу, сократив имена переменных и функций до однобуквенных! Шютка, в которой, сами знаете...

Автор: COVD 11.1.2008, 23:19

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

Автор: w1nd 11.1.2008, 23:36

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

Автор: COVD 11.1.2008, 23:54

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

Автор: batigoal 12.1.2008, 00:17

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)