Onkar Joshi's blog

You have a List in your application that is traversed or iterated over very frequently but is modified very rarely. Like a ‘Top 10′ kind of list on your home page which is served for every hit to the home page (think hundreds of hits per second) and is updated by an hourly Quartz job.

If you use an ArrayList for that list and no synchronization, you run the risk of a ConcurrentModificationException being thrown every hour when the list is modified by the Quartz job because the list may currently be in the middle of a traversal or iteration for a user visiting your homepage.

One way a person might try to fix it is to use a Vector or rather Collections.synchronizedList(List<T>). But this doesn’t help! While add(), remove(), get() will now be thread-safe on the list, Iterators will still throw ConcurrentModificationException! You will need to synchronize on the list object before iterating on it as well as in the Quartz job where you modify it. That’s just terrible from a performance and scalability point of view! Synchronization will be needed everywhere and all the time just because of an hourly modification.

Fortunately, there is a better solution. Use a CopyOnWriteArrayList.

Whenever a structural modification is made to this list, a new copy is created. This is not inefficient if modifications happen rarely. Iterators on this will not experience a ConcurrentModification because the list they started iterating on is never modified.

Another way one may try to avoid Concurrent Modification without adding synchronization code all over is to build a new List in their scheduled job and then switch out the reference which is used for iteration with the new list. Assigning a reference is an atomic operation in the JVM. This approach would fail if the code doing the iteration used an old style for loop - for (int i=0; i<list.size(); i++) { … list.get(i) …}. A change in the size of the switched list introduces a failure point. Worse, there are visibility problems here since the changes from a different thread may not be seen at all. Using the volatile keyword may help see the changes to the reference from a different thread, but the changed list size would still be a problem.

The memory consistency and happens-before guarantees of Copy On Write Array List make these problems disappear. Also, the code is simple since one doesn’t need to use volatile or synchronized. Less code, less bugs!

Another use case for CopyOnWriteArrayList is the case of the Observer design pattern. If event listeners are added and removed by multiple threads, it is quite possible that using a CopyOnWriteArrayList might be appropriate for correctness and simplicity.

Hope this helps. Remember to get your code reviewed by your nearest concurrency guru!