CopyOnWriteArrayList数组复制替换机制及线程访问逻辑咨询

Let’s break down your questions with practical implementation details from CopyOnWriteArrayList to make things concrete.

1. How does CopyOnWriteArrayList replace the original array with a copy, and when does this replacement happen? #

Under the hood, CopyOnWriteArrayList relies on a private transient volatile Object[] array field to store its elements. The volatile modifier is critical here—it ensures any changes to the array reference are immediately visible to all threads.

For a typical mutable operation like add(), here’s the step-by-step process:

• First, the method grabs a ReentrantLock to block other concurrent mutable operations (preventing messy overlapping copy operations).
• It creates a full copy of the current underlying array.
• The new element is added to this copy (never the original array—so the original stays untouched during modification).
• Once the copy is fully updated and ready, the setArray() method runs. This is just a simple assignment: array = newElements—this is the actual "replacement" of the original array reference.
• Finally, the lock is released.

The replacement happens at the very end of the mutable operation, right after the new array is fully prepared, and before the lock is let go. Thanks to the volatile field, this assignment is atomic and instantly visible to every other thread.

2. After a mutable operation completes, do all threads always work on their own local copies? How is the copy replaced for other threads, and when does this replacement occur? #

Nope, threads don’t stick to local copies forever—here’s the breakdown:

• Threads running mutable operations: When a thread starts a mutable action (like add or set), it creates a private copy of the array, modifies that copy, and only swaps the original reference once the change is done. During this process, it’s exclusively working on its own copy.
• Threads running read operations: Reads (like get() or iterating) don’t use locks. They directly access the current array reference. Before the mutable operation finishes, they’ll read the original array. Once the replacement (setArray() call) happens, any subsequent read from any thread will pick up the new array reference and work with the updated data.

The replacement for other threads is handled entirely by the volatile array field:
When the modifying thread assigns the new array to the volatile array field, Java’s memory model guarantees this write is flushed to main memory immediately. Any thread reading the array field after this point will fetch the latest reference from main memory, effectively switching to the new array. This replacement happens at the same stage as the first question—right after the new array is fully modified, before the lock is released.

One quick note: Iterators created before the mutable operation will still reference the old array (they’re fail-safe, not fail-fast), so they won’t see the new changes until you create a fresh iterator.

内容的提问来源于stack exchange，提问作者vijayinani