Как можно CopyOnWriteArrayList быть потокобезопасным?

Question

Я просмотрел OpenJDK source code из CopyOnWriteArrayList и кажется, что все операции записи защищены одной и той же блокировкой, и операции чтения вообще не защищены. Насколько я понимаю, под JMM все обращения к переменной (как чтение, так и запись) должны быть защищены блокировкой или переупорядочением.

Например, set(int, E) метод содержит следующие строки (под замком):

/* 1 */ int len = elements.length; 
/* 2 */ Object[] newElements = Arrays.copyOf(elements, len); 
/* 3 */ newElements[index] = element; 
/* 4 */ setArray(newElements); 

get(int) метод, с другой стороны, только делает return get(getArray(), index);.

В моем понимании JMM это означает, что get может наблюдать массив в несогласованном состоянии, если операторы 1-4 переупорядочиваются как 1-2 (новый) -4-2 (copyOf) -3.

Не понимаю ли я JMM или есть ли какие-либо другие объяснения, почему CopyOnWriteArrayList является потокобезопасным?

Answer 1

Если вы посмотрите на ссылку на базовый массив, вы увидите, что она помечена как volatile. Когда происходит операция записи (например, в приведенном выше извлечении), эта ссылка volatile обновляется только в окончательном отчете через setArray. До этого момента любые операции чтения возвращают элементы из старой копии массива.

Важным моментом является то, что обновление массива представляет собой атомную операцию, и поэтому считывания всегда будут видеть массив в согласованном состоянии.

Преимущество только снятия блокировки для операций записи улучшает пропускную способность для чтения: это связано с тем, что операции записи для CopyOnWriteArrayList могут быть очень медленными, поскольку они включают в себя копирование всего списка.

Answer 2

Получение ссылки на массив является атомной операцией. Таким образом, читатели либо видят старый массив, либо новый массив - в любом случае состояние согласовано. (set(int,E) вычисляет новое содержимое массива перед установкой ссылки, поэтому массив соответствует, когда asignment сделан.)

Массив ссылки сам помечается как volatile так, чтобы читатели не должны использовать блокировку, чтобы увидеть изменения ссылочный массив. (EDIT: Кроме того, volatile гарантирует, что присвоение не будет переупорядочено, что приведет к выполнению задания, когда массив, возможно, находится в несогласованном состоянии.)

Блокировка записи необходима для предотвращения одновременной модификации, которая может привести к тому, что массив удерживает несогласованные данные или изменения теряются.