Java中List的size为何小于0？LinkedList出现Size:-1异常原因排查

Absolutely—this is almost certainly a concurrency bug caused by unsafe multi-threaded access to a LinkedList, which is not thread-safe by design.

Let’s break this down:

First, LinkedList’s size field is a simple int that tracks the number of elements. Unlike thread-safe collections (like ConcurrentLinkedQueue or CopyOnWriteArrayList), there’s no synchronization or atomicity guarantees around updates to this field. Operations like add(), remove(), or clear() modify size with non-atomic steps (e.g., size++ is actually read-increment-write, three separate operations). When multiple threads perform these operations at the same time, race conditions can corrupt the size value:

• For example, if two threads try to decrement size simultaneously, one thread’s write might overwrite the other in a way that leads to an incorrect negative value.
• Or, an interrupted or partially completed modification (due to concurrent access) could leave size out of sync with the actual elements in the list, resulting in invalid values like -1.

The error stack you shared confirms this corruption:

java.lang.IndexOutOfBoundsException: Index: 0, Size: -1 at java.util.LinkedList.checkPositionIndex(LinkedList.java:560) at java.util.LinkedList.listIterator(LinkedList.java:867) at java.util.AbstractList.listIterator(AbstractList.java:299) at java.util.AbstractSequentialList.iterator(AbstractSequentialList.java:239) at //foreach loop over list

In normal circumstances, LinkedList’s size should never be negative—this is a clear sign that the collection’s internal state has been corrupted by unsafe concurrent access.

As for why you can’t reproduce it: concurrency bugs are notoriously hard to replicate because they depend on precise thread timing (e.g., when the JVM switches between threads during the non-atomic size update). The issue only surfaces under specific, rare scheduling conditions.

Here are some steps to address this:

• Replace the LinkedList with a thread-safe alternative like ConcurrentLinkedQueue (if you don’t need random access) or CopyOnWriteArrayList (for read-heavy workloads).
• If you must use LinkedList, wrap it with Collections.synchronizedList() to ensure all access is synchronized. Just remember to manually synchronize when iterating over the list (since the wrapper doesn’t handle that automatically).
• Audit all code paths that modify or access the list to ensure they’re using proper synchronization, especially in multi-threaded contexts.
• For debugging, you could add logging around list operations (with thread IDs) or use tools that influence thread scheduling, though there’s no guarantee this will trigger the issue consistently.

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