Почему Java Vector считается устаревшим классом, устаревшим или устаревшим?
Разве его нельзя использовать при работе с параллелизмом?
И если я не хочу вручную синхронизировать объекты и просто хочу использовать потокобезопасную коллекцию без необходимости делать свежие копии базового массива (как это делает CopyOnWriteArrayList), тогда можно ли использовать Vector?
А как насчет Stack, который является подклассом Vector, что мне использовать вместо него?
Vector синхронизируется по каждой отдельной операции. Это почти никогда не то, чем вы хотите заниматься.
Обычно вы хотите синхронизировать всю последовательность операций. Синхронизация отдельных операций менее безопасна (например, если вы выполняете итерацию по Vector, вам все равно нужно снять блокировку, чтобы никто другой не изменил коллекцию одновременно, что могло бы вызвать ConcurrentModificationException в повторяющемся потоке), но также медленнее (зачем вынимать блокировку повторно, когда будет достаточно одного раза)?
Конечно, у него также есть накладные расходы на блокировку, даже когда вам это не нужно.
По сути, это очень ошибочный подход к синхронизации в большинстве ситуаций. Как заметил г-н Брайан Хенк, вы можете украсить коллекцию с помощью таких вызовов, как _ 4_ - еще один пример - тот факт, что Vector объединяет реализацию коллекции" массив с измененным размером "с битом" синхронизировать каждую операцию ". плохой дизайн; подход к декорированию дает более четкое разделение проблем.
Что касается эквивалента Stack - для начала я бы посмотрел на _7 _ / _ 8_.
Vector менее эффективна с точки зрения ненужной синхронизации, но, выполняя эту синхронизацию, она может создать иллюзию поточной безопасности для пользователей, которые плохо знакомы с потоками и думают, что синхронизации каждой операции достаточно для сделать безопасным произвольное использование между потоками. Я по-прежнему очень рад рекомендовать перейти с Vector на ArrayList почти во всех случаях.
- person Jon Skeet; 10.02.2016
LinkedList<T> лучше, чем ArrayList<T> в некоторых ситуациях, часто верно обратное - ни один из них эффективно не осуждает другой.
- person Jon Skeet; 10.02.2016
Vector официально устарел, заметьте ... точно так же, как Date и Calendar нет, но я тоже не хотел бы использовать их в новых разработках.)
- person Jon Skeet; 10.02.2016
Stack - для начала я бы посмотрел на _2 _ / _ 3_. Есть ли у Stack синхронизированные методы в качестве суперкласса Vector? Должны ли мы заменить Stack на Collections.synchronizedList применительно к Deque/ArrayDeque?
- person ; 21.11.2017
Stack в любом случае будут проходить через методы суперкласса, но мне нужно будет проверить, чтобы быть уверенным.
- person Jon Skeet; 22.11.2017
Vector был частью 1.0 - исходная реализация имела два недостатка:
1. Именование: векторы на самом деле представляют собой просто списки, к которым можно получить доступ как к массивам, поэтому его следовало называть ArrayList (который является заменой коллекций Java 1.2 для Vector).
2. Параллелизм: все get(), set() методы synchronized, поэтому вы не можете иметь точный контроль над синхронизацией.
Между ArrayList и Vector нет большой разницы, но вы должны использовать ArrayList.
Из документа API.
Начиная с платформы Java 2 v1.2, этот класс был модифицирован для реализации интерфейса List, что сделало его членом Java Collections Framework. В отличие от новых реализаций коллекций, вектор синхронизируется.
ArrayList, LinkedList и т. Д., Все из которых реализуют интерфейс List, поэтому, если вы хотите использовать List методы, не зная, какова на самом деле основная реализация, вы можете просто взять List в качестве параметра методов и т. Д. то же самое относится к разработчикам Map и так далее. Между тем, в C ++ есть класс std::array, который является просто заменой на основе шаблонов массивов статической длины в стиле C.
- person JAB; 14.05.2014
Помимо уже заявленных ответов об использовании Vector, Vector также имеет множество методов для перечисления и извлечения элементов, которые отличаются от интерфейса List, и разработчики (особенно те, кто изучал Java до 1.2) могут, как правило, использовать их, если они находятся в код. Хотя перечисления выполняются быстрее, они не проверяют, была ли коллекция изменена во время итерации, что может вызвать проблемы, и, учитывая, что вектор может быть выбран для ее синхронизации - с сопутствующим доступом из нескольких потоков, это делает эту проблему особенно опасной. Использование этих методов также связывает большой объем кода с Vector, так что заменить его другой реализацией List будет непросто.
Вы можете использовать synchronizedCollection / List в java.util.Collection, чтобы получить поточно-безопасную коллекцию из небезопасной для потоков.
java.util.Stack наследует накладные расходы на синхронизацию java.util.Vector, что обычно не оправдано.
Однако он наследует гораздо больше. Дело в том, что java.util.Stack extends java.util.Vector - это ошибка объектно-ориентированного дизайна. Пуристы заметят, что он также предлагает множество методов помимо операций, традиционно связанных со стеком (а именно: push, pop, peek, size). Также возможно выполнение search, elementAt, setElementAt, remove и многие другие операции с произвольным доступом. По сути, пользователь должен воздерживаться от использования операций Stack, не связанных со стеком.
По этим причинам производительности и дизайна ООП JavaDoc для java.util.Stack < / a> рекомендует ArrayDeque в качестве естественной замены . (Двухсторонняя очередь - это больше, чем стек, но, по крайней мере, она ограничена манипулированием двумя сторонами, а не предлагает произвольный доступ ко всему.)
