-
Bug
-
Resolution: Fixed
-
P4
-
1.2.1, 1.4.0
-
beta
-
x86
-
windows_nt
-
Verified
Name: jb33418 Date: 01/31/2000
java version "1.2.1"
Classic VM (build JDK-1.2.1-A, native threads)
There is a very nagging problem in my code: I used
"Collections.getSynchronizedList(new LinkedList())" to get a linked list. I
expect it to be full thread safe, however, every once in a while, I found lost
LinkList node. In tracking down the problem, I SUSPECT (no proof case yet) that
it was due to concurrent access to the list. According to the documentation for
the java.util.LinkedList, "
List list = Collections.synchronizedList(new LinkedList(...));
The iterators returned by the this class's iterator and listIterator methods are
fail-fast: if the list is structurally modified at any
time after the iterator is created, in any way except through the Iterator's own
remove or add methods, the iterator will throw a
ConcurrentModificationException. Thus, in the face of concurrent modification,
the iterator fails quickly and cleanly, rather than
risking arbitrary, non-deterministic behavior at an undetermined time in the
future. "
I assumed that, as long as I use the iterator from listIterator(), it will be
thread safe. However, looking at the source code, I found out that the remove()
in the private ListIterator class inside java.util.LinkedList does NOT call the
checkComodication() method, which is apparently used to check the modification
count matches. Could you tell me why?
Another related question is that the documentation for
Collections.synchronizedList(List) says that I still have to lock the list for
iteration. Does that mean I will get an ConcurrentModificationException if I
don't? It seems all the add/get/set/remove are synchronized but the listIterator
is not, it is quite confusing...
(Review ID: 99335)
======================================================================
- duplicates
-
JDK-4363349 java.util.LinkedList remove in iterator did not fail fast
-
- Closed
-