How can List have size less than zero in java?

We found this error in our java application log:
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

How is this possible that LinkedList has size less than zero? Could it be concurrency issue if that list is not thread safe? We were not able to reproduce it anyway.

The '-1' in that exception trace is produced by the outOfBoundsMsg private method, which just puts the field size in there.

The size field is modified via size++ and size-- in the relevant methods.

That leaves the following explanations:

1. A corrupt VM. That seems.. unlikely.
2. corrupted memory. That seems.. unlikely.
3. Concurrency issue.

It's LinkedList (see stack trace), which is not thread safe (in fact, there are very few use cases where linkedlist is the right answer, if you never use LinkedList in your programming career you're probably using it about the right amount).

The concurrency issue is trivially explained (any given field may, or may not - entirely up to the VM and the phase of the moon right now, exist the way schroedinger's cat does: Each thread has a fleeting copy of it that they modify, synchronizing it up (with conflicts resolved arbitrarily) from time to time).

The way the VM is set up, you're supposed to write code so that this cannot be observable to you; not to write code that for example predicts the arbitrary sync moments, which you can't.

As with most issues stemming from concurrency issues, it is extremely difficult to reliably reproduce stuff like this. It depends on which music was playing in your winamp and whatnot.

To fix it:. You could try to guard all access to this list with a synchronized() block, or just wrap the list in Collections.synchronizedList, but whilst that will avoid these bizarre situations where fields end up containing invalid values, that is unlikely to truly solve anything. Code like this:

if (!list.contains(a)) list.add(a);

can never work right, even if the list is 'synchronized': Synchronized means any single call is considered atomic, but that's 2 calls to list. Other code is free to add 'a' in the middle of the contains call and the add call: Hence why synchronized lists are rarely what you wanted.

More likely you want a list that is more suitable to the job, probably from the java.util.concurrent package. Possibly you want to do all communication between threads through a channel that supports transactions or otherwise is designed to be good for inter-thread comms. Think 'database, such as postgres, using transactions' or 'message queue system such as rabbitmq'.

To show how to work with data like this in a concurrent fashion:

synchronized(list) {
    if (!list.contains(a)) list.add(a);
}

Assuming all accesses to this list are done with a synchronized guard, the above will work, and will never result in a being in the list twice.

Or, think about your data structures. In this hypothetical example, a set feels more logical if the aim is not to have the same item in the list twice. Make sure you use the 'primitives' that the collection exposes:

Set<String> set = ConcurrentHashMap.newKeySet();
...
set.add(a); // safe, no need for a synchronized block

or another example with map:

Map<Integer, List<String>> m = new ConcurrentHashMap<>();

//unsafe:
if (!m.containsKey(1)) m.put(1, new ArrayList<String>());

// safe:
m.computeIfAbsent(1, a -> new ArrayList<String>());