여기에서 무슨 일이 일어나고 있는지를 알아 내려고 애쓰는 시간을 잃어 버렸지 만 마침내 뭔가가 있다고 생각합니다.PicoContainer 캐싱은 스레드로부터 안전 할 수 있습니까?
우리는 내가 싱글 동작이 발생할 줄 알았는데 단순히 캐싱집니다 일부 상당히 정상 PicoContainer 코드가 있습니다
container.as(Characteristics.CACHE).addComponent(Service.class, ServiceImpl.class);
그러나
오늘날 우리가 발견, 우리는 분명히 건설되고있는 구성 요소가를 한 번이 아니라 네 번. 내 컴퓨터에서 재현 할 수있는 것이 아니라 다른 일부 개발자 컴퓨터에서 재현 할 수있는 것이 아닙니다.
더 자세히 조사한 결과, 여러 스레드가 동시에 동일한 구성 요소를 조회하기 위해 PicoContainer를 치고 하나의 사본을 인스턴스화하고 다른 세 개의 스레드를 기다리는 대신 4 개의 인스턴스를 생성하는 것으로 나타났습니다 (그 중 하나를 유지하는 것을 기억합니다.)
PicoContainer에서 진정한 단 하나의 비헤이비어를 얻는 방법은 비교적 간단합니까?
사후 부검이있었습니다. 실제로이 검사를받은 사람의 문제를 해결했으며, 적어도 단기간에 작성한 모든 테스트를 수정했습니다. 장기간에 10,000 번 테스트가 실행되면 PicoContainer는 여전히 구성 요소의 인스턴스를 여러 개 만듭니다. 따라서 Locking 비헤이비어를 사용하는 경우에도 여전히 스레드로부터 안전하지 않다고 주장 할 것입니다. 사용하지 않는 것보다 다소 좋을 것입니다. – Trejkaz
참. 나는 [Double Check Lock] (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)이 다중 인스턴스의 가능성을 더욱 줄일 수 있다고 생각합니다. 특히 [메모리 모델]이 개선 된 JDK5 (http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html). – Santosh
필자는 PicoContainer가 어떻게 작동 하는지를 조사한 다음 실제로 쓰레드 안전 컴포넌트 어댑터를 만들기 위해 Guava의 동시성 작업을 사용하려고합니다. – Trejkaz