Преимущества массивов
Как я вижу, преимущества списка над массивом довольно очевидны:
- Generics обеспечивает более точный ввод текста:
List<Integer>, List<? extends Number>, List<? super Integer>
.
- Интерфейс List имеет множество полезных методов:
addAll
, remove
и т.д. Хотя для массивов все стандартные операции, кроме get/set, должны выполняться процедурным способом, передавая его статическому методу.
- Коллекции предлагают различные реализации, такие как
ArrayList
, LinkedList
, unmodifieable и синхронизированные списки, которые могут быть скрыты под общим интерфейсом List.
- Управление длиной OOB.
В качестве недостатков я могу упомянуть только отсутствие синтаксического сахара и проверку типа времени выполнения. В то же время поддержка обеих структур требует частого использования методов asList
и toArray
, что делает код менее читаемым. Поэтому мне любопытно, есть ли какие-либо важные преимущества использования массивов, которые я пропускаю.
Ответы
Ответ 1
Массивы более эффективны как с точки зрения времени обработки, так и с точки зрения памяти. Это особенно применимо, если вы работаете с примитивными типами, такими как int
или long
, так как List
требует, чтобы все элементы были обернуты в Object
(например, Integer
или long
). Хотя функции автообновления, введенные Java 5, уменьшают объем кода, который вам нужен для такой упаковки и развертывания, он не устраняет проблем с производительностью, поскольку объекты-оболочки все еще создаются.
Однако большинство приложений, вероятно, не имеют узких мест в производительности, связанных с этими проблемами, поэтому в большинстве случаев List
и другие коллекции должны работать нормально. В этих случаях легкость программирования перевешивает увеличение использования памяти или процессора, а List
- правильный выбор.
Ответ 2
Если ваш список не меняется часто, списки добавляют много лишнего веса к объекту, который вы никогда не будете использовать. Когда вы пытаетесь запустить что-то, что нужно оптимизировать, это полезно. Этот дополнительный вес также делает вещи медленнее, чем они были бы с помощью только массивов. Однако, если вы не знаете, что вам нужны массивы усиления, вы должны просто использовать списки.
Ответ 3
Одна вещь, которую я не видел, упоминается здесь: массивы могут иметь N измерений, тогда как списки ограничены одним. Вы можете использовать списки списков, но синтаксис (List<List<...>>
) гораздо более громоздкий, чем [] []
Ответ 4
Скорость. Коллекции несколько медленнее, чем простые массивы: внутренне большинство по-прежнему используют массивы, но имеют дополнительные уровни кода вокруг них. Конечно, если у вас нет особой необходимости в дополнительной производительности, вы все равно должны использовать коллекции.
Еще одно небольшое преимущество массивов состоит в том, что было бы проще вызвать вариативные методы с массивами. Это никогда не должно быть основной причиной выбора одного над другим, хотя.
Ответ 5
Если есть какие-либо важные преимущества использования массивов, которые я пропускаю?
Постоянный доступ к любому элементу с очень небольшой константой. Для безопасного доступа к элементу массива требуется всего несколько инструкций: несколько нагрузок, сравнение и ветвь. Филиал обычно успешно работает почти в 100% случаев, поэтому современное оборудование отлично справляется с работой.
Ответ 6
Я предполагаю, что теоретический ответ состоит в том, что массив должен иметь лучшую производительность, потому что общие коллекции имеют дополнительные уровни абстракции. Лично в бизнес-приложении я вижу очень мало смысла в использовании массивов по общим коллекциям.
Ответ 7
В дополнение к другим ответам есть одно тонкое свойство массивов, которое можно считать преимуществом по сравнению с списками. Это можно проиллюстрировать следующим кодом:
//This works
Integer[] ints = new Integer[4];
Number[] nums = ints;
//This doesn't work
List<Integer> intList = new ArrayList<Integer>();
List<Number> numList = intList; //Does not compile
List<Number> numList2 = (List<Number>)intList; //Does not compile either
В то время как массив подкласса IS является массивом суперкласса, списки подклассов НЕ являются списками суперклассов (и для этого есть веская причина - у дженериков был бы дефект типа safery, если бы он был разрешен).
Ответ 8
Массивы лучше в следующих ситуациях:
- вы знаете, что будете работать с фиксированным числом элементов в массиве
- вам не нужно изменять размер массива
Массивы:
- быстрее, чем любая коллекция
Коллекции, подобные массиву:
-
ArrayList
- быстрое чтение и добавление в конец List
. Использует внутренний массив. Медленно, если вам нужно увеличить размер List
-
LinkedList
- быстрое добавление к обеим сторонам List
. Быстрое увеличение/уменьшение динамического размера. Не использует внутренний массив
Вывод:
Я рекомендую использовать соответствующий для вашей коллекции сценарий. Нельзя бороться с Array []
, потому что пакет Collections
предлагает очень удобный API, например add()
, addAll()
и т.д.
Ссылка:
Вы можете найти более подробное сравнение здесь → "Arrays vs ArrayList vs LinkedList vs..."
Ответ 9
Это действительно зависит от ситуации. Массивы невероятно быстрые, но они фиксированного размера, и они могут оказаться непригодными, если количество данных, которые вам нужно обрабатывать, очень велико. Коллекции, с другой стороны, имеют разную степень производительности, в зависимости от конкретного подкласса. Например, ArrayList - это всего лишь оболочка вокруг массива и поэтому должна иметь аналогичную скорость итерации и требования к памяти. Для себя я обычно использую Iterable <T> интерфейс, где это возможно, поскольку это дает максимальную гибкость моему коду, позволяя ему обрабатывать резидентные массивы в памяти, а также списки данных, которые извлекаются из файла или через сеть, используя пользовательский класс iterable/iterator. Когда настало время фактически создать объект Iterable, который я передаю, это зависит от конкретной ситуации; если я знаю размер, и он будет сразу вписываться в память, тогда я просто использую массив, а если он будет расти, то я буду использовать ArrayList, и если ему нужно быструю вставку с обоих концов, то я буду использовать LinkedList.