se sincroniza el método toArray() de Collection sincronizado?

Question

Si tengo una colección sincronizada como esto

Collection c = Collections.synchronizedCollection(myCollection);

Javadoc para las synchronizedCollection mentiones esa iteración externo deben estar sincronizados como esto:

synchronized (c) { 
Iterator i = c.iterator(); 
while (i.hasNext()) { 
    process (i.next()); 
} 
} 

¿Puedo asumir que c.toArray() está sincronizado y por lo tanto no se los cambios en la colección ocurrirán cuando el método se ejecute?

o necesito para sincronizarlo así:

synchronized (c) { 
    c.toArray(); 
} 

Answer 1

Desde el Javadoc para synchronizedCollection:

devuelve una colección sincronizada (thread-safe) respaldado por la colección especificada.

Por lo tanto, c.toArray() no requiere ninguna sincronización adicional. El método SynchronizedCollection de toArray() hará el bloqueo por usted. En esencia, ese es el objetivo de synchronizedCollection().

Si desea confirmar que esta lectura del contrato concuerda con la implementación real, consulte GrepCode.

Answer 2

Si está hablando de la utilidad de recolección de commons de Apache, la respuesta es sí. CollectionUtils.synchronizedCollection(...) devuelve una instancia de SynchronizedCollection que está toArray() método es:

public Object[] toArray() { 
     synchronized (lock) { 
      return collection.toArray(); 
     } 
    } 

Answer 3

Usted no lo necesita, el método realiza la sincronización para usted.

Answer 4

Si está utilizando java.util.Collections que forma parte de la API de recopilación de Java estándar, todos los métodos en la SynchronizedCollection devuelta se sincronizarán incluyendo toArray(). Vea los bloques de código a continuación, tomados del código fuente de Java en java.util.Collections.SynchronizedCollection.

public Object[] toArray() { 
    synchronized(mutex) {return c.toArray();} 
} 

public <T> T[] toArray(T[] a) { 
    synchronized(mutex) {return c.toArray(a);} 
} 

Answer 5

Parece que hay una gran idea errónea de que puede confiar en la implementación real del código fuente. Esto es falso, debe confiar en el contrato del método. Dado que el contrato no existe, no puede suponer que hará algo, en cualquier momento la implementación subyacente puede cambiar. Por ejemplo, observe la siguiente función:

/** 
* Returns an empty Collection of Books. 
* 
* 
*/ 
public Collection returnEmptyBooks() 
{ 
    return new HashSet<Book>(); 
} 

Esto implica que puedo devolver cualquier cosa que implemente la interfaz de Colección. Firma más documentación. No se puede suponer que esté sincronizado o cualquier otra cosa de esa naturaleza. También podría deducir que nunca volverá a obtener null de este método, a menos que el contrato haya sido violado.

En caso de que nadie lea los comentarios. Cualquier conversión de una estructura de datos a otra implica iteración. No puede pasar de List a Set sin iterar sobre todos los elementos. Lo mismo se aplicaría con una conversión a una matriz. Debe completar la matriz iterando sobre su estructura de datos inicial, por lo tanto, debe estar sincronizada.