为什么Java Vector（和Stack）类被认为已过时或已弃用？

本文翻译自：Why is Java Vector (and Stack) class considered obsolete or deprecated?

Why is Java Vector considered a legacy class, obsolete or deprecated? 为什么Java Vector被认为是遗留类，已过时或已弃用？

Isn't its use valid when working with concurrency? 在使用并发时，它的使用是否有效？

And if I don't want to manually synchronize objects and just want to use a thread-safe collection without needing to make fresh copies of the underlying array (as CopyOnWriteArrayList does), then is it fine to use Vector ? 如果我不想手动同步对象并且只想使用线程安全的集合而不需要创建底层数组的新副本（如CopyOnWriteArrayList那样），那么使用Vector是否可以？

What about Stack , which is a subclass of Vector , what should I use instead of it? 那么Stack ，它是Vector一个子类，应该用什么而不是它呢？

---

#1楼

参考：https://stackoom.com/question/5odH/为什么Java-Vector-和Stack-类被认为已过时或已弃用

---

#2楼

您可以使用java.util.Collection上的synchronizedCollection / List方法从非线程安全的集合java.util.Collection获取线程安全集合。

---

#3楼

Vector synchronizes on each individual operation. Vector在每个单独的操作上同步。 That's almost never what you want to do. 这几乎不是你想要做的。

Generally you want to synchronize a whole sequence of operations. 通常，您希望同步整个操作序列 。 Synchronizing individual operations is both less safe (if you iterate over a Vector , for instance, you still need to take out a lock to avoid anyone else changing the collection at the same time, which would cause a ConcurrentModificationException in the iterating thread) but also slower (why take out a lock repeatedly when once will be enough)? 同步单个操作既不安全（例如，如果迭代Vector ，你仍然需要取出一个锁以避免其他人同时更改集合，这会在迭代线程中导致ConcurrentModificationException ）而且慢一点（为什么一旦足够就反复取出锁）？

Of course, it also has the overhead of locking even when you don't need to. 当然，即使你不需要，它也有锁定的开销。

Basically, it's a very flawed approach to synchronization in most situations. 基本上，在大多数情况下，这是一种非常有缺陷的同步方法。 As Mr Brian Henk pointed out, you can decorate a collection using the calls such as Collections.synchronizedList - the fact that Vector combines both the "resized array" collection implementation with the "synchronize every operation" bit is another example of poor design; 正如Brian Henk先生指出的那样，您可以使用Collections.synchronizedList等调用来装饰集合 - Vector将“调整大小的数组”集合实现与“同步每个操作”位相结合，这是设计不佳的另一个例子; the decoration approach gives cleaner separation of concerns. 装饰方法可以更清晰地分离顾虑。

As for a Stack equivalent - I'd look at Deque / ArrayDeque to start with. 至于Stack等价物 - 我会先看看Deque / ArrayDeque 。

---

#4楼

Vector was part of 1.0 -- the original implementation had two drawbacks: Vector是1.0的一部分 - 原始实现有两个缺点：

1. Naming: vectors are really just lists which can be accessed as arrays, so it should have been called ArrayList (which is the Java 1.2 Collections replacement for Vector ). 1.命名：向量实际上只是可以作为数组访问的列表，因此它应该被称为ArrayList （它是Vector的Java 1.2 Collections替代品）。

2. Concurrency: All of the get() , set() methods are synchronized , so you can't have fine grained control over synchronization. 2.并发：所有get() ， set()方法都是synchronized ，因此您无法对同步进行细粒度控制。

There is not much difference between ArrayList and Vector , but you should use ArrayList . ArrayList和Vector之间没有太大区别，但您应该使用ArrayList 。

From the API doc. 来自API文档。

As of the Java 2 platform v1.2, this class was retrofitted to implement the List interface, making it a member of the Java Collections Framework. 从Java 2平台v1.2开始，这个类被改进以实现List接口，使其成为Java Collections Framework的成员。 Unlike the new collection implementations, Vector is synchronized. 与新的集合实现不同，Vector是同步的。

---

#5楼

Besides the already stated answers about using Vector, Vector also has a bunch of methods around enumeration and element retrieval which are different than the List interface, and developers (especially those who learned Java before 1.2) can tend to use them if they are in the code. 除了已经陈述的关于使用Vector的答案之外，Vector还有许多关于枚举和元素检索的方法，这些方法与List接口不同，开发人员（特别是那些在1.2之前学习Java的人）可能倾向于使用它们，如果他们在码。 Although Enumerations are faster, they don't check if the collection was modified during iteration, which can cause issues, and given that Vector might be chosen for its syncronization - with the attendant access from multiple threads, this makes it a particularly pernicious problem. 尽管枚举速度更快，但它们不会检查集合是否在迭代期间被修改，这可能会导致问题，并且考虑到可能会选择Vector进行同步 - 通过多线程的话务员访问，这使得它成为一个特别有害的问题。 Usage of these methods also couples a lot of code to Vector, such that it won't be easy to replace it with a different List implementation. 这些方法的使用也将大量代码耦合到Vector，因此用不同的List实现替换它并不容易。

---

#6楼

java.util.Stack inherits the synchronization overhead of java.util.Vector , which is usually not justified. java.util.Stack继承的同步开销java.util.Vector ，这通常是没有道理的。

It inherits a lot more than that, though. 不过，它继承了很多东西。 The fact that java.util.Stack extends java.util.Vector is a mistake in object-oriented design. java.util.Stack extends java.util.Vector这一事实在面向对象设计java.util.Stack extends java.util.Vector是一个错误。 Purists will note that it also offers a lot of methods beyond the operations traditionally associated with a stack (namely: push, pop, peek, size). 纯粹主义者会注意到它除了传统上与堆栈相关的操作之外还提供了许多方法（即：push，pop，peek，size）。 It's also possible to do search , elementAt , setElementAt , remove , and many other random-access operations. 它还可以执行search ， elementAt ， setElementAt ， remove和许多其他随机访问操作。 It's basically up to the user to refrain from using the non-stack operations of Stack . 基本上由用户决定不使用Stack的非堆栈操作。

For these performance and OOP design reasons, the JavaDoc for java.util.Stack recommends ArrayDeque as the natural replacement. 出于这些性能和OOP设计的原因， java.util.Stack的JavaDoc建议将ArrayDeque作为自然替代品。 (A deque is more than a stack, but at least it's restricted to manipulating the two ends, rather than offering random access to everything.) （deque不仅仅是一个堆栈，但至少它仅限于操纵两端，而不是随机访问所有内容。）