I got a ConcurrentModificationException (CME) during run-time.
What does it mean?
It means that you’ve updated your collection while iterating over it (single or multi-threaded alike).
A few more things to know:
Best effort detection - First off, consider yourself lucky, CMEs are thrown only in best effort, so another universe, your collection could have became corrupted instead of fast-failing and and the operation and issuing you a warning.
Identifying the collection – Like deadlocks, CME’s are easy to pinpoint once you inspected the exception’s stack trace.
Solving it:
- ListIterator
If you’re single threaded, consider solving the CME by manipulating the collection via the ListIterator interface instead of directly.
Advantages – simple.
Drawbacks – single threaded model oriented. - Synchronizers
Use locks to obtain mutual exclusion in collection R/W operations.
Advantages – easy to code.
Drawbacks – lock overhead for reading operations - Copy-on-write
Either Java.util.concurrent collections like: CopyOnWriteArrayList, CopyOnWriteArraySet. Or for a map: grab CopyOnWriteMap from Apache (this guys have been doing Sun’s dirty work for years now).
Advantages – very good reading performance (switching locks for volatile).
Drawbacks – very bad write performance on large maps.
Conclusion – use for seldom mutating collections. - Concurrent Collections
If you want to go heavyweight, consider using: ConcurrentHashMap (or one of its package friends).
Once you create an iterator over a ConcurrentHashMap, it does not freeze the collection for traversal, updates to the collection may or may not appear during the traversal (weakly consistent).
the approach I ended up taking:
My use case was populating an almost never changing ~ten items cache. A copyonwrite map was the best choice, I believe.

Some sites like 


Someone told me that the stats that the reliability of the performance indicators that the graphic VI console shows is questionable and it’s recommended using the terminal utilities.So, I SHHed to the service console VM and ran the top utility. Immediately, I understood that what I’m actually doing is surveying the service console VM processes, rather than the overall ESX hypervisor activity. A quick dig up made me realize that the hypervisor is visible through the esxtop command, which is also executed from within the service console VM.
One new serviceability artifact that I have long ago really wanted to have in production was the verbose GC, this feature records the JVM garbage collection activity over time, providing insight for resolving issues such as: stop-the-world performance freezes, memory leaks, native heap corruption, etc.
A trigger for action
Via e-mail