2011-01-17 2 views
4

Java's weak hash map과 같은 약한 해시 테이블은 약한 참조를 사용하여 가비지 수집기가 도달 할 수없는 키 컬렉션을 추적하고 해당 키가있는 바인딩을 컬렉션에서 제거합니다. 약한 해시 테이블은 일반적으로 가비지 수집기가 그래프의 도달 할 수없는 부분을 수집 할 수 있도록하기 때문에 그래프의 한 정점이나 가장자리에서 다른 정점이나 가장자리까지 삽입을 구현하는 데 사용됩니다.weakhashmap과 순전히 기능적으로 동일합니까?

이 데이터 구조와 완전히 동일한 기능이 있습니까? 그렇지 않다면, 어떻게 창조 될 수 있습니까?

이것은 흥미로운 도전처럼 보입니다. 도달 할 수없는 부분을 제거하기 위해 데이터 구조를 수집 (즉, 변경)해야하기 때문에 내부 구현은 순수 할 수는 없지만 데이터의 일부에만 영향을주기 때문에 불순물을 결코 관찰 할 수없는 사용자에게 순수한 인터페이스를 제공 할 수 있다고 생각합니다. 정의에 의해 사용자가 더 이상 도달 할 수없는 구조.

답변

0

순수 기능 데이터 구조는 사용자 관점에서 변경할 수 없습니다. 그래서, 만약 해쉬 - 맵으로부터 키를 얻고, 기다린 다음, 같은 키를 다시 얻으면, 나는 같은 값을 얻어야 만합니다. 나는 열쇠를 잡을 수있어 사라지지 않는다.

API가 나에게 다음 세대를 제공하고 컨테이너의 이전 버전에 대한 모든 참조가 해제 될 때까지 값이 수집되지 않는 경우에만 작동 할 수 있습니다. 데이터 구조의 사용자는 새로운 세대가 약한 가치를 발표 할 것을 주기적으로 요구할 것으로 예상됩니다. 난 당신이 원하는 행동을 이해하지만 객체 출시지도와이 테스트를 통과 할 수 없습니다 :

편집 (코멘트 기준)

FunctionalWeakHashMap map = new FunctionalWeakHashMap(); 

{ // make scope to make o have no references 
    Object o = new SomeObject(); 
    map["key"] = o; 
} // at this point I lose all references to o, and the reference is weak 

// wait as much time as you think it takes for that weak reference to collect, 
// force it, etc 

Assert.isNotNull(map["key"]); // this must be true or map is not persistent 

나는이 테스트

를 통과 할 수 있음을 시사하고있다을
FunctionalWeakHashMap map = new FunctionalWeakHashMap(); 

{ // make scope to make o have no references 
    Object o = new SomeObject(); 
    map["key"] = o; 
} // at this point I lose all references to o, and the reference is weak in the map 

// wait as much time as you think it takes for that weak reference to collect, 
// force it, etc 

map = map.nextGen(); 

Assert.isNull(map["key"]); 
+0

아닙니다. 약한 해시 맵의 요점은 프로그래머가 주기적으로 요청하지 않아도 GC가 도달 할 수없는 부분 그래프를 자동으로 해제한다는 것입니다. –

+0

나는 그것이 영구적 인 데이터 구조로 작동 할 수없고 두 가지 동작을 조화시키는 방법을 제공 할 수 없다고 구체적으로 말하고 있습니다. 당신 문제는 당신이 내가 그것에 도달 할 수 없다고 생각하는 것입니다,하지만 그럴 수 있습니다. 나는 물론 객체에 대한 참조를 가지고 있지 않지만 키가있다. –

+0

귀하의 행동에 대한 귀하의 해석이 잘못되었습니다. * 키 *가 도달 할 수 없게되면 약한 해시 맵의 바인딩이 제거됩니다. 카운터 예제의 키를 누르고 있으므로 해당 키의 바인딩을 수집 할 수 없었고 그러한 문제가 없었습니다. o의 도달 가능성은 부적합하다. 정의 할 수없는 도달 할 수없는 값의 의미에만 영향을주기 때문에 영구 데이터 구조에서도 작동하지 않는 이유는 없습니다. –

2

흥미로운 개념입니다. "순전히 기능적인"환경에서 주요한 복잡성은 객체 정체성이 "순수하게 기능적인"의미에서 정상적으로 관찰 가능하지 않다는 것입니다. I.E. 객체를 복사하거나 동일한 객체를 새로 작성하는 경우 Java에서 복제본이 원본이 아닌 것으로 예상됩니다. 그러나 기능 설정에서 가비지 컬렉터가 다르게 처리 할지라도 새로운 것이 의미 상으로 이전 것과 동일 할 것으로 예상됩니다.

개체 식별을 의미 체계의 일부로 허용하는 경우 소리가 들리 겠지만 그렇지 않은 경우는 가능합니다. 후자의 경우, 해킹이 발견 될지라도 (나는 아래에 설명 된 하나를 생각했다.) 사실을 이용하기 위해 모든 일을 할 것이기 때문에 당신은 언어 구현을 당신과 싸우게 될 것이다. 그 객체 신원은 관찰 할 수있는 것이 아닙니다.

내 마음 속에 떠오르는 '해킹'은 키로 고유 한 값을 사용하는 것이므로 대부분의 경우 값 평등은 참조 평등과 일치합니다. 예를 들면, 나는 내가 그 인터페이스에서 다음과 같이 하스켈에서 개인적으로 사용하는 라이브러리가 : 당신 같은 해시 맵이 키와이와 아마 대부분-일 것이라고 설명

data Uniq s 
getUniq :: IO (Uniq RealWorld) 
instance Eq (Uniq s) 
instance Ord (Uniq s) 

을하지만, 심지어 여기에 내가 생각할 수있는 컴파일러의 "unbox-strict-fields"최적화가 활성화 된 상태에서 사용자가 키를 일부 데이터 구조의 엄격한 필드에 저장한다고 가정합니다. 'Uniq'가 기계 정수에 대한 새로운 유형의 래퍼 일 경우 더 이상 GC가 가리킬 수있는 객체가 없으며 "그 것이 핵심"이라고 말할 수 있습니다. 따라서 사용자가 키를 사용하여 키를 사용하면지도가 이미 잊어 버렸을 수 있습니다.(편집 :이 특정 예제는 분명히 주위에 일할 수 Uniq의 구현을 그렇게 unboxed 수없는 일이되도록, 컴파일러가 우리가하지 않을 수있는 많은 방법으로 도움이되기 위해 노력하기 때문에 그것은 까다로운 것입니다.) 개체의 신원이 주어지지 않는 한 많은 경우 "최적화"가 약한 해시 맵 구현에 의해 깨지거나 깨질 것이라는 것을 나는 의심한다. 일류 관찰 가능 상태.

관련 문제