비교기 기반 키 값 맵을 사용하고 싶습니다. 읽기 및 쓰기 작업 (스케쥴러를 통해 3 개월에 한 번)이 수행됩니다. 컬렉션의 초기로드는 응용 프로그램 시작시 수행됩니다.몇 가지 쓰기 및 자주 읽는 동시 수집 Java
ConcurrentSkipListMap이 이에 대한 좋은 후보가됩니까? 이것에 대한 get 연산은 동시에 여러 스레드에 대한 액세스를 허용합니까? 동시 비 차단 읽기하지만 원자 쓰기를 찾고 있어요.
ConcurrentHashMap 정확히 찾고있는 것입니다. Javadoc에서 :
검색 작업 (get 포함)은 일반적으로 차단하지 않으므로 업데이트 작업 (넣기 및 제거 포함)과 겹칠 수 있습니다. 검색은 가장 최근에 완료된 업데이트 작업의 결과를 반영합니다. (더 공식적으로, 주어진 키에 대한 업데이트 작업을 맺는 일이 발생-전에 (null 이외의와의 관계를) 검색을 업데이트 된 값을보고 해당 키 위해.) 그것 같은 소리
동시 "에 대한 귀하의 요구 사항을 만족 비 차단 읽기이지만 원자 쓰기 ".
쓰기가 너무 적기 때문에 high loadFactor and appropriate initialSize when creating the ConcurrentHashMap을 지정하면 맵을 채울 때 테이블 크기 조정을 방지 할 수 있습니다. (당신은 또한 자바 (8)의 자바 독가 더 이상 크기의 힌트로 사용되는 의미없는 것 같습니다하지만, 일의의 concurrencyLevel을 설정할 수 있습니다.)
당신이 절대적으로SortedMap 또는 NavigableMap이 있어야합니다 경우, ConcurrentSkipListMap는 OUT-입니다 바로가는 방법. 하지만 실제로 사용하기 전에 해당 인터페이스에서 제공하는 기능 (첫 번째/마지막 키 가져 오기, 서브맵, 인근 항목 찾기 등)이 실제로 필요한지 다시 한 번 확인합니다. 가파른 가격 (대부분의 작업에서 log n 대 일정 시간)을 지불하게됩니다.
동시 작업을 찾고 있으므로 기본적으로 3 명의 경쟁자가 있습니다. Hashtable, ConcurrentHashMap, ConcurrentSkipListMap (또는 Collections.synchronizedMap()하지만 효율적이지 않습니다).
은 '희귀 쓰기 작업'주문 '정렬 소망하는'나는 ConcurrentSkipListMap과 경주를 승리라고 생각한다.
제 3 자 코드를 사용하고자하는 경우 드물게 작성하는 데 이상적인지도의 복사 중 복사 버전을 고려해 볼 수 있습니다. 여기에 인터넷 검색을 통해 와서 하나는 다음과 같습니다
https://bitbucket.org/atlassian/atlassian-util-concurrent/wiki/CopyOnWrite%20Maps
가 자신을 그렇게주의의 위험 부담을 시도하지 마십시오.
3 달 동안 계속 운영 할 것으로 예상되는 애플리케이션에 대해서는 의심 스럽지만 솔직히 모든 ConcurrentMap 구현이 여기서 작동합니다. –
로드하는 데 너무 많은 비용이 들지 않는 한, 불변의 맵으로 가서 3 개월마다 새로운 맵을 만들면됩니다. 스레드 안전성에 대해 걱정할 필요가 없습니다. – shmosel
예, 모든 동시 콜렉션의 경우 해당 연산은 스레드로부터 안전합니다. javadoc에서도 꽤 명확합니다. get()에만 관심이 있다면 왜 O (log (n))가 아닌 O (1)이 될 ConcurrentHashMap을 사용하지 않는지 궁금합니다. –