UFO ET IT

IdentityHashMap의 사용 사례

ufoet 2021. 1. 10. 17:50
반응형

IdentityHashMap의 사용 사례


누구든지 중요한 사용 사례가 무엇인지 말씀해 주 IdentityHashMap시겠습니까?


문서화는 말합니다 :

이 클래스의 일반적인 용도는 직렬화 또는 딥 복사와 같은 토폴로지 보존 개체 그래프 변환입니다. 이러한 변환을 수행하려면 프로그램은 이미 처리 된 모든 개체 참조를 추적하는 "노드 테이블"을 유지해야합니다. 노드 테이블은 서로 다른 객체가 동일하더라도 동일하지 않아야합니다. 이 클래스의 또 다른 일반적인 용도는 프록시 개체를 유지하는 것입니다. 예를 들어, 디버깅 기능은 디버깅중인 프로그램의 각 개체에 대해 프록시 개체를 유지하려고 할 수 있습니다.


당신이 당신의 열쇠를 할 때마다 의해 비교하지 equals만에 의해 ==당신이 IdentityHashMap의를 사용할 수 있습니다. 이것은 많은 참조 처리를 수행하는 경우 매우 유용 할 수 있지만 매우 특수한 경우에만 제한됩니다.


IdentityHashMap을 사용할 수있는 한 가지 경우는 키가 Class 객체 인 경우입니다. 이것은 get에 대한 HashMap보다 약 33 % 빠릅니다! 아마도 더 적은 메모리를 사용합니다.


당신은 또한 사용할 수 있습니다 IdentityHashMapA와 범용지도 경우 당신은 키가 동일하므로 사용하십시오 개체 수 의 경우에만 자신의 참조가 동일합니다.

무슨 이득? 분명히 또는 같은 구현을 사용하는 것보다 더 빠르며 메모리를 덜 사용합니다 .HashMapTreeMap


사실 이런 경우가 꽤 많습니다. 예를 들면 :

  • Enum에스. 열거 형의 경우 더 나은 대안이 있습니다.EnumMap
  • Class사물. 그들은 또한 참조로 비교할 수 있습니다.
  • 인턴 Strings. 그것들을 리터럴 로 지정 하거나 호출 String.intern()함으로써.
  • 캐시 된 인스턴스. 일부 클래스는 해당 인스턴스의 캐싱을 제공합니다. 예를 들어 다음의 javadoc에서 인용 Integer.valueOf(int):

    이 메서드는 항상 -128 ~ 127 범위의 값을 캐시합니다.

  • 특정 라이브러리 / 프레임 워크는 정확히 하나의 세 라틴 유형 인스턴스 (예 : Spring Bean)를 관리합니다.
  • 싱글 톤 유형. Singleton 패턴으로 빌드 된 유형의 인스턴스를 사용하는 경우 (최대) 하나의 인스턴스가 존재하는지 확인할 수 있으므로 참조 동등성 테스트가 동등성 테스트에 적합합니다.
  • 맵에 값을 넣는 데 사용 된 값에 액세스하기 위해 동일한 참조 만 사용하도록 명시 적으로 처리하는 기타 유형입니다.


마지막 요점을 설명하려면 :

Map<Object, String> m = new IdentityHashMap<>();

// Any keys, we keep their references
Object[] keys = { "strkey", new Object(), new Integer(1234567) };

for (int i = 0; i < keys.length; i++)
    m.put(keys[i], "Key #" + i);

// We query values from map by the same references:
for (Object key : keys)
    System.out.println(key + ": " + m.get(key));

예상대로 출력됩니다 ( Object지도에서 값을 쿼리 하는 데 동일한 참조를 사용했기 때문 ).

strkey: Key #0
java.lang.Object@1c29bfd: Key #1
1234567: Key #2

HashMap은 개체를 추가 할 때마다 Entry 개체를 생성하므로 개체가 많을 때 GC에 많은 스트레스를 줄 수 있습니다. 1,000 개 이상의 객체가있는 HashMap에서는 GC 정리 항목 만있는 CPU의 상당 부분을 사용하게됩니다 (경로 찾기 또는 생성 된 후 정리되는 기타 원샷 컬렉션과 같은 상황에서). IdentityHashMap에는이 문제가 없으므로 훨씬 더 빨라질 것입니다.

여기에서 벤치 마크를 참조하십시오. http://www.javagaming.org/index.php/topic,21395.0/topicseen.html


이것은 저의 실용적인 경험입니다.

IdentityHashMap은 큰 카디널리티에 대해 HashMap에 비해 훨씬 작은 메모리 풋 프린트를 남깁니다.


One important case is where you are dealing with reference types (as opposed to values) and you really want the correct result. Malicious objects can have overridden hashCode and equals methods getting up to all sorts of mischief. Unfortunately, it's not used as often as it should be. If the interface types you are dealing with don't override hashCode and equals, you should typically go for IdentityHashMap.

ReferenceURL : https://stackoverflow.com/questions/838528/use-cases-for-identityhashmap

반응형