Über LinkedBlockingQueue Iterator nie ConcurrentModificationException

Question

Paket werfen java.util.concurrent.ThreadPoolExecutor die folgende Methode hat:

public void purge() { 
    final BlockingQueue<Runnable> q = workQueue; 
    try { 
     Iterator<Runnable> it = q.iterator(); 
     while (it.hasNext()) { 
      Runnable r = it.next(); 
      if (r instanceof Future<?> && ((Future<?>)r).isCancelled()) 
       it.remove(); 
     } 
    } catch (ConcurrentModificationException fallThrough) { 
     // Take slow path if we encounter interference during traversal. 
     // Make copy for traversal and call remove for cancelled entries. 
     // The slow path is more likely to be O(N*N). 
     for (Object r : q.toArray()) 
      if (r instanceof Future<?> && ((Future<?>)r).isCancelled()) 
       q.remove(r); 
    } 

    tryTerminate(); // In case SHUTDOWN and now empty 
} 

Es gibt eine Ausnahme ConcurrentModificationException, aber in Java doc kann ich sehen:

Der zurückgegebene Iterator ist ein „schwach konsistenter "Iterator, der niemals ConcurrentModificationException auslöst und garantiert, dass Elemente durchquert werden, wie sie bei der Konstruktion des Iterators existierten, und möglicherweise (aber nicht garantiert) alle Modifikationen nach der Konstruktion widerspiegelt.

Bitte sagen Sie mir, wie Sie es verstehen.

Answer 1

Wie Sie im ThreadPoolExecutor Constructor sehen können, können Sie es mit jedem BlockingQueue

public ThreadPoolExecutor(int corePoolSize, 
          int maximumPoolSize, 
          long keepAliveTime, 
          TimeUnit unit, 
          BlockingQueue<Runnable> workQueue) 

liefern Es kann eine eigene Implementierung, die nicht schwach konsistent sein muss, und wenn es nicht zu werfen hat ConcurrentModificationException entweder dies ist die übliche Ausnahme, die geworfen wird, so dass einige defensive Programmierung von Java-Entwicklern ist.