Collections.synchronizedList (list)가 내부적으로 instanceof check를 사용하는 이유는 무엇입니까?

Question

클래스의 소스 코드를 확인합니다. 나는 목록이 가능해, RandomAccess 유형의 경우 우리가 확인하는 이유를 알아 보았 실패

public static <T> List<T> synchronizedList(List<T> list) { 
    return (list instanceof RandomAccess ? 
      new SynchronizedRandomAccessList<>(list) : 
      new SynchronizedList<>(list)); 
} 

방법 에는 Collections.synchronizedList (목록)을 가로 질러왔다. ArrayList가이 인터페이스를 구현하고 LinkedList가 구현하지 않는다는 것을 이해합니다. 또한

, SynchronizedRandomAccessList는 SynchronizedList을 상속합니다. 그러면이 수표의 요점은 무엇입니까? 설명해주세요.

Answer 1

거의 다 왔어. 일부 목록에는 RandomAccess을 구현하기 때문에 Collections.synchronizedList(list)은 RandomAccess을 확인합니다.

이 RandomAccess은 과 마찬가지로 marker interface입니다. 목록의 항목에 임의로 액세스 할 수 있는지 여부를 알려줍니다. 나는. ArrayList에서 동일한 계산 비용으로 모든 항목을 검색 할 수 있습니다. 반면에 n 번째 요소를 찾으려면 LinkedList을 따라 가야합니다.

그럼 Collections.synchronizedList(list)에는 어떤 현상이 발생합니까? RandomAccessList -s를 RandomAccess 동기화 목록에 래핑하는 반면, RandomAccess 목록을 RandomAccess 동기화 목록으로 래핑합니다. 그렇지 않으면 그 목록은 동일합니다. 아래 코드는 SynchronizedRandomAccessList입니다. 이것은 programming by difference의 좋은 예입니다. 두 클래스는 거의 동일합니다.

static class SynchronizedRandomAccessList<E> 
    extends SynchronizedList<E> 
    implements RandomAccess { 

    SynchronizedRandomAccessList(List<E> list) { 
     super(list); 
    } 

    SynchronizedRandomAccessList(List<E> list, Object mutex) { 
     super(list, mutex); 
    } 

    public List<E> subList(int fromIndex, int toIndex) { 
     synchronized (mutex) { 
      return new SynchronizedRandomAccessList<>(
       list.subList(fromIndex, toIndex), mutex); 
     } 
    } 

    private static final long serialVersionUID = 1530674583602358482L; 

    /** 
    * Allows instances to be deserialized in pre-1.4 JREs (which do 
    * not have SynchronizedRandomAccessList). SynchronizedList has 
    * a readResolve method that inverts this transformation upon 
    * deserialization. 
    */ 
    private Object writeReplace() { 
     return new SynchronizedList<>(list); 
    } 
} 

RandomAccess 인터페이스의 요점은 무엇입니까? Holger이 지적했듯이 Collections.binarySearch()은이 인터페이스를 기반으로 결정합니다. 또 다른 예는 Collections.reverse()입니다.

Answer 2

RandomAccess 마커 인터페이스의 원래 목적을 기억해야합니다. List을 다른 방법으로 전달하면 임의 액세스 또는 순차적 목록에 적합한 알고리즘을 선택할 수 있어야합니다. 올바른 알고리즘을 선택하려면 list instanceof RandomAccess을 통해 마커 인터페이스를 테스트해야합니다.

방금, 이러한 모든 방법을 볼 수있는 List 인터페이스를 구현하는 다른 객체로 목록을 포장하는 경우 one example

public static <T> 
int binarySearch(List<? extends Comparable<? super T>> list, T key) { 
    if (list instanceof RandomAccess || list.size()<BINARYSEARCH_THRESHOLD) 
     return Collections.indexedBinarySearch(list, key); 
    else 
     return Collections.iteratorBinarySearch(list, key); 
} 

는 지금

(또한 reverse, shuffle, copy 및 fill 참조) 표시하려면 , 래퍼 개체이므로이 정보는 손실됩니다. 그러나 동기화 된 목록과 같은 래퍼는 get과 같은 임의 액세스 방법의 시간 복잡도를 변경하지 않습니다. 따라서 래핑 된 목록이 임의 액세스 목록 인 경우 래퍼는 RandomAccess도 구현해야하므로 이러한 래퍼를 수신하는 메서드는 빠른 임의 액세스를 사용할 수 있는지 여부를 여전히 감지 할 수 있습니다.

당신이 implementation of SynchronizedRandomAccessList 보면, 당신이하지 모두가 SynchronizedList을 확장하고 동작을 상속, RandomAccess 구현 및 빠른 랜덤 액세스를 필요로 자신을 표시되는 것을 볼 수 있습니다. 재정의하는 유일한 방법은 정확히 같은 이유로 subList입니다. 목록에 효율적인 무작위 액세스가있는 경우 해당 하위 목록도 있으므로 RandomAccess도 구현해야합니다. checkedList 같은 다른 래퍼 공장 같은 패턴을 따르는 것이

는

static class SynchronizedRandomAccessList<E> 
    extends SynchronizedList<E> 
    implements RandomAccess { 

    SynchronizedRandomAccessList(List<E> list) { 
     super(list); 
    } 

    SynchronizedRandomAccessList(List<E> list, Object mutex) { 
     super(list, mutex); 
    } 

    public List<E> subList(int fromIndex, int toIndex) { 
     synchronized (mutex) { 
      return new SynchronizedRandomAccessList<>(
       list.subList(fromIndex, toIndex), mutex); 
     } 
    } 

참고. 거짓