{"id":722,"date":"2026-10-02T14:05:00","date_gmt":"2026-10-02T12:05:00","guid":{"rendered":"https:\/\/grindloop.io\/blog\/?p=722"},"modified":"2026-09-30T23:13:08","modified_gmt":"2026-09-30T21:13:08","slug":"listener-removes-itself-concurrentmodificationexception","status":"publish","type":"post","link":"https:\/\/grindloop.ai\/blog\/listener-removes-itself-concurrentmodificationexception\/","title":{"rendered":"Why a Listener That Removes Itself Throws ConcurrentModificationException"},"content":{"rendered":"

A listener that unregisters itself inside its callback changes the list while a for<\/code> loop still walks it. Kotlin’s for<\/code> loop runs on the list’s iterator. The iterator of ArrayList<\/code> is fail-fast. It notices the structural change and throws ConcurrentModificationException<\/code> on the next call to next()<\/code>. No second thread is involved. A second cause makes the bug hard to pin down. Whether the loop crashes depends on where the listener sits in the list. It also depends on the runtime, because the JVM and Android decide hasNext()<\/code> differently. In one position, each runtime ends the loop early with no crash. The remaining listener never hears the event. So a JVM unit test can pass while the phone crashes. Copying the list stops the crash. But the copy still calls a listener that an earlier listener just removed. The fix is to iterate a snapshot and check each listener is still registered before calling it.<\/p>\n\n

A sync tracker that crashes on one thread<\/h2>\n\n

The running example is a SyncTracker<\/code>. It tells every registered screen when a background sync ends. One caller wants the event only once, so its listener unregisters itself on the first call. Everything runs on the main thread.<\/p>\n\n\n

fun interface SyncListener { fun onSyncFinished(ok: Boolean) }\n\nclass SyncTracker {\n    private val listeners = mutableListOf<SyncListener>()\n\n    fun register(l: SyncListener) { listeners += l }\n    fun unregister(l: SyncListener) { listeners -= l }\n\n    fun notifyFinished(ok: Boolean) {\n        for (l in listeners) l.onSyncFinished(ok)\n    }\n}\n\n\/\/ A one-shot caller: show a snackbar once, then stop listening\ntracker.register(object : SyncListener {\n    override fun onSyncFinished(ok: Boolean) {\n        showSnackbar(ok)\n        tracker.unregister(this)\n    }\n})<\/pre>\n\n\n
Here are four registration orders run through this class on the JVM, with Kotlin 2.4.20. The backing list is a java.util.ArrayList<\/code>. Each line shows which listeners were called before the loop stopped.<\/p>\n\n\n
toast, oneShot, badge   -> no crash, called=[toast, oneShot]\na, b, oneShot, badge    -> no crash, called=[a, b, oneShot]\noneShot, toast, badge   -> ConcurrentModificationException, called=[oneShot]\ntoast, badge, oneShot   -> ConcurrentModificationException, called=[toast, badge, oneShot]<\/pre>\n\n\n
Two of the four orders crash. In the other two, nothing is thrown. But badge<\/code> never gets the event. That silent case is worse than the crash, because nothing in the logs points at it.<\/p>\n\n
Why ConcurrentModificationException fires on a single thread<\/h2>\n\n
The Kotlin control-flow docs<\/a> say the for<\/code> loop “iterates through anything that provides an iterator.” A collection provides one by default. So for (l in listeners)<\/code> calls listeners.iterator()<\/code>, then hasNext()<\/code> and next()<\/code> on each pass. listeners.forEach { }<\/code> is an inline function over the same iterator, so it fails the same way.<\/p>\n\n
The Java 21 ArrayList<\/code> reference<\/a> calls that iterator fail-fast. A structural change made outside the iterator’s own remove<\/code> or add<\/code> makes it throw ConcurrentModificationException<\/code>. Removing an element counts as structural. The list tracks this with a counter called modCount<\/code>. The iterator copies the counter when it’s created. In the OpenJDK source<\/a>, next()<\/code> compares the two before returning anything.<\/p>\n\n
Here “concurrent” means during iteration. No other thread is involved. The one-shot listener calls unregister(this)<\/code> from inside the loop body. That bumps modCount<\/code>. The next call to next()<\/code> sees the mismatch and throws.<\/p>\n\n
hasNext() decides whether you crash or silently skip<\/h2>\n\n
The check lives in next()<\/code>, not in hasNext()<\/code>. If hasNext()<\/code> returns false first, the loop ends quietly. That’s the second cause. It differs by runtime.<\/p>\n\n
On the JVM, OpenJDK’s hasNext()<\/code> returns cursor != size<\/code>. It reads the live size. Say the one-shot listener is third of four. After it runs, the cursor is 3 and the size has dropped to 3. hasNext()<\/code> says false. The loop exits. The fourth listener is skipped without an error.<\/p>\n\n
Android doesn’t run OpenJDK’s class unchanged. AOSP’s libcore<\/code> copy of ArrayList<\/code><\/a> marks an “Android-changed” limit<\/code> field. It stores the size at the moment the iterator is created. hasNext()<\/code> returns cursor < limit<\/code>. The AOSP comment says this keeps hasNext()<\/code> stable while elements are added or removed. The side effect flips which position is silent.<\/p>\n\n
The model below copies both hasNext()<\/code> rules. It keeps the same modCount<\/code> check in next()<\/code>. It runs as plain Kotlin on the JVM. So the Android column comes from the AOSP source above, not from ART.<\/p>\n\n\n
class ModelList<T>(private val androidRule: Boolean) : Iterable<T> {\n    private val items = ArrayList<T>()\n    private var modCount = 0\n    fun add(x: T) { items.add(x); modCount++ }\n    fun remove(x: T) { if (items.remove(x)) modCount++ }\n\n    override fun iterator() = object : Iterator<T> {\n        val limit = items.size \/\/ Android: size captured at creation\n        var cursor = 0\n        val expected = modCount\n        override fun hasNext() =\n            if (androidRule) cursor < limit else cursor != items.size\n        override fun next(): T {\n            if (modCount != expected) throw ConcurrentModificationException()\n            return items[cursor++]\n        }\n    }\n}<\/pre>\n\n\n\n
oneShot at index 0 of 4 | JVM: CME                          | Android: CME\noneShot at index 1 of 4 | JVM: CME                          | Android: CME\noneShot at index 2 of 4 | JVM: no crash, L3 never called    | Android: CME\noneShot at index 3 of 4 | JVM: CME                          | Android: no crash<\/pre>\n\n\n
The JVM rows match the real ArrayList<\/code> run from the first section. That matters for tests. Local unit tests<\/a> run on your workstation’s JVM, not on a device. A test that registers the one-shot listener third of four doesn’t crash there. The same order crashes on the phone. Put it last and the reverse happens.<\/p>\n\n
The Java docs warn against leaning on any of this. They say the exception is thrown “on a best-effort basis.” Code that depends on it for correctness is wrong.<\/p>\n\n
Copying the list stops the crash but calls a removed listener<\/h2>\n\n
The usual first fix is to iterate a copy: listeners.toList().forEach { }<\/code>. Another is to swap in CopyOnWriteArrayList<\/code>. Both stop the crash. Both also create a new bug once one listener removes a different one.<\/p>\n\n
Extend the example. A navigation listener reacts to the sync by closing a detail screen. Closing the screen unregisters that screen’s listener. The screen’s listener sits after the navigation listener in the list.<\/p>\n\n\n
class DetailScreen(private val log: MutableList<String>) {\n    var destroyed = false\n    val listener = SyncListener {\n        log += if (destroyed) \"screen(DESTROYED)\" else \"screen\"\n    }\n}\n\ntracker.register(oneShot)                  \/\/ unregisters itself\ntracker.register {                         \/\/ navigation\n    screen.destroyed = true\n    tracker.unregister(screen.listener)\n}\ntracker.register(screen.listener)\ntracker.register(badge)<\/pre>\n\n\n\n
toList snapshot      -> [oneShot, nav, screen(DESTROYED), badge]\nCopyOnWriteArrayList -> [oneShot, nav, screen(DESTROYED), badge]<\/pre>\n\n\n
The destroyed screen still gets the event. On a device, that could be a callback touching a view after onDestroyView()<\/code>. The CopyOnWriteArrayList<\/code> reference<\/a> documents why. Its iterator reads a snapshot of the array taken when the iterator was created. It “will not reflect additions, removals, or changes” made after that. toList()<\/code> behaves the same way, because it’s a copy too.<\/p>\n\n
The fix: iterate a snapshot, then recheck membership<\/h2>\n\n\n
@MainThread\nfun notifyFinished(ok: Boolean) {\n    for (l in listeners.toList()) {\n        \/\/ Skip anyone unregistered earlier in this same dispatch\n        if (l in listeners) l.onSyncFinished(ok)\n    }\n}<\/pre>\n\n\n\n
snapshot + recheck   -> [oneShot, nav, badge]<\/pre>\n\n\n
The snapshot makes the loop immune to changes in listeners<\/code>. The membership check keeps removals in effect for the rest of the dispatch. A listener added during the dispatch waits for the next event, because it isn’t in the snapshot. That’s usually what you want. Say it out loud in an interview anyway.<\/p>\n\n
The in<\/code> check is a linear scan. For a handful of listeners, that cost doesn’t matter. If the list is large, back it with a LinkedHashSet<\/code> to keep order and get fast lookups.<\/p>\n\n
This version assumes one thread, so the @MainThread<\/code> annotation documents the contract. If other threads can register, use CopyOnWriteArrayList<\/code> for the storage. Keep the same membership check in the loop.<\/p>\n\n
This is also what LiveData does. LiveData.java<\/code><\/a> stores observers in a SafeIterableMap<\/code><\/a>. Its class comment describes a linked list that “supports modifications during iterations.” Removing an entry updates any live iterator. removeObserver()<\/code> also marks the wrapper inactive. considerNotify()<\/code> checks that flag first. So an observer removed mid-dispatch never gets the value.<\/p>\n\n
What to say when the interviewer hands you this snippet<\/h2>\n\n
    \n
  1. Name the mechanism first. The for<\/code> loop uses the list’s iterator. unregister(this)<\/code> changes the list inside the loop body, so the fail-fast check in next()<\/code> throws. It’s a single-thread bug.<\/li>\n
  2. Explain why it’s intermittent. The check runs only in next()<\/code>. If hasNext()<\/code> says false first, the loop ends silently and later listeners are skipped. Mention that JVM and Android pick different positions for that silent exit.<\/li>\n
  3. Propose the copy, then break it yourself. A snapshot or CopyOnWriteArrayList<\/code> stops the crash. It still calls a listener that an earlier listener removed.<\/li>\n
  4. Give the final version. Iterate a snapshot and recheck membership before each call. Then state the threading contract. Point to LiveData as the same design in androidx.<\/li>\n<\/ol>\n\n
    This fits the spot-the-bug format covered in the Android live-coding round formats<\/a>. Step 3 goes past finding the crash, because you break your own first fix. The debugging round scores that follow-up bug too. See what the debugging round scores after the first fix<\/a>.<\/p>\n\n
    Answers that sound right and still fail<\/h2>\n\n