A propos LinkedBlockingQueue iterator jamais jeter ConcurrentModificationException

Question

Package java.util.concurrent.ThreadPoolExecutor a la méthode suivante:

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 
} 

Il y a une exception ConcurrentModificationException, mais en Java doc je peux voir:

L'itérateur retourné est un « faible "itérateur cohérent" qui ne lèvera jamais ConcurrentModificationException, et garantit de parcourir les éléments tels qu'ils existaient lors de la construction de l'itérateur, et peut (mais n'est pas garanti) refléter toute modification postérieure à la construction.

S'il vous plaît dites-moi comment comprendre.

Answer 1

Comme vous pouvez le voir dans le vous pouvez fournir avec toute BlockingQueue

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

Constructor ThreadPoolExecutor Il peut être votre propre implémentation qui ne doit pas être faiblement cohérente et bien qu'il ne doit pas jeter ConcurrentModificationException soit c'est l'exception habituelle qui est lancée, donc c'est une programmation défensive par les développeurs Java.