WeakHashMap 또는 WeakReference는 언제 사용합니까?

WeakHashMap 또는 WeakReference는 언제 사용합니까?

취약한 레퍼런스의 사용은 지금까지 구현된 적이 없기 때문에 그 사용 사례와 구현 방법을 알아보려고 합니다.언제 를 사용할 필요가 있었습니까?WeakHashMap또는WeakReference어떻게 사용되었습니까?

강력한 참조의 한 가지 문제는 캐시이며, 특히 이미지와 같은 매우 큰 구조의 경우입니다.내가 작업하는 웹 사이트 설계 도구와 같이 사용자가 제공한 이미지로 작업해야 하는 응용 프로그램이 있다고 가정합니다.디스크에서 로드하는 것은 매우 비용이 많이 들고 (대용량일 가능성이 있는) 이미지의 복사본을 한 번에 2개 메모리에 저장하는 것을 피하고 싶기 때문에 당연히 이러한 이미지를 캐시해야 합니다.

이미지 캐시는 이미지를 새로고침할 필요가 없을 때 이미지를 새로고침하지 못하도록 되어 있기 때문에 캐시에 이미 메모리에 있는 이미지에 대한 참조가 항상 포함되어 있어야 한다는 것을 금방 알 수 있습니다.다만, 통상의 강력한 참조에서는, 그 참조 자체가 이미지를 메모리에 보존할 수 밖에 없습니다.그 때문에, 이미지가 메모리내에서 불필요하게 되었을 때를 판단해 캐시로부터 삭제할 필요가 있기 때문에, 가비지 수집의 대상이 됩니다.강제로 가비지 수집기의 동작을 복제하고 개체가 메모리에 있어야 하는지 여부를 수동으로 확인해야 합니다.

취약 레퍼런스에 대해서, Ethan Nicholas

WeakReference대SoftReference

명확한 구별 중 하나는 와의 차이입니다.

기본적으로는WeakReference참조된 객체에 해당 객체에 대한 하드 참조가 없으면 JVM에 의해 GC-d가 됩니다.aSoftReference반면 d개체는 메모리를 회수해야 할 때까지 가비지 컬렉터에 의해 방치되는 경향이 있습니다.

값이 내부에 보관되어 있는 캐시WeakReferences는 거의 쓸모가 없습니다(단,WeakHashMap는, 약하게 참조되고 있는 키). SoftReferences는 사용 가능한 메모리와 함께 확장 및 축소할 수 있는 캐시를 구현할 때 값을 정리하는 데 유용합니다.

의 일반적인 사용WeakReference및WeakHashMap특히 오브젝트에 속성을 추가하기 위한 것입니다.경우에 따라서는 오브젝트에 기능이나 데이터를 추가하고 싶지만 서브클래싱이나 컴포지션은 옵션이 아닙니다.이 경우 추가하는 오브젝트를 추가할 속성에 링크하는 해시맵을 작성하는 것이 당연합니다.그 부동산이 필요하면 언제든지 지도에서 찾아보세요.그러나 속성을 추가할 개체가 파괴되고 많이 생성되는 경향이 있는 경우 맵에 오래된 개체가 많은 메모리를 차지하게 될 수 있습니다.

를 사용하는 경우WeakHashMap대신 오브젝트는 프로그램의 나머지 부분에서 더 이상 사용되지 않는 즉시 맵을 떠나게 됩니다.이것은 바람직한 동작입니다.

데이터를 추가하기 위해 이 작업을 수행해야 했습니다.java.awt.Component1.4.2와 1.5 사이의 JRE의 변화를 피하기 위해 관심 있는 모든 컴포넌트를 하위 분류하여 수정할 수 있었습니다.JButton,JFrame,JPanel......) 단, 코드 수가 훨씬 적기 때문에 이 작업은 훨씬 더 쉬워졌습니다.

또 하나의 유용한 사례WeakHashMap그리고.WeakReference는 리스너 레지스트리의 실장입니다.

특정 이벤트를 청취할 때 일반적으로 청취자를 등록합니다(예:

manager.registerListener(myListenerImpl);

이 경우,manager를 사용하여 청취자를 저장합니다.WeakReference즉, 레지스터를 삭제할 필요가 없습니다(예:manager.removeListener(myListenerImpl)청취자 또는 수신자를 고정하는 구성 요소를 사용할 수 없게 되면 자동으로 제거됩니다.

물론 리스너를 수동으로 삭제할 수도 있지만, 아직 삭제하지 않았거나 삭제하지 않은 경우 메모리 누수가 발생하지 않으며 리스너가 가비지 수집되는 것을 막을 수도 없습니다.

어디서 하는 거지?WeakHashMap등장할 수 있을까요?

등록된 리스너를 저장하기 위해 플래시하는 리스너 레지스트리:WeakReference는 이러한 참조를 저장하기 위한 컬렉션을 필요로 합니다.WeakHashSet만 해당됩니다.WeakHashMap그러나 후자를 사용하면 첫 번째 기능의 기능을 쉽게 "수정"할 수 있습니다.

Set<ListenerType> listenerSet =
    Collections.newSetFromMap(new WeakHashMap<ListenerType, Boolean>());

해서.listenerSet새 수신기를 등록하려면 해당 수신기를 세트에 추가하면 됩니다.또한 명시적으로 삭제되지 않더라도 수신기가 더 이상 참조되지 않으면 JVM에 의해 자동으로 삭제됩니다.

이 블로그 투고에서는 두 가지 클래스(Java: synchronizing on a ID)의 사용에 대해 설명합니다.사용법은 다음과 같습니다.

private static IdMutexProvider MUTEX_PROVIDER = new IdMutexProvider();

public void performTask(String resourceId) {
    IdMutexProvider.Mutex mutext = MUTEX_PROVIDER.getMutex(resourceId);
    synchronized (mutext) {
        // look up the resource and do something with it
    }
}

IdMutextProvider는 동기화할 ID 기반 개체를 제공합니다.요건은 다음과 같습니다.

• 는 동등한 ID를 동시에 사용하려면 동일한 개체에 대한 참조를 반환해야 합니다.
• 는 다른 ID에 대해 다른 개체를 반환해야 합니다.
• no release mechanism(프로바이더에 반환되지 않음)
• 누설해서는 안 됩니다(가비지 수집에 적합한 오브젝트).

이 작업은 다음과 같은 유형의 내부 스토리지 맵을 사용하여 수행됩니다.

WeakHashMap<Mutex, WeakReference<Mutex>>

개체는 키와 값입니다.맵 외부에 개체에 대한 하드 참조가 없는 경우 가비지가 수집될 수 있습니다.맵의 값은 하드 참조와 함께 저장되므로 메모리 누수를 방지하려면 값을 WeakReference로 감싸야 합니다.이 마지막 포인트는 javadoc에서 다룹니다.

예를 들어 특정 클래스에서 생성된 모든 개체를 추적하려는 경우.이러한 개체를 가비지 수집하도록 허용하려면 개체 자체 대신 개체에 대한 약한 참조 목록/맵을 유지합니다.

이제 누군가 나에게 환영에 대한 언급을 설명해 준다면 난 행복할 텐데...

위와 같이 강한 기준이 존재하는 한 약한 기준이 유지된다.

예를 들어 리스너 내부에서 WeakReference를 사용하여 리스너가 타깃오브젝트에 대한 메인레퍼런스가 없어지면 리스너가 활성화되지 않도록 하는 방법이 있습니다.이는 청취자 목록에서 WeakReference가 삭제되는 것을 의미하는 것은 아니며 청소는 여전히 필요하지만 예약된 시간 등에 수행할 수 있습니다.이는 또한 재생되는 객체가 강한 참조를 보유하지 못하게 하고 결국 메모리 증식의 원인이 되는 효과도 있습니다.예: 윈도우보다 라이프 사이클이 긴 모델을 참조하는 스윙 GUI 컴포넌트

위에서 설명한 바와 같이 청취자와 함께 재생하는 동안 사용자의 관점에서 오브젝트가 "즉시" 수집된다는 것을 빠르게 깨달았습니다.

WeakReferences의 실제 용도 중 하나는 거의 사용되지 않는 하나의 매우 큰 개체가 있는 경우입니다.필요하지 않을 때는 메모리에 보관하고 싶지 않지만, 다른 스레드에 동일한 개체가 필요한 경우 두 개도 메모리에 보관하고 싶지 않습니다.오브젝트에 대한 약한 참조와 그것을 사용하는 메서드의 하드 참조를 어딘가에 유지할 수 있습니다.두 메서드가 모두 완료되면 오브젝트가 수집됩니다.

새로운 Weak Hash Map()의 구글 코드를 검색했습니다.

GNU classpath 프로젝트에서 많은 매치를 얻었고

1. Apache xbean 프로젝트 : WeakHashMapEditor.java
2. Apache Lucene 프로젝트 : CachingWrapperFilter.java

weakhashmap을 사용하여 확장 객체 생성을 위한 리소스 없는 캐싱을 구현할 수 있습니다.

단, 가변 객체가 있는 것은 바람직하지 않습니다.쿼리 결과를 텍스트 검색 엔진에 캐시하기 위해 사용했습니다(실행하는 데 약 400밀리초 소요). 거의 업데이트되지 않습니다.

언급URL : https://stackoverflow.com/questions/154724/when-would-you-use-a-weakhashmap-or-a-weakreference