Чистка ArrayList

@Vovabo4 · Регистрация: 05.06.2013

Студворк — интернет-сервис помощи студентам

Часто возникает потребность удаления всех элементов ArrayList. Как правильнее(с наименьшей памятью на выходе) это осуществить?

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
//Вариант 1
ArrayList a = new ArrayList();
...
a = new ArrayList();
 
//Вариант 2
ArrayList a = new ArrayList();
...
a = null;
a = new ArrayList();
 
//Вариант 3
ArrayList a = new ArrayList();
...
a.clear();

@tankomaz · 11.05.2014, 16:29

1й вариант - самый плохой, в момент создания нового объекта (а ссылка еще не освобождена для GC) - можете попасть в недостаток памяти
2й вариант - получше будет, но старый объект будет сидеть до вызова GC (теоретически самый быстрый должен быть, но немного ресурсодержащий)
3й вариант будет выполнен за O(n), из плюсов - лишняя память не используется, из минусов - проход по всей коллекции (для простоты понимания вскроем пациента)

Java
1
2
3
4
        for (int i = 0; i < size; i++)
            elementData[i] = null;
 
        size = 0;

Добавлено через 1 минуту
я бы лучше 2й юзал, если памяти не совсем кот наплакал и коллекции по 1кк элементов

@DEVcoach · 11.05.2014, 18:41

tankomaz,
Вы не учитываете массу нюансов.

Во-первых, с прикладной точки зрения разницы между первым и вторым вариантом нет вообще никакой. Если посмотреть на assembly код, то между обнулением и ссылки и присвоением ей нового объекта находится несколько десятков ассемблерных инструкций, суммарное время исполнения которых будет измеряться несколькими десятками наносекунд. Более того, если внимательно посмотреть на эти инструкции, то там особо некуда вставлять safepoint'ы GC, так как JIT агрессивно все инлайнит. Соответственно, вероятность, что GC сможет остановить поток после обнуления но до создания нового списка, стремится к нулю. Про мизерный размер пустого ArrayList я вообще молчу. Так что второй вариант вообще отбрасываем из-за его бессмысленности.

Во-вторых, выбор между первым и третьим вариантом очень сильно зависит от того, как именно используется этот список. Если это какой-то короткоживущий объект не особо большого размера, то надо однозначно создавать новый ArrayList. Тем самым GC будет прибивать его young generation на минорных сборках. Если же мы будем делать его clear(), то ссылка постареет и перейдет в tenured, и над ней GC будет пыхтеть уже в процессе более тяжеловесной major collection. А вот если это долгоживущий объект, или если размер списка велик (тысячи, десятки тысяч объектов, и более), и после очистки он все равно будет расти до эти размеров, то надо однозначно чистить, а не пересоздавать. Тем самым мы сможем избежать ненужных аллокаций памяти по мере роста списка. Но не зная входных данных автора, это тоже является "нанооптимизацией", а которой не стоит думать, пока не появится повод.

@Vovabo4 · 11.05.2014, 21:07 **[ТС]**

tankomaz, У меня почему-то возникает предположение, что 1й и 2й это абсолютно одно и то же.

@tankomaz · 11.05.2014, 21:14

Сообщение от Vovabo4

tankomaz, У меня почему-то возникает предположение, что 1й и 2й это абсолютно одно и то же.

Сообщение от DEVcoach

между первым и вторым вариантом нет вообще никакой

skipy тире ru.livejournal.com/6068.html

Добавлено через 1 минуту
+ http://habrahabr.ru/post/132500/

@tankomaz · 11.05.2014, 21:17

с ссылками на Скипа траблы, скрин даю если кто не не попадет на его сайт

@DEVcoach · 11.05.2014, 22:26

tankomaz,
Так я и написал - с практической точки зрения. Если у вас приложение не может аллоцировать очередной объект из-за нехватки памяти - ему конец. Если вы предварительно обнулите ссылку, то оттяните этот конец на несколько мгновений.
На практике это бессмысленно. Собственно, поэтому такое и встречается в реальном коде крайне редко - когда надо прибить один огромный объект, создав вслед за ним еще один не менее огромный. Мы же создаем несчастный ArrayList(), который займет что-то около 100 байт.

@Wado-Ru · 12.05.2014, 21:43

Сообщение от DEVcoach

GC будет пыхтеть уже в процессе более тяжеловесной major collection.

щас не 90-е, это уже не проблема

@DEVcoach · 13.05.2014, 00:10

Если бы это не было проблемой, у GC HotSpot не было бы нескольких десятков настроек.

Новые блоги и статьи Все статьи Все блоги /
Программный контроль заполнения реквизита табличной части документа Maks 02.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: реализовать контроль заполнения реквизита табличной части. . .	wmic не является внутренней или внешней командой Maks 02.04.2026 Решение: DISM / Online / Add-Capability / CapabilityName:WMIC~~~~ Отсюда: https:/ / winitpro. ru/ index. php/ 2025/ 02/ 14/ komanda-wmic-ne-naydena/	Программная установка даты и запрет ее изменения Maks 02.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: при создании документов установить период списания автоматически. . .	Вывод данных в справочнике через динамический список Maks 01.04.2026 Реализация из решения ниже выполнена на примере нетипового справочника "Спецтехника" разработанного в конфигурации КА2. Задача: вывести данные из ТЧ нетипового документа. . .
Функция заполнения текстового поля в реквизите формы документа Maks 01.04.2026 Алгоритм из решения ниже реализован на нетиповом документе "ВыдачаОборудованияНаСпецтехнику" разработанного в конфигурации КА2, в дополнении к предыдущему решению. На форме документа создается. . .	К слову об оптимизации kumehtar 01.04.2026 Вспоминаю начало 2000-х, университет, когда я писал на Delphi. Тогда среди программистов на форумах активно обсуждали аккуратную работу с памятью: нужно было следить за переменными, вовремя. . .	Идея фильтра интернета (сервер = слой+фильтр). Hrethgir 31.03.2026 Суть идеи заключается в том, чтобы запустить свой сервер, о чём я если честно мечтал давно и давно приобрёл книгу как это сделать. Но не было причин его запускать. Очумелые учёные напечатали на. . .	Модель здравосоХранения 6. ESG-повестка и устойчивое развитие; углублённый анализ кадрового бренда anaschu 31.03.2026 В прикрепленном документе раздумья о том, как можно поменять модель в будущем

@DEVcoach 12 / 12 / 2 Регистрация: 28.04.2014 Сообщений: 31
	11.05.2014, 18:41
	tankomaz, Вы не учитываете массу нюансов. Во-первых, с прикладной точки зрения разницы между первым и вторым вариантом нет вообще никакой. Если посмотреть на assembly код, то между обнулением и ссылки и присвоением ей нового объекта находится несколько десятков ассемблерных инструкций, суммарное время исполнения которых будет измеряться несколькими десятками наносекунд. Более того, если внимательно посмотреть на эти инструкции, то там особо некуда вставлять safepoint'ы GC, так как JIT агрессивно все инлайнит. Соответственно, вероятность, что GC сможет остановить поток после обнуления но до создания нового списка, стремится к нулю. Про мизерный размер пустого ArrayList я вообще молчу. Так что второй вариант вообще отбрасываем из-за его бессмысленности. Во-вторых, выбор между первым и третьим вариантом очень сильно зависит от того, как именно используется этот список. Если это какой-то короткоживущий объект не особо большого размера, то надо однозначно создавать новый ArrayList. Тем самым GC будет прибивать его young generation на минорных сборках. Если же мы будем делать его clear(), то ссылка постареет и перейдет в tenured, и над ней GC будет пыхтеть уже в процессе более тяжеловесной major collection. А вот если это долгоживущий объект, или если размер списка велик (тысячи, десятки тысяч объектов, и более), и после очистки он все равно будет расти до эти размеров, то надо однозначно чистить, а не пересоздавать. Тем самым мы сможем избежать ненужных аллокаций памяти по мере роста списка. Но не зная входных данных автора, это тоже является "нанооптимизацией", а которой не стоит думать, пока не появится повод. 1

@Vovabo4 21 / 19 / 4 Регистрация: 05.06.2013 Сообщений: 190
	11.05.2014, 21:07 [ТС]
	tankomaz, У меня почему-то возникает предположение, что 1й и 2й это абсолютно одно и то же. 0

@tankomaz ɐwʎ ɔ vǝmоɔ dиw ɐʚонɔ 443 / 442 / 100 Регистрация: 14.10.2012 Сообщений: 1,146 Записей в блоге: 9
	11.05.2014, 21:17
	с ссылками на Скипа траблы, скрин даю если кто не не попадет на его сайт Миниатюры 1

@DEVcoach 12 / 12 / 2 Регистрация: 28.04.2014 Сообщений: 31
	11.05.2014, 22:26
	tankomaz, Так я и написал - с практической точки зрения. Если у вас приложение не может аллоцировать очередной объект из-за нехватки памяти - ему конец. Если вы предварительно обнулите ссылку, то оттяните этот конец на несколько мгновений. На практике это бессмысленно. Собственно, поэтому такое и встречается в реальном коде крайне редко - когда надо прибить один огромный объект, создав вслед за ним еще один не менее огромный. Мы же создаем несчастный ArrayList(), который займет что-то около 100 байт. 0

@DEVcoach 12 / 12 / 2 Регистрация: 28.04.2014 Сообщений: 31
	13.05.2014, 00:10
	Если бы это не было проблемой, у GC HotSpot не было бы нескольких десятков настроек. 0