java.util.HashMap

 

public class HashMap<K,V>
extends AbstractMap<K,V>
implements Map<K,V>, Cloneable, Serializable

https://docs.oracle.com/javase/8/docs/api/

Java Platform SE 8

Object를 상속받고 Map<K, V>인터페이스를 구현한 추상클래스 AbstractMap.

 

HashMap은 Map<K, V>, Cloneable, Serializable 인터페이스를 구현하고 AbstractMap<K, V>를 상속받은 클래스이다.

 

인터페이스와 추상클래스 >>

Hash table이라는 자료구조를 가지고 있다. 

java.util.Hashtable는 동기화를 지원하고, 키, 값에 null을 넣을 수 없지만, java.util.HashMap은 동기화를 지원하지 않고 키, 값에 null을 넣을 수 있다. 

순서가 없다.

기본 연산인 get, put은 해쉬함수를 통해 elements들을 buckets에 넣고 가져오고, 이러한 연산에는 일정한 성능을 보인다. 

HashMap안에 있는 요소들을 보기위한 iteration 성능이 중요하다면 처음 capacity를 (the number of buckets) 너무 크거나 적게 주지 않는 것이 중요하다. -> HashMap 인스턴스의 capacity와 key-value 매핑된 수의 크기의 비례하는 시간을 필요로 하므로.

HashMap은 2개 파라미터를 인스턴스로 갖는데, initial capacity와 load factor은 성능에 영향을 미친다. capacity는 hash table이라는 자료 구조에서 쓰이는 buckets의 수를 말하고, 해당 파라미터의 initial capacity는 hash table이 생성될 시의 capacity를 말함.또 다른 파라미터 load factor은 capacity가 자동으로 증가되기 전에 hash table이 얼마나 차있는지 측정한다.  load factor와 현재 capacity의 곱의 수가 hash table을 초과하면, rehash되고(내부 데이터구조가 다시 재정립되는 것), hash table은 대략 2배의 buckets을 갖게된다.

 

일반적으로 기본 load factor(.75)은 시간과 공간비용 측면에서 적절한 밸런스를 제공한다. 더 큰 값은 공간 오버해드는 줄여주지만 찾는 비용이 늘어난다. (get, put을 포함한 대부분의 operation에 영향을 끼침.) 

따라서 2개의 인스턴스인 initial capacity와 load factor의 값 설정시 rehash operation을 최소화 하기 위해 고려해야한다. load factor로 개체의 최대 개수(데이터 입력할 최대개수)를 나눴을 때 initial capacity가 더 크면 rehash는 일어나지 않는다.-> HashMap의 인스턴스에 많이 저장되야 되면 처음 생성할 때 부터 init capacity를 크게 주면 rehash하지 않아도 되니까 더 효율적일 수 있다.

많은 키를 사용할 때 같은 hashCode()를 사용하는 것은 성능에 좋지 않다. 영향을 개선시키기 위해 키가 Comparable클래스 일 때 comparison order를 사용하면 키들 간의 연결을 끊을 수 있다. // 이 부분은 무슨 말을 하고 싶은지 몰겠음.

 

동기화를 지원하지 않는 클래스이다. Collenctions.synchronizedMap을 통해 감싸(wrapped)져서 동기화(멀티쓰레드 환경)에 안전하게 사용할 수 있음. 

Map m = Collections.synchronizedMap(new HashMap(...));

만약 다른 쓰레드에서 바꾸면 ConcurrentModificationException을 날림.