Java 맵 컬렉션 클래스의 소개
Map 인터페이스와 메소드의 이해
Java 코어 클래스에는 여러 가지 사전정의된 Map 클래스가 존재합니다. 구체적인 구현 방식을 설명하기 전에 Map 인터페이스를 살펴보고 모든 Map 클래스가 공유하는 공통점이 무엇인지 이해해 보기로 하겠습니다. Map 인터페이스는 모든 Map이 공통적으로 갖는 네 가지 종류의 메소드를 정의하고 있습니다. 그 중에서 별로 중요하지 않은 두 가지 메소드를 살펴 보기로 하겠습니다.
표 1: 아래 두 가지 메소드는 오브젝트에 의해 오버라이드(override)되며, Map 오브젝트가 동등(equallity) 조건에 의해 비교될 수 있게 합니다.
| equals(Object o) | 지정한 오브젝트과 이 맵의 동등(equality) 조건을 비교합니다 |
| hashCode() | 이 맵의 해시 코드를 리턴합니다. |
맵 빌딩
맵은 엘리먼트를 삽입/제거하기 위한 다양한 뮤테이터(mutator) 메소드를 제공합니다
표 2: 맵 업데이트 메소드: 맵의 컨텐트를 변경하기 위한 메소드.
| clear() | 모든 매핑을 맵으로부터 제거 |
| remove(Object key) | 키와 연계된 값을 맵에서 제거 |
| put(Object key, Object value) | 지정된 값을 지정된 키와 연계(associate) |
| clear() | 모든 매핑을 맵으로부터 제거 |
| putAll(Map t) | 특정 맵에서 이 맵으로 모든 매핑을 복사 |
여기에 별다른 것은 없습니다. 한 가지 참고할 만한 사항은 putAll()이 여러 번의 put() 호출을 사용하는 것보다 효율적인 경우가 드물다는 사실입니다. putAll()을 전달하기 위해 다른 맵을 생성하는데 드는 비용을 고려하지 않더라도 마찬가지입니다. putAll()은 전달된 Map의 각 엘리먼트에 대해 루프를 실행하며, 각각의 키 값을 put()이 실행되는 Map에 추가하는 알고리즘을 실행해야 하기 때문입니다. 하지만 putAll()이 전체 엘리먼트를 추가하기 전에 Map의 크기를 적절하게 설정하는 작업을 수행하는 작업을 수행하므로, 사용자가 직접 Map의 사이즈를 설정하는 것보다 putAll()이 좀더 효율적으로 실행될 수 있음을 참고하시기 바랍니다.
맵의 조회
Map의 각 엘리먼트 별로 알고리즘을 실행하는 방법은 상황에 따라 달라집니다. 특정 쿼리를 만족하는 엘리먼트가 무엇인지 확인하려면, 또는 어떤 이유로든 전체 엘리먼트에 대해 알고리즘을 반복적으로 실행하려면 먼저 Map의 “뷰”를 가져와야 합니다. 뷰에는 크게 3 가지가 있습니다 (표3) 참고
- 전체 키-값 쌍(key-value pair) — entrySet()
- 전체 키 — keySet()
- 전체 값 — values()
앞의 두 가지는 Set 오브젝트를, 마지막은 Collection을 반환합니다. 세 가지 경우 모두 Collection 또는 Set 오브젝트를 직접 반복실행(iterate)할 수는 없으므로, 반복실행을 위한 Iterator 오브젝트를 먼저 가져와야 합니다. 따라서 Map의 여러 엘리먼트에 대해 반복실행을 하기 위해서는 다소 복잡한 구문을 사용해야 합니다.
이 오브젝트들(Set, Collection, Iterator)는 실제로 하부 맵의 뷰로써 존재할 뿐, 전체 엘리먼트의 사본을 포함하고 있지 않다는 점을 참고할 필요가 있습니다. 따라서 조회 작업은 매우 효율적으로 수행됩니다. 반면 Collection 또는 Set의 toArray() 메소드는 Map의 모든 엘리먼트를 포함하는 어레이 오브젝트를 생성하므로, 실제로 어레이 내부의 엘리먼트를 일일이 확인해야 하는 경우가 아니라면 비효율적일 수 있습니다.
아래 예제는 HashMap을 이용하여 간단한 테스트를 실행하고 두 가지 방법을 이용하여 Map 엘리먼트들을 일일이 확인하는데 드는 비용을 비교하고 있습니다 (Test1.java 참고)
이 테스트를 수행하는 방법에는 여러 엘리먼트에 대한 실행 시간을 측정하는 방법과 toArray 호출을 이용하여 어레이를 생성하는데 드는 추가적인 비용을 산출하는 방법이 있습니다. 첫 번째 방법에서 어레이를 생성하는데 소요되는 시간을 무시한다면, Iterator를 이용하는 방법보다 toArray 호출을 통해 기존에 생성된 어레이를 사용하는 방법이 30%-60% 정도 빠릅니다. 하지만, toArray를 사용하여 어레이를 생성하는데 수반되는 오버헤드를 고려한다면, 오히려 Interator가 10%-20% 정도 빠른 성능을 보입니다. 그러므로, 컬렉션으로부터 엘리먼트 어레이를 생성해야 할 필요가 있는 경우라면, 각 엘리먼트 별로 작업을 수행하는 대신 어레이를 사용하는 편이 빠릅니다. 반면에 어레이가 굳이 필요하지 않은 경우라면 어레이를 아예 생성하지 않고 Iterator를 사용하는 것이 바람직합니다
표 3: 뷰를 반환하는 Map 메소드: 아래 메소드들은 Map 엘리먼트를 조회(traverse)하거나 Map의 엘리먼트를 삭제하기 위한 오브젝트를 반환합니다
entrySet()
맵에 포함된 매핑에 대한 Set 뷰를 반환합니다. 셋에 포함된 각 엘리먼트는 Map.Entry 오브젝트로 구성되며, getKey(), getValue() 메소드의 접근을 위한 key/value 엘리먼트를 포함할 수 있습니다(setValue() 메소드도 함께 제공됩니다).
keySet()
맵에 포함된 키에 대한 Set 뷰를 반환합니다. Set에서 엘리먼트를 제거하면 해당되는 매핑(key, value) 역시 Map에서 제거됩니다.
values()
맵에 포함된 값에 대한 Collection 뷰를 반환합니다. Collection에서 엘리먼트를 제거하면 해당되는 매핑(key, value) 역시 Map에서 제거됩니다.
엘리먼트에 대한 접근
맵 액세스를 위한 메소드는 표 4에서 확인하실 수 있습니다. 맵은 (value가 아닌) key를 기준으로 한 액세스에 최적화되는 것이 일반적입니다. 이러한 환경이 Map 정의에 분명히 명시되지는 않지만, 일반적으로 그러하다고 기대할 수 있습니다. 따라서 containsKey() 메소드는 get() 메소드와 유사한 실행 속도를 갖는 것으로 기대할 수 있습니다. 반면 containsValue() 메소드는 맵의 value를 일일이 스캔해야 하므로 훨씬 느린 속도를 보이는 경우가 대부분입니다.
표 4: 맵 액세스 및 테스트를 위한 메소드: Map 컨텐트를 변경하지 않은 상태에서 Map 컨텐트에 대한 정보를 조회하기 위한 메소드입니다.
| get(Object key) | 지정된 키에 관련된 값을 반환합니다. |
| containsKey(Object key) | 맵이 지정된 키에 대한 매핑을 포함하고 있는 경우 True를 반환합니다. |
| containsValue(Object value) | 맵이 지정된 값에 대한 하나 또는 그 이상의 키를 포함하고 있는 경우 True를 반환합니다. |
| isEmpty() | 맵이 key-value 매핑을 전혀 포함하고 있지 않은 경우 True를 반환합니다. |
| size() | 맵에 포함된 key-value 매핑의 수를 반환합니다. |
HashMap에서 containsKey(), containsValue() 메소드를 이용하여 모든 엘리먼트를 테스트하는데 걸리는 시간을 비교해 보면, containsValue()의 실행 시간이 수십 배나 오래 걸림을 확인할 수 있습니다. (참고 Test2.java) 따라서 containsValue()가 애플리케이션의 성능 문제를 유발할 가능성이 매우 높습니다. 이 경우, containsValue() 이외의 다른 대안을 사용하여 보다 효율적인 방법으로 문제를 해결할 수 있을 것입니다. 이러한 대안이 불가능하다면, 첫 번째 Map의 모든 값을 키로 갖는 두 번째 Map을 생성하고, 첫 번째 Map에 대해 containsValue()를 실행하는 대신 두 번째 Map에 containsKey()를 실행하는 방법을 고려해 볼 수 있을 것입니다
코어 맵
Java는 다양한 Map 클래스를 포함하는 형태로 배포됩니다. Map 클래스는 크게 세 가지 종류로 구분됩니다
- 매핑 관리를 위해 애플리케이션에서 사용하는 범용 Map (대부분 java.util 패키지에 구현)
- HashMap
- Hashtable
- Properties
- LinkedHashMap
- IdentityHashMap
- TreeMap
- WeakHashMap
- ConcurrentHashMap
- 직접 생성하는 대신 다른 클래스를 이용하여 액세스하는 특수 목적의 Map
- java.util.jar.Attributes
- javax.print.attribute.standard.PrinterStateReasons
- java.security.Provider
- java.awt.RenderingHints
- javax.swing.UIDefaults
- 별도의 Map 클래스 구현을 지원하기 위한 추상화 클래스
- AbstractMap
해시 매핑 테크닉
대부분의 범용 Map은 해시 매핑(hash mapping)을 사용합니다. 해시 매핑은 엘리먼트를 어레이에 매핑하기 위한 매우 단순한 메커니즘을 제공합니다. Map을 제대로 이해하기 위해서는 먼저 해시 매핑을 이해하는 것이 중요합니다.
해시 맵 구조는 엘리먼트가 저장되는 내부 어레이로 구성됩니다. 내부 저장소가 어레이 형태로 구성되므로, 임의의 키를 이용하여 어레이에 인덱스를 적용하기 위한 메커니즘이 필요합니다. 이 메커니즘은 어레이의 크기보다 작은 어레이 인덱스 값을 생성하는데 사용됩니다. 이러한 메커니즘을 해시 함수(hash function)이라 부릅니다. Java 해시 기반 Map에서, 해시 함수는 임의의 오브젝트를 내부 어레이에 적합한 정수로 변환합니다. 해시 함수를 다른 데서 찾을 필요는 없습니다. 모든 오브젝트는 정수값을 반환하는 hashCode() 메소드를 가지고 있습니다. 이 값을 어레이로 매핑하려면, 값을 양수로 변환한 뒤 어레이 사이즈로 나눈 나머지값을 취하면 됩니다. Java의 모든 오브젝트에 대해 사용 가능한 단순한 해시 함수의 예가 아래와 같습니다.
int hashvalue = Maths.abs(key.hashCode()) % table.length;
(modulo라 불리는 % 바이너리 연산자는 좌항을 우항으로 나눈 후 나머지값으로 남는 정수를 반환합니다.)
실제로 버전 1.4가 출시되기 전까지, 위의 해시 함수가 해시 기반 Map 클래스를 위해 사용되어 왔습니다. 실제 코드는 아래와 같습니다
int hashvalue = (key.hashCode() & 0x7FFFFFFF) % table.length;
이는 양수 값을 얻기 위해 좀 더 효율적인 메커니즘을 사용하고 있을 뿐, 앞에서 예시한 함수와 동일합니다. 버전 1.4가 출시되면서 HashMap 클래스는 Doug Lea의 util.concurrent 패키지를 기반으로 하는 좀 더 복잡한 해시 함수를 사용하게 되었습니다(Doug Lea의 클래스에 대해서는 뒷부분에서 좀 더 자세하게 설명합니다).
그림1 해싱의 동작 원리
지금까지 해시 매핑의 기본적인 원리를 설명했습니다. 하지만 이것으로 설명이 충분한 것은 아닙니다. 해시 함수는 임의의 오브젝트를 어레이의 특정 위치에 매핑시킵니다. 하지만 서로 다른 두 개의 키가 동일한 위치에 매핑되는 경우는 어떻게 해야 할까요? 이러한 현상을 근본적으로 차단할 수 있는 방법은 없습니다. 해시 매핑에서는 이러한 문제를 충돌(collision)이라 부릅니다. 맵에서는 이러한 충돌을 피하기 위해 인덱스 위치에 링크드 리스트(linked list)를 삽입하고, 각각의 엘리먼트를 링크드 리스트에 추가하는 방법을 사용합니다. 따라서 해시 기반 Map의 기본적인 put() 메소드는 아래와 같이 구현됩니다.
다양한 해시 기반 Map의 소스를 살펴보면 그 내용이 서로 상당히 유사하다는 것을 알 수 있습니다. 널 키, 널 값을 처리하는 방법, 내부 어레이의 리사이즈와 같은 별도의 고려사항이 존재하기는 합니다. 위에서 정의된 put() 메소드는 get() 메소드를 위한 알고리즘을 함께 포함하고 있습니다. 삽입 과정에서 키가 이미 존재하는지의 여부를 확인하기 위해 매핑된 인덱스의 엔트리를 검색하는 작업이 필요하기 때문입니다. (get() 메소드는 put()과 동일한 알고리즘을 가지고 있지만 삽입, 덮어쓰기를 위한 코드가 없다는 차이만을 갖습니다.) 링크드 리스트 이외에도 충돌 현상을 방지하기 위한 방법으로, 해시 맵에서 별도의 “open addressing” 접근법이 사용되기도 합니다(본 문서에서는 자세히 다루지 않습니다).
해시맵의 최적화
해시 맵의 내부 어레이가 단 하나의 엘리먼트만으로 구성되어 있다면, 모든 엔트리는 동일한 어레이 위치의 링크드 리스트에 삽입되어야 할 것입니다. 이 방법은 매우 비효율적입니다. 링크드 리스트에 대한 선형 검색을 이용한 액세스 또는 업데이트는 각각의 어레이 인덱스가 하나의 오브젝트만을 가진 경우보다 훨씬 느립니다. 링크드 리스트의 액세스/업데이트 속도는 리스트의 사이즈에 정비례하는 반면, 해시 함수를 이용하여 어레이의 단일 엘리먼트를 액세스/업데이트하는 속도는 어레이 사이즈와 무관합니다. 점근적 성능(asymptotic performance, Big-O notation)의 용어에 대응시킨다면 전자는 O(n)이고 후자는 O(1)이 됩니다. 따라서 여러 엔트리가 동일한 어레이 위치에 집중되는 것을 방지하고 어레이의 사이즈를 크게 잡는 것이 유리합니다.
Map의 리사이즈
해시에서 각각의 내부 어레이 위치를 “버킷(bucket)”이라 부르고, 사용 가능한 버킷의 수(내부 어레이의 사이즈)를 용량(capacity)이라 부릅니다. Map 오브젝트가 임의의 수의 엔트리를 효과적으로 처리하게 하려면, 맵의 리사이즈가 가능해야 합니다. 하지만 리사이즈 작업은 매우 많은 비용이 필요합니다. 어레이의 사이즈가 바뀌면 인덱스 값 또한 바뀔 수 밖에 없기 때문에 리사이즈 과정에서 모든 엘리먼트를 새로운 어레이에 다시 삽입해야 합니다. 이전에 충돌하던 키들이 서로 충돌하지 않는 반면, 이전에는 충돌하지 않던 키들이 서로 충돌할 수 있습니다. Map을 충분한 크기로 늘리는 경우, 충돌의 가능성을 최소화할 수 있으며 따라서 극적인 성능 향상이 가능합니다.
1.4.2 JVM에서 많은 수의 엔트리(백만 개 이상)를 HashMap에 추가하는 간단한 테스트를 수행해 보았습니다. 표 5는 그 결과를 보여 주고 있으며, 모든 시간은 ‘pre-sized 서버 모드’에 정규화되었습니다(참고Test3.java). pre-sized JVM의 경우 클라이언트/서버 모드 JVM 모두 동일한 시간을 보입니다(JIT 컴파일 단계의 시간은 계산하지 않았습니다). 하지만 Map의 디폴트 사이즈를 사용하는 경우에는 여러 차례 리사이즈 작업이 발생하며 그 비용은 상당합니다. 서버 모드의 경우 50%나 증가하였으며, 클라이언트 모드와 비교했을 때는 3배나 많은 시간이 걸렸습니다!
표 5: pre-sized HashMap과 default sized HashMap에 엔트리를 추가하는데 소요되는 시간
| Client mode | Server mode | |
| Pre-sized large | 100% | 100% |
| Default size | 294% | 157% |
Load Factor의 사용
각 버킷의 링크드 리스트 사이즈를 추적하지 않고도 리사이즈가 필요한 시점을 결정할 수 있도록 하기 위해, 해시 기반 Map은 별도의 매개변수와 계산식을 이용하여 버킷의 밀집도를 측정합니다. Map은 “로드 팩터(load factor)”라 불리는 매개변수를 이용하며, 로드 팩터는 Map에 리사이즈가 수행되기 전에 얼마나 많은 “로드” 작업이 허용되는지를 결정하는데 사용됩니다. 로드 팩터, 엔트리의 수(맵 사이즈), 용량의 관계는 아래와 같이 정의됩니다.
- (load factor) x (capacity) > (map size)인 경우 맵은 리사이즈 된다.
예를 들어, 디폴트 로드 팩터가 0.75이고 디폴트 용량이 11이면 11 x 0.75 = 8.25가 됩니다. 이 값에 버림을 적용하면 8 개의 엘리먼트를 얻습니다. 따라서 이 Map에 8 개째의 엔트리를 추가하는 시점에 Map은 보다 큰 용량으로 리사이즈 됩니다. 역으로, 리사이즈를 피하기 위해 초기 용량을 계산할 때에는 추가되는 엔트리의 수를 로드 팩터로 나누고 그 결과에 올림을 적용하면 됩니다.
- 로드 팩터가 0.75일 때 100 개의 엔트리를 추가하려면, 용량은 100/0.75 = 133.33, 이 결과에 올림을 적용하여 134 (또는 홀수 값이 필요한 경우 135)
홀수 값을 갖는 버킷 사이즈는 충돌의 가능성을 줄여주므로 보다 효율적입니다. 소수(素數)를 적용하는 것이 이상적이지만, 실제로 테스트해 보면 소수가 항상 최상의 결과를 보여 주는 것은 아닙니다(참조Test4.java). 버전 1.4 이후의 일부 Map(예: HashMap과 LinkedHashMap (Hashtable과 IdentityHashMap은 제외))은 2n의 용량을 필요로 하는 해시 함수를 사용하지만, 이러한 Map은 결과값에 가장 근사한 2n 값을 자동으로 계산하므로, 별도의 계산 작업이 불필요합니다.
로드 팩터는 시간과 공간의 조율을 위한 변수입니다. 로드 팩터가 작으면 공간을 더 많이 차지하지만 충돌의 가능성이 적어지므로, 액세스/업데이트가 빨라집니다. 0.75 이상의 로드 팩터는 일반적으로 권장되지 않으며, 로드 팩터 1.0은 최소한 하나 이상의 충돌 가능성을 담보합니다. 로드 팩터가 0.50 이하로 내려가면 그 효과는 점차적으로 약해지지만, 맵 사이즈를 효과적으로 관리하는 이상 작은 로드 팩터가 (메모리 비용을 제외하고) 성능에 부정적인 영향을 미칠 가능성은 없습니다. 하지만 Map의 사이즈를 충분히 크게 설정해 놓지 않은 상태라면, 로드 팩터가 작으면 작을 수록 리사이즈가 더욱 빈번하게 발생하고 성능 저하 현상으로 연결될 수 있습니다.
적절한 맵의 선택
그렇다면 어떤 맵을 사용해야 할까요? 동기화가 필요할까요, 그렇지 않을까요? 애플리케이션의 최적화된 성능을 보장하기 위해 가장 중요한 두 가지 고려사항이 바로 이 두 가지입니다. 범용 Map을 사용하는 경우에는 맵 사이즈와 로드 팩터의 두 가지 튜닝 옵션만으로 대부분의 문제를 해결할 수 있습니다.
최적의 Map 성능을 얻기 위한 방법이 아래와 같습니다.
- 모든 Map 변수를 Map으로 선언합니다(다시 말해, HashMap, Hashtable과 같은 다른 Map 클래스를 사용하지 않습니다.)
Map criticalMap = new HashMap(); //GOOD
HashMap criticalMap = new HashMap(); //BAD
이와 같이 선선하면 코드의 한 라인만 수정함으로써 특정 Map 인스턴스를 쉽게 대체할 수 있습니다.
- Doug Lea의 util.concurrent 패키지를 다운로드합니다. (http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html) ConcurrentHashMap을 디폴트 Map으로 사용합니다. 1.5 릴리즈로 이전하는 경우, 디폴트Map을 java.util.concurrent.ConcurrentHashMap으로 변경합니다. 멀티-쓰레드 환경이라 하더라도 Synchronized wrapper를 이용하여 ConcurrentHashMap을 래핑하지 않습니다. 디폴트 사이즈와 로드 팩터를 그대로 사용합니다.
- 애플리케이션 프로파일링을 수행합니다. Map이 성능 병목으로 작용하는 경우, 그 원인을 분석하고 Map 클래스, Map 사이즈, 로드 팩터, 키 오브젝트 equals() 메소드 등에 관련한 설정 변경을 시도합니다. 범용적이지 않은 특수 목적의 Map 활용 시에는 예외 없이 특수 목적의 커스텀 Map 구현 방식이 필요하지만, 그렇지 않은 경우라면 범용적인 Map을 이용하여 원하는 성능 목표를 달성할 수 있을 것입니다.
맵의 선택
어쩌면 여러분들은 좀 더 복잡한 설명을 기대하고 있을지도 모르겠습니다. 조금 여유를 갖고 접근해 봅시다. 먼저, 어떤 Map을 사용해야 할까요? 그 답은 매우 간단합니다. 특정 Map 유형을 필요로 하는 실질적인 설계 요구사항이 도출되기 전까지는 Map을 선택하지 않습니다. 구체적인 Map 구현 방식은 일반적으로 설계 단계에서 결정되지 않습니다. Map이 필요하다는 사실은 알더라도, 어떤 Map이 필요한지는 모를 수 있습니다. Map 인터페이스가 필요한 이유가 바로 여기에 있습니다. 필요한 시점까지 Map 구현 방식의 결정을 미루는 것이 좋습니다. 또 “Map” 선언 변수를 올바르게 활용하였다면, 라인 하나만 변경함으로써 특정 Map의 구현 방식을 변경할 수 있을 것입니다. 이것은 매우 적은 비용을 수반하는 튜닝 방법입니다. 그렇다면 디폴트 Map 구현 방식은 무엇을 선택해야 할까요? 여기에 대해서는 곧 설명하겠습니다.
맵의 동기화
그렇다면 동기화 여부는 어떻게 결정할 수 있을까요? (동기화를 위해서는 synchronized Map을 사용하거나 Collections.synchronizedMap()을 이용하여 unsynchronized Map dmf synchronized Map으로 변환해야 합니다. 두 번째 테크닉에서는 “synchronized wrapper”가 사용됩니다.) 이것은 매우 복잡한 문제입니다. Map이 멀티-쓰레드 동시 액세스/업데이트를 위해 사용될 것인지의 여부를 고려해야 하며, 이와 별도로 유지보수에 관련한 고려가 필요합니다. 예를 들어, 동시 업데이트를 고려하지 않고 Map을 시작하였다가, 나중에 동시 업데이트가 필요해지는 경우를 고려해 봅시다. 이러한 상황이라면, unsynchronized Map으로 시작하였다가 나중에 애플리케이션에 동시 업데이트 쓰레드를 추가하는 시점에 synchronized로 변경하는 방법을 사용할 가능성이 매우 높습니다. 이러한 작업은 애플리케이션의 손상을 초래하며, 이러한 형태의 버그는 그 원인을 확인하고 추적하기가 가장 어렵습니다.
하지만 디폴트로 synchronized Map을 선택하고 멀티-쓰레드 애플리케이션의 실행을 순차화(serialize)하는 경우에는 심각한 성능 저하를 경험하게 됩니다. 해답을 찾기는 무척 어려운 것처럼만 보입니다.
Doug Lea는 뉴욕 주립대학의 컴퓨터 과학 교수입니다. 그는 util.concurrent라 통칭되는 몇 가지 퍼블릭 도메인 패키지를 생성하였으며, 이 패키지에는 고성능 동시 접속 프로그램을 단순화하기 위한 여러 가지 유틸리티 클래스가 포함되어 있습니다. 이 클래스에 포함된 두 가지 Map으로 ConcurrentReaderHashMap과 ConcurrentHashMap이 있습니다. 이 Map 구현방식은 쓰레드로부터 안전(thread-safe)하며, 동시 액세스/업데이트를 위해 동기화를 요구하지 않을 뿐 아니라, Map을 필요로 하는 대부분의 상황에서 유용하게 활용됩니다. 또 이 Map들은 Hashtable과 같은 synchronized Map이나 synchronized wrapper를 사용하는 방식보다 훨씬 더 뛰어난 확장성을 제공하며, HashMap과 비교했을 때의 성능적인 손실은 매우 적은 수준입니다. utl.concurrent 패키지는 1.5 Java 릴리즈를 위한 동시성 유틸리티의 개발을 추진해 온 JSR166의 기반을 이루고 있으며, 1.5 릴리즈는 이 Map을 새로운 java.util.concurrent 패키지에 포함하게 될 것입니다.
결론적으로 synchronized/unsynchronized Map을 선택하기 위해 복잡한 결정 과정을 거칠 필요는 없으며, ConcurrentHashMap을 사용하기만 하면 됩니다. 물론 ConcurrentHashMap이 적합하지 않은 경우도 있을 수 있습니다. 하지만 이러한 경우의 가능성은 극히 적으며 각 케이스 별로 별도로 해결하는 것이 바람직합니다.
저자 - Jack Shirazi
출처 한국오라클
