es el sistema ConcurrentModificationException dependiente lanzando

Question

estoy trabajando en una pieza de código con el iterador y conseguir un ConcurrentModificationException en la línea de una cuando corro el programa de mi IDE en windows--

LinkedList ll =new LinkedList(); 
    . . . 
    . . . 
    Iterator iter = ll.iterator(); 
    int i=0; 
    while (iter.hasNext()) { 
     // GrammarSection agrammarSection = (GrammarSection) iter.next(); //a 
     String s1 = (String) iter.next(); 
     ll.remove(i); 
     i++; 
    } 

Se espera porque Im modificando la lista mientras estoy iterando para que el iterador de fail-fast arroje una excepción de modificación concurrente. Sin embargo, cuando ejecuto este código en Unix con el servidor Apache, el siguiente método del iterador no arroja ninguna excepción. Entonces, ¿la excepción de modificación simultánea depende del nivel de SO?

Answer 1

No, no debería. Debería bloquearse de todos modos.

Supongo que podría ser diferente en una JVM diferente, pero de acuerdo con official spec, los iteradores en la lista vinculada deberían fallar.

El sistema operativo no tiene nada que ver con eso.

Answer 2

Descubrí cuál podría ser el problema. Cuando su lista tiene 2 elementos, hasNext() devuelve false y funciona sin excepción. Si la lista tiene 3 o más elementos arroja una excepción en todas partes. Así que asegúrese de que su lista tenga la cantidad correcta de elementos.

En cuanto a la dependencia OS - código Java no depende del sistema operativo

De todos modos - Utilización iter.remove() - le van a quitar el elemento de la lista subyacente sin causar la excepción.

El problema con su enfoque es que está modificando la lista subyacente sin que el iterador sepa nada de esa modificación. Entonces debes llevarlo a cabo a través del iterador.

Answer 3

Utilice iter.remove(); no ll.remove (i)

Si utiliza la función de eliminación del iterador, no obtendrá una excepción de modificación concurrente.

Sin embargo, para responder a su pregunta; el CME no debe depender del nivel del sistema operativo. Debe haber algún otro problema con su código sobre por qué no está lanzando CME en Unix.

Por cierto, la especificación de los siguientes comentarios

"Tenga en cuenta que el comportamiento a prueba de ayuno de un repetidor no puede ser garantizada, ya que es, en general, imposible ofrecer ninguna garantía duros en presencia de la modificación concurrente no sincronizado Los iteradores a prueba de errores lanzan ConcurrentModificationException sobre la base del mejor esfuerzo. Por lo tanto, sería incorrecto escribir un programa que dependiera de esta excepción para su corrección: el comportamiento a prueba de fallas de los iteradores debería usarse solo para detectar errores ".

Answer 4

Entonces, ¿la excepción concurrentmodification depende del nivel del sistema operativo?

Tiene dependencia de JMV, pero no en el código que mostró.

// LinkedLists have a member variable called modCount 
// which is an integer which holds the count of modifications 
// made on the list with methods like list.add() list.remove() etc. 
LinkedList ll =new LinkedList(); 
. . . 
. . . 
// When the iterator is created here, it copies the current modCount 
// of the LinkedList into a member of its own called expectedModCount 
Iterator iter = ll.iterator(); 
int i= 0; 
while (iter.hasNext()) { 
    // iter.next() calls a method called checkForComodification 
    // which throws a ConcurrentModificationException if the 
    // current modCount of the original LinkedList is different 
    // from the expectedModCount on this iterator 
    String s1 = (String) iter.next(); 
    ll.remove(i); 
    i++; 
} 

Cuando se accede a la lista y itera en diferentes hilos sin sincronización correcta, la modificación hecha a LinkedList.modCount (cuando LinkedList.add, LinkedList.remove etc son llamados) podría no ser visible para el hilo haciendo la iteración.Por lo tanto, no se garantiza el lanzamiento de ConcurrentModificationException s en general. Pero en el código de un solo subproceso que mostró, no debería haber problemas de visibilidad y la excepción siempre se debe lanzar si se llama alguna vez ll.remove() con éxito después de ll.iterator().