Java – Collection – Map – ConcurrentHashMap

> Thread-Safe ?

  동기화(Synchronize)라고 표현하기도 하며 어떠한 Class의 인스턴스가 여러개의 Thread에서 동시 참조되고 해당 객체에 Operation 이 발생해도 정합성을 유지해줄때 보통 우리는 Thread-Safe 하다 라고 표현한다.  @ThreadSafe 어노테이션을 이용해 해당 Class가 Thread-Safe 함을 표시하기도 한다.   어떠한 경우에도 개발자가 의도한대로 정확하게 동작한다라고도 이야기 할 수 있다.  참조하는(사용하는) 쪽에서 특별한 동기화 없이도 정확히 동작한다는 것을 이야기한다.  멀티 Thread 환경에서는 필수 적인 요소이다.  Java에서 Thread-Safe 를 이루는 방향 및 조건은 여러 가지가 있으나 이번 Post에는 따로 소개하지는 않는다.


> ConcurrentHashMap

  검색과 갱신 전체에 걸쳐 Thread-Safe 함을 보장하면서도 높은 성능을 보장하는 HashMap 이다.  HashMap처럼 기본적으로는 Hashtable 과 동일한 Spec을 제공한다.   Hashtable 또한 Thread-Safe를 보장한다. 그러나 차이점은 모든 작업이 Thread-Safe 임에도 불구하고 검색작업(get과 같은)에는 Lock이 수반되지 않으며, 전체 테이블을 잠궈야 하는 액션도 없다.  
  ConcurrentHashMap의 검색 작업(get 포함)은 Lock이 이루어지지 않으며 갱신 작업(put 및 remove 포함)과 동시에 수행 될 수 있다.  반대로 Hashtable 의 내부 코드를 살펴보면 Thread-Safe를 보장하는 방법으로 put, get 등의 검색 및 갱신 작업의 method 레벨에서 synchronized 키워드를 사용한다.  이는 간편하게 동시접근을 막아 Thread-safe 를 보장하는 방법 중 하나이다.  그러나 method 레벨에서 synchronized 키워드를 이용하면 Lock의 매개로 활용객체가 바로 객체바로 자신이 된다(this).  이는 전체적인 성능 저하를 가져온다.  어느 한 순간에 Lock이 설정된 어떤 method도 하나의 Thread만이 진입할 수 가 있게 된다. (누군가 get으로 Lock을 획득 중이면, put도 진입할 수가 없다.)

 ConcurrentHashMap의 검색은 검색 method가 실행되는 시점에 가장 최근에 완료된 갱신 작업의 결과를 반영한다.  putAll 및 clear와 같은 집계 작업의 경우 동시 검색에는 해당 시점에 put / remove 중인 일부 항목만 반영될 수 있다.  마찬가지로, iterator, Spliterator, Enumeration 수집 생성 시점 또는 이후 어느 한 시점의 상태를 반영하는 요소를 반환한다.  Hashtable에서 활용되던 ConcurrentModificationException은 이제 더이상 사용되지 않는다.  


> ConcurrentHashMap의 활용 예

 멀티 Thread 환경에서의 Thread-safe 한 Counter  (computeIfAbsent 사용)

import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.*;
import java.util.concurrent.atomic.LongAdder;

public class ConcurrentHashMapTest {
	public static void main(String[] args) {
		int loopSize = 30;
		CountDownLatch countDownLatch = new CountDownLatch(loopSize);
		ExecutorService tp = Executors.newFixedThreadPool(10);

		Map<String, LongAdder> testMap = new HashMap<>();

		for(int i = 0; i < loopSize; i++) {
			int selector = (i % 3);
			String type = (selector == 0) ? "HR" : (selector == 1) ? "SALES" : "IT";
			tp.submit(new Runner(type , countDownLatch, testMap));
		}

		try {
			countDownLatch.await();
		} catch (InterruptedException e) {
			e.printStackTrace();
		}

		System.out.println(testMap.toString());
		tp.shutdown();
	}

	static class Runner implements Runnable {
		private final String runnerNo;
		private final CountDownLatch countDownLatch;
		private Map<String, LongAdder> testMap;
		Runner(String runnerNo, CountDownLatch countDownLatch, Map<String, LongAdder> testMap){
			this.runnerNo = runnerNo;
			this.countDownLatch = countDownLatch;
			this.testMap = testMap;
		}
		@Override
		public void run() {
			try {
				testMap.computeIfAbsent(runnerNo, (value) -> new LongAdder()).increment();
			} catch (Exception e){
				e.printStackTrace();
			} finally {
				countDownLatch.countDown();
			}

		}
	}
}

ExecutorService를 이용해 30개의 Thread를 동시에 수행한다.  Thread 동시 시작을 위해 CountdownLatch가 활용되었다. 

12Line을 살펴보면 각 Thread에서 공유할 Map의 구현체를 HashMap을 사용하였다.   Thread에서는 생성자로 입력받은 Type을 Key로 같는 Map 의 Value를 LongAdder(Counter)로 활용한다.

Thread가 모두 종료되면 해당 Map의 내용을 출력한다.  Java 8 부터 추가된 computeIfAbsent를 이용해 값이 없으면 생성(new LongAdder()) 하고 있을 경우 Count (increment()) 한다.

30개의 Thread에 각 각 10개씩 Type String 값을 “HR”, “SALES”, “IT” 라고 할당해주었기 때문에 Count 값 역시 10개씩 출력되어야 한다.

먼저 HashMap을 이용했을때의 결과를 살펴보자.  


HashMap 결과

  • 1회차
{HR=7, IT=8, SALES=8}

Process finished with exit code 0
  • 2회차
{SALES=8, HR=7, IT=8}

Process finished with exit code 0
  • 3회차
{HR=9, IT=10, SALES=10}

Process finished with exit code 0

해당 결과는 역시 Non-ThreadSafe 의 전형을 보여준다. 

이제, 구현체를 ConcurrentHashMap으로 변경 후 다시 한번 결과를 살펴보자.  ( 12Line : new HashMap<>(); -> new ConcurrentHashMap<>(); )


ConcurrentHashMap 결과

{HR=10, IT=10, SALES=10}

Process finished with exit code 0

몇번을 수행해도 결과는 같다. 

 ConcurrentHashMap이 Thread-safe 하다 하더라도, 여러개의 Action (예 : get 수행 후 없을 경우 put 과 같은) 을 수행 할 경우까지 보장하지는 않는다.

이러한 경우를 위해 Java 8 이후에는 여러 가지 복합 작업을 수행할 수 있는 method를 제공해준다.  computeIfAbsent 는 그 중 하나이다.

Java – Collection – Map – WeakHashMap (약한 참조 해시맵)

> Weak Reference 

  WeakHashMap의 작동 방식을 이해하려면 JVM의 GC와 관련하여 WeakReference  를 조금은 이해할 필요가 있다.  Java에서는 세 가지 주요 유형의 참조(Reference) 방식이 존재한다.   

  1. 강한 참조 (Strong Reference)
    – Integer prime = 1;   와 같은 가장 일반적인 참조 유형이다.    prime 변수 는 값이 1 인 Integer 객체에 대한 강한 참조 를가진다.  이 객체를 가리키는 강한 참조가 있는 객체는 GC대상이 되지않는다.

     

  2. 부드러운 참조 (Soft Reference)
    – SoftReference<Integer> soft = new SoftReference<Integer>(prime);   와 같이 SoftReference Class를 이용하여 생성이 가능하다.  만약 prime == null 상태가 되어 더이상 원본(최초 생성 시점에 이용 대상이 되었던 Strong Reference) 은 없고 대상을 참조하는 객체가 SoftReference만 존재할 경우 GC대상으로 들어가도록 JVM은 동작한다.   다만 WeakReference 와의 차이점은 메모리가 부족하지 않으면 굳이 GC하지 않는 점이다.  때문에 조금은 엄격하지 않은 Cache Library들에서 널리 사용되는 것으로 알려져있다.

     

  3. 약한 참조 (Weak Reference)
    – WeakReference<Integer> soft = new WeakReference<Integer>(prime);   와 같이 WeakReference Class를 이용하여 생성이 가능하다.  prime == null 되면 (해당 객체를 가리키는 참조가 WeakReference 뿐일 경우) GC 대상이 된다.  앞서 이야기 한 내용과 같이 SoftReference와 차이점은 메모리가 부족하지 않더라도 GC 대상이 된다는 것이다.    다음 GC가 발생하는 시점에 무조건 없어진다.

 

> WeakHashMap

  일반적인 HashMap의 경우 일단 Map안에 Key와 Value가 put되면 사용여부와 관계없이 해당 내용은 삭제되지 않는다.  Map안의 Element들이 일부는 사용되고 일부는 사용되지 않을 수 있는 경우도 있으나, 그것의 구현은 전적으로 프로그래머에 달려있게 된다.  예를 들면 Key에 해당하는 객체가 더이상 존재하지 않게 되는 경우이다.  그래서 만약 어떤 객체가 null이 되어 버리면 해당 객체를 key로 하는 HashMap의 Element도 더이상 꺼낼 일이 없는 경우가 발생하는 것을 가정해볼 수 있다.

  WeakHashMap은 WeakReference의 특성을 이용하여 HashMap의 Element를 자동으로 제거, GC 해버린다.   Key에 해당하는 객체가 더이상 사용되지 않는다고 판단되면 제거한다는 의미이다.    아래의 사용예를 보자.

public class WeakHashMapTest {

    public static void main(String[] args) {
        WeakHashMap<Integer, String> map = new WeakHashMap<>();

        Integer key1 = 1000;
        Integer key2 = 2000;

        map.put(key1, "test a");
        map.put(key2, "test b");

        key1 = null;

        System.gc();  //강제 Garbage Collection

        map.entrySet().stream().forEach(el -> System.out.println(el));

    }
}

결과  (null 로 할당된 key1이 Map 내에서 사라졌다.)

2000=test b

Process finished with exit code 0


이 클래스는 주로 equals 메소드가 == 연산자를 사용하는 Key를 사용할 경우 유용하다.  그런 Key가 버려지면 결코 동일한 Key는 생성되지 않으므로,  나중에 WeakHashMap 에서 해당 키의 조회를 수행하는 것은 불가능하게 되기 때문이다.  그러나 Key가 String 과 같이 단일 값을 가지는 Class고 == 연산자 외에 equals를 사용하여 서로 다른 객체라도 동일성을 체크하여 유지 하고 싶은 경우 적절하지 않다. 

WeakHashMap은 HashMap과 마찬가지로 Thread-safe하지 않으며 필요할 경우 Collections.synchronizedMap 을 이용할 수 있다.


주의점 1 – String은 new가 아닌 리터럴 방식으로 생성될 경우 (String a = “abc”; 와 같이)  intern()에 의해 String pool을 JVM은 사용하므로 key가 null이 된다고 하도 WeakHashMap은 자동으로 삭제되지 않는다.   이는 Integer 와 같은 Class의 (-127 ~128) 값들도 마찬가지 이다.  JVM은 미리 불변 객체로 해당 값을 보관하고 있다.  (Strong 참조)


주의점 2 – WeakHashMap 내의 Value는 통상 강한 참조에 의해 보관 유지된다.  따라서 Value 객체가 직접 또는 간접적으로 자신의 Key를 강한 참조하지 않도록 주의해야한다.  그러면 키가 삭제되지 않기 때문이다.  Value 객체는 WeakHashMap 자체 를 통해 간접적으로 키를 참조 할 수 있다.   만약 Key를 참조하는 Value를 사용하여 WeakHashMap 또한 올바르게 동작하길 원한다면 WeakReferences 내에서 Value를 다시 래핑하는 방식을 써야 한다.  [  예 : m.put (key, new WeakReference (value)) ]

Java – Collection – Map

> Map (Interface)

  Map의 가장 기본 개념은 Key를 Value에 매핑하는 자료의 한 구조란 것 이다.  Key는 중복될 수 없으며, 각 Key는 하나의 Value(객체)만을 가질 수 있다.   이는 Map안에 존재하는 Key로 재차 삽입(put)할 경우 해당 Value는 덮어쓰기 된다는 걸 의미하기도 한다.  Map interface의 구현체들은 (put, get, remove, containsKey, containsePlue, size, empty)와 같은 기본 작업을 구현한다.  결국 Map은 Key를 이용해 Value를 쉽게 얻고자 할 때 사용한다. 

  Map은 기본적으로 List, Set과 같은 Java Collection과는 다르게, Collection Interface를 구현하지 않는다.  하지만, Data를 삽입(add or put)하고 삭제(remove)하는 등의 일반적인 자료구조의 형태를 가지고 있다는 점에서 유사하다.

 

> Hashtable

  가장 처음으로 등장한(JDK 1.0)  Map의 종류이다. 내부 적으로는 Entry라는 버킷을 만들어 배열형태로 자료들을 저장한다. Hashtable은 기본적으로 Thread-safe하다. (동기화, synchronized)  또한 Null Key와 value를 허용하지 않는다.  

 실제로는 Hashtable은 최초로 등장한 Map이기에 이전 Java 결과물들의 지원을 위해 존재하는 이상의 의미를 현재는 가지질 않는다.   Java API Document에서도 Thread-safe 한 구조가 필요하지 않을 경우 HashMap의 사용을 권장하고 있다.   설사 Thread-safe한 구조 필요하다해도 ConcurrentHashMap을 사용하도록 권장한다. 

 hashCode와 equals를 이용하고 내부 버킷을 운용하는 방법은 HashMap과 유사하므로 해당 내용은 HashMap에서 설명하도록 하겠다.

 

> HashMap

  HashMap은 Null Key & value를 허용한다. HashMap은 동기화되지 않고 Null을 허용한다는 점을 제외하고는 Hashtable과 거의 동일하다.   HashMap은 Element 들의 순서를 보장하지 않는다.

  hashTable의 원리는 Element가 될 Class의 hashCode() 메서드를 이용해 Hash 값을 알아낸 후, 해당 Hash값으로 내부 버킷의 배열 인자(index)를 결정, 분배하여 저장한다.   그리고 알고 있겠지만 동일한 Index로 분배가 될 경우(HashCrash) 해당 Index를 인자로 가지는 배열 멤버는 LinkedList와 같은 형태로 동일한 Index Element를 관리한다.  또한 HashMap의 구현에서는 해당 동일한 Index로 배정된 Element의 갯수가 8개 이상되면 그 Index만 TreeNode 형태로 변화한다.  (Red-black binary search tree)

  HashMap의 성능에 영향을 미치는 두가지 매개 변수가 있다.  (1) Capacity는 HashTable의 배열 크기이다 (초기 default 16).  (2) LoadFactor는 Capacity가 자동으로 증가하기 전에 HashTable이 얼마나 가득 찼는지를 나타내는 측도이다.   Element의 갯수가 LoadFactor 및 현재 Capacity를 초과하면 2배로 resize가 일어나며 내부 Element들은 다시 Index를 부여 받아 분배된다.

  일반적으로, Default loadFactor (0.75)는 시간과 공간 비용 사이에서 좋은 절충을 제공한다.  값이 높을수록 공간 오버 헤드는 감소하지만 조회 비용은 증가한다. 초기 Capacity를 설정할 때는 ReHashing 작업 수를 최소화하기 위해 예상되는 Element 갯수와 loadFactor를 고려해야 한다.  초기 Capacity가 삽입된 Element 갯수를 LoadFactor로 나눈 값보다 큰 경우에는 ReHasing 작업은 수행되지 않는다.

  많은 Element를 HashMap에 저장해야 하는 경우 충분한 Capacity를 초기 값으로 생성하면 resize 오버헤드를 줄일 수 있다.  또한 Element가 되는 객체의 hashCode() 메서드가 제대로 구현되도록 해서 동일한 Hash값이 발생하는걸 줄임으로 HashMap의 성능을 높일 수 있다. 

 

> TreeMap

Red-black binary search tree 자료구조를 표현한다.  Key의 Natural ordering에 따라 순서가 정해지며, 필요할 경우 생성자에 제공된 Comparator에 의하여 정렬 순서가 정해지도록 할 수 있다.

TreeMap은 키를 정렬 가능한 순서에 따라 저장하기 떄문에 hashCode() 메서드는 전혀 사용되지 않는다.  또한 TreeMap은 Red-black tree의 특성 대로 검색, 삭제, 삽입 모든 동작들이 O(log n)의 처리 성능을 가진다.

HashMap과의 주된 차이는 순서를 보장함에 따라 Iterator를 활용해 순서대로 순회가 가능하다는 것이다.

 

> LinkedHashMap

HashMap을 상속하여 구현되었다.  LinkedHashMap은 멤버가 되는 Element들이 doubly-linked (이중링크) 되었다는 점에서 HashMap과 차이가 있다.   Link는 삽입된 순서대로 Iteration 할 수 있게 생성된다.   동일한 Key를 Map에 다시 삽입하는 경우에는 삽입 순서는 영향을 받지 않는다. (containsKey(k) true 일때,  put(k, v) 가 호출되면 k가 다시 삽입된다.)

HashMap과 동일하게 LinkedHashMap도 성능에 영향을 미치는 두가지 매개 변수가 있다. (HashMap 참조, Capacity/Loadfactor) 다만, iteration time은 Capacity에 영향을 받지 않기 때문에, Capacity를 지나치게 높게 선택했을 경우의 페널티는 HashMap의 경우보다 덜 심각하다.

 

 

Java – Collection – Set

> Set (Interface)

  Set 은 중복 Element를 허용하지 않는 Collection의 종류이다.  또한 Set을 구현한 자료형들은 서로 equals와 hashCode를 이용하여 비교할 수 있게 엄격한 조건을 가지고 있다.  동일한 Element를 가지고 있는 Set의 두 구현체들은 서로 구현방법이 달라도 equals를 만족한다.  (이는 결국 동일한 객체만 중복으로 보지 않는다는걸 의미하기도 한다.)

 

> HashSet

  HashSet은 일반적으로 알고 있는 HashTable의 구조를 가진다.  내부적으로는 사실 HashMap을 기반으로 구현되어 있다.  Key-Value로 구성된 HashMap 에서 Key만을 사용하는 것으로 볼 수 있다.   Value는 불변객체를 이용해 Dummy값으로 설정한다.  또한 HashMap의 특징 처럼 Element가 추가된 순서 혹은, 특정 순서와 관계 없이 순회가 이루어진다. (Ordering 보장하지 않는다.)  또한 Null요소를 허용한다.  (중복 불허용이니, 결국 1개의 Null)
   Hash함수가 버킷간에 Element를 적절히 분산 시킨다는 가정하에 기본 작업 (add, remove, contains, size)에 일정한 시간 성능을 제공한다 .  iterator를 이용해 핸들링하려면, HashSet 인스턴스의 사이즈 (Element 수)와, 초기 HashSet 생성자의 (capacity)를 설정한 경우 잔여 공간의 합계에 비례 한 시간이 필요하다.  따라서 iterator 이용할 때 성능이 중요 할 경우 초기 용량을 알맞게 설정하는 것이 중요하다.

  HashSet은 기본적으로 non-thread safe하다. (동기화를 보장하지 않는다.)  복수의 thread가 동시에 HashSet를 이용하려면 외부적으로 동기화를 구현하거나,  Collections.synchronizedSet 메소드를 사용하여 Wrapping 하여 사용하여야 한다.

Set s = Collections.synchronizedSet (new HashSet (…));

 

> TreeSet

  NavigableSet 인터페이스의 구현체인 TreeSet은 실제 구현 Source를 보면 버킷(Element를 담는 공간)으로 TreeMap을 이용한다.  Element는 Natural Order (객체별 기본 Comparable 인터페이스 구현에 의한 compareTo 결과)로 정렬되거나 생성자에 부여된 Comparator에 의한 순서로 정렬 된다.

TreeSet의 버킷으로 이용되는 TreeMap은 Self-balancing Binary Search Tree의 종 류중 하나인 Red-black Tree 방식으로 내부 Element를 구조화 한다.

동기화 관련해서는 HashSet과 같은 특징을 가진다.

 

 

 

 

Java – Collection – List

> List (Interface)

  List Interface를 구현한, 자료구조 Class들의 특징을 이야기 하려고 한다.  List는, 소속된 Element의 순서가 있는 Collection 종류이다.   각 Element가 삽입되는 위치를 정확하게 제어 할 수 있다.  또한 정수로 되어있는 Index를 이용해 Element 접근할 수 있다.

  Set과 달리 List는 일반적으로 중복 요소를 허용한다.  문법적으로 이야기 하자면, 일반적으로 List는 e1.equals(e2)가 허용되는 소속 Element들이 존재할 수 있다.  그리고 일반적으로 null Element를 허용하는 경우 여러 개의 null Element를 허용한다.

Iterator를 이용하여 Element의 삽입 및 교체, 접근 등이 가능하며 구현체들은 Iterator를 얻기위한 메서드를 제공한다.

  List를 구현한 구현체로는 ArrayList와 LinkedList가 일반적으로 사용된다. 

  Element로의 접근 및 검색, 삽입, 삭제 등 에서 두 구현체는 구현방법에 따른 성능차이를 보인다.  경우에 따라 ArrayList와 LinkedList가 더 적합한 경우가 존재한다.  

 

> ArrayList

Element들을 저장하는 방법에 있어서 Array[배열]를 사용한다.   그러므로 배열의 장점 및 단점을 어느 정도 공유한다.  예를 들면, Index를 이용해 각 Element에 Direct로 접근 할 수 있는 장점이 있으며, Array가 초기 Size가 정해져 있는 단점이 있어 확장이 용이하지 않은 단점을 가지고 있다.  단지 ArrayList는 System.arraycopy를 이용해 특정 Size를 넘어가면 자동 확장하게 구현되어 있다.  그러나 분명 자동 확장이라 하더라도 확장할때의 성능 저하는 존재한다.   그러한 점 때문에 ArrayList는 초기 생성 할 때 배열의 초기 Size를 지정할 수 있다.  (DEFAULT_CAPACITY = 10)  어느 정도 크기가 예상될 경우 기본 크기를 그에 맞게 초기에 설정하는 것이 성능상 유리하다.

또한 List의 중간에 Member의 추가 및 삭제가 이루어질 경우도 부하가 존재한다.  배열의 구조를 생각한다면 당연하게 생각 될 것이다.

ArrayList 배열은 일단 확장하고 나면, Element들을 삭제하여도 그 배열 크기는 줄어들지 않는다.  Element의 수가 계속해서 늘었다 줄었다 한다면 ArrayList는 최적의 선택이 아닐 수 있다.

 

> LinkedList

Element들을 저장하는 데 배열을 이용하지 않고, 리스트 안에서 다음 Element를 가리키는 내부 객체를 이용한다.  LinkedList의 각 Element는 해당 Element의 고유 객체(item)와 함께 다음 Element를 가리키는 재귀적 타입인 next라는 필드를 가지고 있다.  또한 prev라는 필드는 직전의 Element를 가리킨다.   이를 이용하면 리스트 사이를 쉽게 이동할 수 있고 순서대로 각 원소를 찾아 처리할 수도 있다.  이러한 특징은 ArrayList의 단점을 없에 준다.  List의 중간에 삭제나 삽입이 이루어지기 수월하고, 확장에 따른 부하가 존재하지 않는다.  그러나 ArrayList가 가지고 있는 장점이 LinkedList에서는 단점이 된다.   Index를 이용한 Element로의 Direct접근이 불가능하다.  get(int index)를 이용할 경우 LinkedList는 List의 첫 요소 부터 혹은 끝부터 List를 순회하여 해당 index를 찾도록 구현 할 수 밖에 없는 것이다. 

 

> ArrayList와 LinkedList의 성능 비교

 

 

Java – Collection 개요 (자료구조)

> 필요없는 사족 (Posting 계기)

Java – Collection에 관한 참고자료 및 Post, 책 등은 사실 이렇게 중복 Post를 할 필요가 없을 정도로 많고 쉽게 찾아 볼 수 있다.  알고리즘에 대해 이야기 할 때, 그리고 자료구조 혹은 Data 핸들링을 위한 이야기 들 가운데 항상 등장한다.  하지만 여기 저기 흩어진 각자의 정리방법, 혹은 Tip들에 대해 블로그 Category로 모을 수 있으면 어떨까 하는 생각에 Posting작업을 시작하게 되었다.

Java를 다루는 이에게 Collection이란 기초적이면서도, 언제든 다시 상기해야 하는 시점이 오는 주제가 아닌가 싶다.

끈기 있게 할 수 있을지 모르겠다.  될 수 있으면 각 개별 Collection들의 특징, 혹은 관련된 Tip, 비교 자료 등을 빠짐없이 이 blog-Category에 모을 수 있다면 하는 소망이 있다.
(단순히 link하는 정도를 넘어)

 

> Java – Collection

Collection은 배열과 같은 다른 객체를 저장, 핸들링하는 것을 목적으로하는 객체이다.   배열과 달리 Collection에는 요소의 일부를 반환하고 변환 및 정렬 등의 메서드를 포함하고 있다.  또한 Collection은 primitive type(int, long, boolean 등)을  요소의 type으로 지정할 수 없다. (하지만 primitive type에 대응되는 wrapper Class를 사용할 수 있다. 예: int -> java.lang.Integer)

모든 Collection 객체는 궁극적으로 java.util.Collection 인터페이스를 구현한다.  그러나 인터페이스를 직접 구현하는 경우는 별로 없다.  Collection 추가 메소드를 지정하는 여러 하위 인터페이스가 있다.  이러한 하위 인터페이스들은 Collection의 기능을 결정한다.  개별 클래스는 일반적으로 구현방식에서만 차이를 보인다. (예를 들어, 모두 ArrayList와 LinkedList는 List의 일반적인 기능을 모두 만족하지만, 내부 구현 방식에 있어 차이를 보인다.)

Collection 인터페이스 의 대부분의 구현은 java.util에 있다.

Map은 Collection 인터페이스를 상속하지 않음에도 불구하고,  일반적으로 Collection을 이야기 할때 항상 포함되기에 함께 이야기해보겠다.

 

> Java Collection 구조

 

> 자료구조 별 일반 특징 비교 (대분류)

 

> 주요 자료구조 별 특징 비교 (실구현 Class)

 

> 참고 URL