<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    在多線程的情況下是由Iterator遍歷修改集合對象,報(bào)ConcurrentModificationException()異常的根因分析。

             在多線程下使用Iterator來迭代對象時,總會包ConcurrentModificationException();異常,經(jīng)過我對list和Iterator相關(guān)源碼的分析,終于搞明白了這個問題: 
             下面結(jié)合源代碼來討論這個問題:

              1、當(dāng)我們調(diào)用一個List的iterator時,其實(shí)返回的并不是Itr對象(Iterator是一個接口),請看代碼:
    1  public Iterator<E> iterator() {
    2    return new
     Itr();
    3  }
           
           2、在Itr類中有這么一句話  int expectedModCount = modCount;首先講一下這兩個變量的含義:
                 expectedModCount :創(chuàng)建當(dāng)前的Itr對象時集合對象被修改的次數(shù)。他是Itr的變量。
                 modCount:記錄集合對象從創(chuàng)建到當(dāng)前時間被做修改的次數(shù)。(集合每進(jìn)行一次增刪改查都會使modCount),他是Itr的外部類AbstractList
                 的變量,且該變量在 AbstractList中被如此修飾protected transient int modCount = 0; 
                另外,Itr自己對集合對象進(jìn)行了修改后,他會維持expectedModCount 和modCount的保持相等,請看以下代碼
     1 //Itr的刪除方法
     2 public void remove() {
     3         if (lastRet == -1
    )
     4         throw new
     IllegalStateException();
     5 
                checkForComodification();
     6 

     7         try {
     8         AbstractList.this
    .remove(lastRet);
     9         if (lastRet <
     cursor)
    10             cursor--
    ;
    11         lastRet = -1
    ;
    12         expectedModCount =
     modCount;
    13         } catch
    (IndexOutOfBoundsException e) {
    14         throw new
     ConcurrentModificationException();
    15 
            }
    16     }

                在代碼的12行,Itr保證了expectedModCount 和modCount值的相等 ,modCount的值發(fā)生了改變嗎,他改變了,帶代碼的第8行改變的,請看此處的代碼:
             
     1public E remove(int index) {
     2
        RangeCheck(index);
     3

     4    modCount++
    ;
     5    E oldValue =
     elementData[index];
     6

     7    int numMoved = size - index - 1
    ;
     8    if (numMoved > 0
    )
     9        System.arraycopy(elementData, index+1
    , elementData, index,
    10
                     numMoved);
    11    elementData[--size] = null// Let gc do its work

    12
    13    return oldValue;
    14    }

               在代碼的第四行modCount發(fā)生了改變。 由此可以看出,在我們調(diào)用集合對象的iterator()方法的remove時總會使list的modCount的值自增1,但是Itr會自己維護(hù)該值和expectedModCount 的一致。
           3、試問:如果expectedModCount 和modCount的值如果不相等,會有什么問題呢,這就是報(bào)ConcurrentModificationException();異常的原因所在,請先看Itr的next()方法和next()調(diào)用的方法
     1//Itr的next方法:
     2public E next() {
     3
                checkForComodification();
     4        try 
    {
     5        E next =
     get(cursor);
     6        lastRet = cursor++
    ;
     7        return
     next;
     8        }
     catch(IndexOutOfBoundsException e) {
     9
            checkForComodification();
    10        throw new
     NoSuchElementException();
    11        }

    12    }

    13
    14//checkForComodification()方法:

    15final void checkForComodification() {
    16        if (modCount !=
     expectedModCount)
    17        throw new
     ConcurrentModificationException();
    18    }

    19    }
    20
        在next方法的一開始顯示調(diào)用了checkForComodification()方法(見第三行),在checkForComodification()方法中做的工作就是比較expectedModCount 和modCount的值是否相等,如果不相等,就認(rèn)為還有其他對象正在對當(dāng)前的List進(jìn)行操作,那個就會拋出ConcurrentModificationException異常。
           經(jīng)過以上的分析,發(fā)現(xiàn)拋出ConcurrentModificationException異常處于調(diào)用next()方法時,比較expectedModCount 和modCount的值,如果兩個值不相等,就會拋出異常,然而在什么情況下會使expectedModCount 和modCount的值不相等呢,只有在兩個Itr同時對一個list進(jìn)行操作的時候才會出現(xiàn)這樣的問題,所以在以后的編碼過程中在是由Iterator進(jìn)行remove()時一定要考慮是否時多線程的,如果是請不要用Iterator進(jìn)行remove(),而應(yīng)該使用List的remove方法進(jìn)行。

    posted on 2008-04-01 09:56 linda 閱讀(4448) 評論(3)  編輯  收藏

    評論

    # re: 在多線程的情況下是由Iterator遍歷修改集合對象,報(bào)ConcurrentModificationException()異常的根因分析。 2009-03-27 23:02 梅友龍

    好內(nèi)容,這個說法我接受,謝了  回復(fù)  更多評論   

    # re: 在多線程的情況下是由Iterator遍歷修改集合對象,報(bào)ConcurrentModificationException()異常的根因分析。 2009-03-27 23:03 梅友龍

    我比較喜歡研究技術(shù)的技術(shù)人,有時間可以聊聊~~  回復(fù)  更多評論   

    # re: 在多線程的情況下是由Iterator遍歷修改集合對象,報(bào)ConcurrentModificationException()異常的根因分析。[未登錄] 2012-02-09 12:46 Jack

    "如果是請不要用Iterator進(jìn)行remove(),而應(yīng)該使用List的remove方法進(jìn)行。 "
    說反了吧?  回復(fù)  更多評論   


    只有注冊用戶登錄后才能發(fā)表評論。


    網(wǎng)站導(dǎo)航:
     

    導(dǎo)航

    <2012年2月>
    2930311234
    567891011
    12131415161718
    19202122232425
    26272829123
    45678910

    統(tǒng)計(jì)

    常用鏈接

    留言簿(1)

    隨筆檔案

    搜索

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 无码人妻AV免费一区二区三区| 免费看黄福利app导航看一下黄色录像| 一区二区三区免费视频播放器| 日韩视频免费一区二区三区| 亚洲精华国产精华精华液好用| 成年美女黄网站色大免费视频| 男人天堂2018亚洲男人天堂 | 国产JIZZ中国JIZZ免费看| 国产精品免费看香蕉| 久久精品国产亚洲AV未满十八| 午夜免费不卡毛片完整版| 亚洲精品国产高清在线观看| 国产精品美女自在线观看免费| 粉色视频在线观看www免费| 又大又黄又粗又爽的免费视频| 一级一级一片免费高清| 最新精品亚洲成a人在线观看| 免费在线观影网站| 亚洲av色福利天堂| 日本视频一区在线观看免费| 亚洲中文字幕久久精品无码VA| 国产伦一区二区三区免费| h视频在线观看免费| 亚洲av无码一区二区三区网站 | 在线观看免费a∨网站| 精品无码专区亚洲| 久久伊人亚洲AV无码网站| 日韩av无码久久精品免费| 97久久国产亚洲精品超碰热| 四虎永久在线精品视频免费观看| 一级a性色生活片久久无少妇一级婬片免费放 | 国产精品亚洲综合| 国产亚洲精品自在线观看| 久久国产免费一区二区三区| 狠狠色香婷婷久久亚洲精品| 亚洲成a人片在线观看老师| 国产成人精品无码免费看| 亚洲精品一二三区| 中文字幕亚洲综合久久菠萝蜜| 91短视频在线免费观看| 狠狠入ady亚洲精品|