자바 프로그래밍을 하면서 Vector 클래스 와 Stack 클래스 활용을 지양하는 이유

개요

자바 Collection 인터페이스를 깊게 공부하기 전엔 코딩 테스트 문제에서 Stack 자료구조를 사용해서 문제를 풀어야할 때, 자바에서 제공해주는 Stack 클래스를 활용해서 문제를 풀었다.

하지만, CS와 자료구조 및 자바 공부를 깊게 해보니 실무적인 프로그래밍시엔 Stack 클래스와 Vector 클래스 활용을 지양해야한다는 걸 학습하게 됐다.

이유는 다음과 같다.

 

1. 비효율적인 동기화

Vector와 Stack은 모두 동기화된(synchronized) 클래스이다. 이는 멀티스레드 환경에서 안전하게 사용할 수 있다는 장점이 있으나, 불필요한 동기화로 인해 성능 저하가 발생할 수 있다. 대부분의 경우, 동기화가 필요하지 않기 때문에 이러한 클래스들을 사용하는 것은 비효율적이다. 대신, 비동기화된 ArrayList와 Deque(구현체로는 ArrayDeque를 많이 사용함)를 사용하는 것이 더 낫다.

 

벡터 클래스의 내부 구현

 

Vector 클래스의 동기화는 클래스 내의 거의 모든 메서드가 synchronized 키워드로 보호되기 때문에 발생한다. 이는 Vector의 모든 메서드가 동기화된 블록 내에서 실행된다는 것을 의미하며, 동시에 여러 스레드가 접근할 경우 스레드 안전성을 보장하지만, 성능 저하를 초래한다.

단순히 Vector에 Iterator를 붙여 순차적으로 item들을 탐색하기만 해도 원소탐색 시마다 get() 메서드의 실행을 위해 계속 lock을 걸고 닫으므로 Iterator연산과정 전체에 1번만 걸어주면 될 locking에 쓸데없는 오버헤드가 엄청나게 발생한다.

또한 단일 스레드 환경에선 동기화 처리는 불필요하기 때문에 불필요한 오버헤드가 생긴다.

코딩 테스트 문제 풀이 때도 멀티 스레딩 환경이 아니기 때문에 벡터 클래스나 스택 클래스를 사용하는 것은 불필요한 오버헤드를 야기시킨다.

 

 

스택 클래스 내부 구현

 

스택 클래스는 벡터 클래스를 상속받아 확장된 클래스이다. 스택의 메소드 또한 동기화 처리가 되어 있어서, 벡터 클래스 와 똑같이 불필요한 오버헤드를 야기시킨다.

 

 

2. 더 나은 대안 존재

• Vector 대신 ArrayList 사용: ArrayList는 Vector와 거의 동일한 기능을 제공하지만, 동기화되지 않아 더 가볍고 빠르다. 동기화가 필요한 경우에는 Collections.synchronizedList 메서드를 사용하여 ArrayList를 동기화할 수 있다.

List<Integer> synchronizedList = Collections.synchronizedList(new ArrayList<>());

• Stack 대신 Deque 사용: Stack 클래스는 오래된 클래스이며, 더 유연하고 강력한 Deque 인터페이스(구현체로는 ArrayDeque, LinkedList 등)를 사용하는 것이 좋다. Deque는 스택과 큐의 기능을 모두 지원하며, 더 나은 성능을 제공한다.
  자바에서 Deque를 구현하는 방법은 크게 LinkedList와 ArrayDeque가 있는데, 스택의 size가 엄청 커질 가능성이 있고 size의 변동성이 매우 큰 경우 즉각적인 메모리 공간 확보를 위해선 LinkedList방식이 적절하고, 그렇지 않은 경우는 자체 메모리 소모량이 적고 iterate의 효율이 좋은 ArrayDeque를 사용하면 된다.
  그 외 특수한 상황을 더 고려해보자면, 멀티스레드 환경에서는 java.util.concurrent 패키지의 ConcurrentLinkedDeque클래스를 사용하는게 좋고(Non-blocking을 사용하여 높은 동시성을 제공, 클래스는 내부적으로 락을 사용하지 않고 CAS(compare-and-swap) 같은 저수준 동기화 기법을 사용한다.)
  스택의 size가 제한되어있는 경우에 LinkedBlockingDeque 클래스(블로킹 큐로, 큐가 가득 차거나 비어 있을 때 스레드를 차단하여 안전한 동기화를 제공 한다.)를 사용하는 것을 고려해볼만 하다.

Deque<Integer> stack = new ConcurrentLinkedDeque<>();
Deque<Integer> anotherStack = new LinkedBlockingDeque<>();

 

 

3. 설계상의 문제

Stack 클래스는 Vector를 상속받아 구현되었기 때문에, 상속을 통한 코드 재사용이라는 측면에서 좋은 설계가 아니다. 이는 Liskov Substitution Principle을 위반하는 경우가 많아진다. Deque 인터페이스를 구현한 클래스들은 이러한 문제를 피할 수 있도록 설계되었다.

 

Stack 클래스는 Vector 클래스를 상속받아 구현되었기 때문에, Vector의 모든 메서드를 상속받는다. 이는 Stack 클래스가 Vector 클래스의 메서드를 불필요하게 많이 가지게 됨을 의미한다. 예를 들어, Vector 클래스에는 insertElementAt, removeElementAt 같은 메서드가 있는데, 이러한 메서드는 스택의 LIFO(Last In First Out) 특성에 적합하지 않다.

Stack<Integer> stack = new Stack<>();
stack.push(1);
stack.push(2);
stack.push(3);
System.out.println(stack.get(1));  // 2
stack.set(1, 99);
System.out.println(stack);  // [1, 99, 3]

 

Vector는 랜덤 액세스를 지원하기 때문에 Stack 클래스가 이를 상속받았을 때 스택의 기본 원칙(LIFO)을 위반할 가능성이 있다. 이는 Liskov Substitution Principle(LSP)의 "서브타입은 기반 타입으로 대체 가능해야 한다"는 원칙을 위반하게 되며, Stack 클래스가 좋은 설계가 아님을 나타낸다. 반면, Deque는 스택과 큐의 특성을 명확하게 유지하며, 인덱스를 통한 랜덤 액세스를 지원하지 않기 때문에 이러한 문제를 피할 수 있다. 그래서, 자바 프로그래밍에서 Stack 대신 Deque를 사용하는 것이 바람직하다.

 

결론

자바 프로그래밍에서 Vector와 Stack을 지양해야 하는 이유는 비효율적인 동기화, 더 나은 대안의 존재, 그리고 설계상의 문제들 때문이다. 이러한 이유로, 더 현대적인 ArrayList와 Deque를 사용하는 것이 바람직하다.