unidimensionales - ¿Por qué la clase Vector Java(y la pila) se considera obsoleta o en desuso?
guardar datos en un arreglo java (5)
Además de las respuestas ya establecidas sobre el uso de Vector, Vector también tiene un montón de métodos para la enumeración y recuperación de elementos que son diferentes a la interfaz de la Lista, y los desarrolladores (especialmente aquellos que aprendieron Java antes de 1.2) tienden a usarlos si están en el código. Aunque las enumeraciones son más rápidas, no comprueban si la colección se modificó durante la iteración, lo que puede causar problemas, y dado que se podría elegir a Vector para su sincronización, con el acceso de varios subprocesos, esto lo convierte en un problema particularmente pernicioso. El uso de estos métodos también combina una gran cantidad de código con Vector, por lo que no será fácil reemplazarlo con una implementación de Lista diferente.
¿Por qué Java Vector se considera una clase heredada, obsoleta o en desuso?
¿No es válido su uso cuando se trabaja con concurrencia?
Y si no quiero sincronizar manualmente los objetos y solo quiero usar una colección segura para subprocesos sin tener que hacer copias nuevas de la matriz subyacente (como CopyOnWriteArrayList hace CopyOnWriteArrayList ), ¿está bien usar Vector ?
¿Qué pasa con Stack , que es una subclase de Vector , qué debo usar en lugar de él?
Puede usar el método synchronizedCollection/List en java.util.Collection para obtener una colección segura para subprocesos de una no segura para subprocesos.
Vector fue parte de 1.0 - la implementación original tenía dos inconvenientes:
1. Nombramiento: los vectores son realmente solo listas a las que se puede acceder como arrays, por lo que debería haberse llamado ArrayList (que es el reemplazo de Java 1.2 Collections para Vector ).
2. Concurrencia: todos los métodos get() , set() están synchronized , por lo que no puede tener un control preciso sobre la sincronización.
No hay mucha diferencia entre ArrayList y Vector , pero debe usar ArrayList .
Desde el documento API.
A partir de la plataforma Java 2 v1.2, esta clase se modificó para implementar la interfaz de lista, por lo que es un miembro de Java Collections Framework. A diferencia de las nuevas implementaciones de colecciones, Vector está sincronizado.
Vector sincroniza en cada operación individual. Eso es casi nunca lo que quieres hacer.
Generalmente quieres sincronizar una secuencia completa de operaciones. La sincronización de las operaciones individuales es menos segura (si itera sobre un Vector , por ejemplo, todavía necesita sacar un bloqueo para evitar que alguien más cambie la colección al mismo tiempo, lo que causaría una excepción de modificación ConcurrentModificationException en el hilo de iteración) pero también más lento (¿por qué sacar un candado repetidamente cuando una vez será suficiente)?
Por supuesto, también tiene la sobrecarga de bloqueo incluso cuando no es necesario.
Básicamente, es un enfoque muy defectuoso para la sincronización en la mayoría de las situaciones. Como lo señaló el Sr. Brian Henk , puede decorar una colección utilizando las llamadas como Collections.synchronizedList ; el hecho de que Vector combine la implementación de la colección "redimensionada" con el bit "sincronizar cada operación" es otro ejemplo de diseño deficiente; El enfoque de la decoración da una separación más limpia de las preocupaciones.
En cuanto a un equivalente de Stack , miraría a Deque / ArrayDeque para empezar.
java.util.Stack hereda la sobrecarga de sincronización de java.util.Vector , que generalmente no está justificada.
Sin embargo, hereda mucho más que eso. El hecho de que java.util.Stack extends java.util.Vector es un error en el diseño orientado a objetos. Los puristas notarán que también ofrece una gran cantidad de métodos más allá de las operaciones tradicionalmente asociadas con una pila (a saber: push, pop, peek, size). También es posible realizar search , elementAt , setElementAt , remove y muchas otras operaciones de acceso aleatorio. Básicamente, es responsabilidad del usuario abstenerse de usar las operaciones no apiladas de Stack .
Por estos motivos de rendimiento y diseño de POO, el JavaDoc para java.util.Stack recomienda ArrayDeque como el reemplazo natural. (Un deque es más que una pila, pero al menos está restringido a manipular los dos extremos, en lugar de ofrecer acceso aleatorio a todo).