只需要set就可以了,你可以自己想一下是什么原因,这样写肯定不行,本身的list在循环里面怎么能一直加呢?循环什么时候结束呢!当然加的你可以这么想,真实原因如下: jdk5.0以上的for-each也是利用内部的iterator来遍历集合的(跟以前的iterator一样) 获得的Iterator是一个内部类产生的迭代器,这个迭代器在调用next方法时,会检查列表是否被修改过,如果被修改过,就会抛出ConcurrentModificationException异常。进一步说,当使用 fail-fast iterator 对 Collection 或 Map 进行迭代操作过程中尝试直接修改 Collection / Map 的内容时,即使是在单线程下运xi,java.util.ConcurrentModificationException 异常也将被抛出。Iterator 是工作在一个独立的线程中,并且拥有一个 mutex 锁。 Iterator 被创建之后会建立一个指向原来对象的单链索引表,当原来的对象数量发生变化时,这个索引表的内容不会同步改变,所以当索引指针往后移动的时候就找不到要迭代的对象,所以按照 fail-fast 原则 Iterator 会马上抛出 java.util.ConcurrentModificationException 异常。 所以 Iterator 在工作的时候是不允许被迭代的对象被改变的。但你可以使用 Iterator 本身的方法 remove() 来删除对象,Iterator.remove() 方法会在删除当前迭代对象的同时维护索引的一致性。 有意思的是如果你的 Collection / Map 对象实际只有一个元素的时候, ConcurrentModificationException 异常并不会被抛出。这也就是为什么在 javadoc 里面指出: it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
在遍历集合的时候,不能做add或者是remove操作, 根据源码,好像是因为集合类里面有一个类似版本号之类的属性modCount, expectedModCount在初始化时候是跟modCount的值一样的,但是当你进行add或者remove时,会对modCount进行+1操作, 当你对迭代中的集合进行add或者remove操作时,每次会去比较modCount == expectedModCount??, 如果不等,则抛出throw new ConcurrentModificationException();
说简单点,你值得拥有是:for(ListIterator iter = list.listIterator(); iter.hasNext();) { VmInfo vm = (VmInfo) iter.next(); vm.setName(xx); iter.add(vm); }
jdk5.0以上的for-each也是利用内部的iterator来遍历集合的(跟以前的iterator一样) 获得的Iterator是一个内部类产生的迭代器,这个迭代器在调用next方法时,会检查列表是否被修改过,如果被修改过,就会抛出ConcurrentModificationException异常。进一步说,当使用 fail-fast iterator 对 Collection 或 Map 进行迭代操作过程中尝试直接修改 Collection / Map 的内容时,即使是在单线程下运xi,java.util.ConcurrentModificationException 异常也将被抛出。Iterator 是工作在一个独立的线程中,并且拥有一个 mutex 锁。 Iterator 被创建之后会建立一个指向原来对象的单链索引表,当原来的对象数量发生变化时,这个索引表的内容不会同步改变,所以当索引指针往后移动的时候就找不到要迭代的对象,所以按照 fail-fast 原则 Iterator 会马上抛出 java.util.ConcurrentModificationException 异常。 所以 Iterator 在工作的时候是不允许被迭代的对象被改变的。但你可以使用 Iterator 本身的方法 remove() 来删除对象,Iterator.remove() 方法会在删除当前迭代对象的同时维护索引的一致性。 有意思的是如果你的 Collection / Map 对象实际只有一个元素的时候, ConcurrentModificationException 异常并不会被抛出。这也就是为什么在 javadoc 里面指出: it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
根据源码,好像是因为集合类里面有一个类似版本号之类的属性modCount,
expectedModCount在初始化时候是跟modCount的值一样的,但是当你进行add或者remove时,会对modCount进行+1操作,
当你对迭代中的集合进行add或者remove操作时,每次会去比较modCount == expectedModCount??,
如果不等,则抛出throw new ConcurrentModificationException();
VmInfo vm = (VmInfo) iter.next();
vm.setName(xx);
iter.add(vm);
}