Java原始碼分析:深入探討Iterator模式
Java原始碼分析:深入探討Iterator模式[@more@] java.util包中包含了一系列重要的集合類。本文將從分析原始碼入手,深入研究一個集合類的內部結構,以及遍歷集合的迭代模式的原始碼實現內幕。
下面我們先簡單討論一個根介面Collection,然後分析一個抽象類AbstractList和它的對應Iterator介面,並仔細研究迭代子模式的實現原理。
本文討論的原始碼版本是JDK 1.4.2,因為JDK 1.5在java.util中使用了很多泛型程式碼,為了簡化問題,所以我們還是討論1.4版本的程式碼。
集合類的根介面Collection
Collection介面是所有集合類的根型別。它的一個主要的介面方法是:
boolean add(Object c)
add()方法將新增一個新元素。注意這個方法會返回一個boolean,但是返回值不是表示新增成功與否。仔細閱讀doc可以看到,Collection規定:如果一個集合拒絕新增這個元素,無論任何原因,都必須丟擲異常。這個返回值表示的意義是add()方法執行後,集合的內容是否改變了(就是元素有無數量,位置等變化),這是由具體類實現的。即:如果方法出錯,總會丟擲異常;返回值僅僅表示該方法執行後這個Collection的內容有無變化。
類似的還有:
boolean addAll(Collection c);
boolean remove(Object o);
boolean removeAll(Collection c);
boolean remainAll(Collection c);
Object[] toArray()方法很簡單,把集合轉換成陣列返回。Object[] toArray(Object[] a)方法就有點複雜了,首先,返回的Object[]仍然是把集合的所有元素變成的陣列,但是型別和引數a的型別是相同的,比如執行:
String[] o = (String[])c.toArray(new String[0]);
得到的o實際型別是String[]。
其次,如果引數a的大小裝不下集合的所有元素,返回的將是一個新的陣列。如果引數a的大小能裝下集合的所有元素,則返回的還是a,但a的內容用集合的元素來填充。尤其要注意的是,如果a的大小比集合元素的個數還多,a後面的部分全部被置為null。
最後一個最重要的方法是iterator(),返回一個Iterator(迭代子),用於遍歷集合的所有元素。
用Iterator模式實現遍歷集合
Iterator模式是用於遍歷集合類的標準訪問方法。它可以把訪問邏輯從不同型別的集合類中抽象出來,從而避免向客戶端暴露集合的內部結構。
例如,如果沒有使用Iterator,遍歷一個陣列的方法是使用索引:
for(int i=0; i
而訪問一個連結串列(LinkedList)又必須使用while迴圈:
while((e=e.next())!=null) { ... e.data() ... }
以上兩種方法客戶端都必須事先知道集合的內部結構,訪問程式碼和集合本身是緊耦合,無法將訪問邏輯從集合類和客戶端程式碼中分離出來,每一種集合對應一種遍歷方法,客戶端程式碼無法複用。
更恐怖的是,如果以後需要把ArrayList更換為LinkedList,則原來的客戶端程式碼必須全部重寫。
為解決以上問題,Iterator模式總是用同一種邏輯來遍歷集合:
for(Iterator it = c.iterater(); it.hasNext(); ) { ... }
奧秘在於客戶端自身不維護遍歷集合的"指標",所有的內部狀態(如當前元素位置,是否有下一個元素)都由Iterator來維護,而這個Iterator由集合類透過工廠方法生成,因此,它知道如何遍歷整個集合。
客戶端從不直接和集合類打交道,它總是控制Iterator,向它傳送"向前","向後","取當前元素"的命令,就可以間接遍歷整個集合。
首先看看java.util.Iterator介面的定義:
public interface Iterator {
boolean hasNext();
Object next();
void remove();
}
依賴前兩個方法就能完成遍歷,典型的程式碼如下:
for(Iterator it = c.iterator(); it.hasNext(); ) {
Object o = it.next();
// 對o的操作...
}
在JDK1.5中,還對上面的程式碼在語法上作了簡化:
// Type是具體的型別,如String。
for(Type t : c) {
// 對t的操作...
}
每一種集合類返回的Iterator具體型別可能不同,Array可能返回ArrayIterator,Set可能返回SetIterator,Tree可能返回TreeIterator,但是它們都實現了Iterator介面,因此,客戶端不關心到底是哪種Iterator,它只需要獲得這個Iterator介面即可,這就是物件導向的威力。
Iterator原始碼剖析
讓我們來看看AbstracyList如何建立Iterator。首先AbstractList定義了一個內部類(inner class):
private class Itr implements Iterator {
...
}
而iterator()方法的定義是:
public Iterator iterator() {
return new Itr();
}
因此客戶端不知道它透過Iterator it = a.iterator();所獲得的Iterator的真正型別。
現在我們關心的是這個申明為private的Itr類是如何實現遍歷AbstractList的:
private class Itr implements Iterator {
int cursor = 0;
int lastRet = -1;
int expectedModCount = modCount;
}
Itr類依靠3個int變數(還有一個隱含的AbstractList的引用)來實現遍歷,cursor是下一次next()呼叫時元素的位置,第一次呼叫next()將返回索引為0的元素。lastRet記錄上一次遊標所在位置,因此它總是比cursor少1。
變數cursor和集合的元素個數決定hasNext():
public boolean hasNext() {
return cursor != size();
}
方法next()返回的是索引為cursor的元素,然後修改cursor和lastRet的值:
public Object next() {
checkForComodification();
try {
Object next = get(cursor);
lastRet = cursor++;
return next;
} catch(IndexOutOfBoundsException e) {
checkForComodification();
throw new NoSuchElementException();
}
}
expectedModCount表示期待的modCount值,用來判斷在遍歷過程中集合是否被修改過。AbstractList包含一個modCount變數,它的初始值是0,當集合每被修改一次時(呼叫add,remove等方法),modCount加1。因此,modCount如果不變,表示集合內容未被修改。
Itr初始化時用expectedModCount記錄集合的modCount變數,此後在必要的地方它會檢測modCount的值:
final void checkForComodification() {
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
}
如果modCount與一開始記錄在expectedModeCount中的值不等,說明集合內容被修改過,此時會丟擲ConcurrentModificationException。
這個ConcurrentModificationException是RuntimeException,不要在客戶端捕獲它。如果發生此異常,說明程式程式碼的編寫有問題,應該仔細檢查程式碼而不是在catch中忽略它。
但是呼叫Iterator自身的remove()方法刪除當前元素是完全沒有問題的,因為在這個方法中會自動同步expectedModCount和modCount的值:
public void remove() {
...
AbstractList.this.remove(lastRet);
...
// 在呼叫了集合的remove()方法之後重新設定了expectedModCount:
expectedModCount = modCount;
...
}
要確保遍歷過程順利完成,必須保證遍歷過程中不更改集合的內容(Iterator的remove()方法除外),因此,確保遍歷可靠的原則是隻在一個執行緒中使用這個集合,或者在多執行緒中對遍歷程式碼進行同步。
最後給個完整的示例:
Collection c = new ArrayList();
c.add("abc");
c.add("xyz");
for(Iterator it = c.iterator(); it.hasNext(); ) {
String s = (String)it.next();
System.out.println(s);
}
如果你把第一行程式碼的ArrayList換成LinkedList或Vector,剩下的程式碼不用改動一行就能編譯,而且功能不變,這就是針對抽象程式設計的原則:對具體類的依賴性最小。
下面我們先簡單討論一個根介面Collection,然後分析一個抽象類AbstractList和它的對應Iterator介面,並仔細研究迭代子模式的實現原理。
本文討論的原始碼版本是JDK 1.4.2,因為JDK 1.5在java.util中使用了很多泛型程式碼,為了簡化問題,所以我們還是討論1.4版本的程式碼。
集合類的根介面Collection
Collection介面是所有集合類的根型別。它的一個主要的介面方法是:
boolean add(Object c)
add()方法將新增一個新元素。注意這個方法會返回一個boolean,但是返回值不是表示新增成功與否。仔細閱讀doc可以看到,Collection規定:如果一個集合拒絕新增這個元素,無論任何原因,都必須丟擲異常。這個返回值表示的意義是add()方法執行後,集合的內容是否改變了(就是元素有無數量,位置等變化),這是由具體類實現的。即:如果方法出錯,總會丟擲異常;返回值僅僅表示該方法執行後這個Collection的內容有無變化。
類似的還有:
boolean addAll(Collection c);
boolean remove(Object o);
boolean removeAll(Collection c);
boolean remainAll(Collection c);
Object[] toArray()方法很簡單,把集合轉換成陣列返回。Object[] toArray(Object[] a)方法就有點複雜了,首先,返回的Object[]仍然是把集合的所有元素變成的陣列,但是型別和引數a的型別是相同的,比如執行:
String[] o = (String[])c.toArray(new String[0]);
得到的o實際型別是String[]。
其次,如果引數a的大小裝不下集合的所有元素,返回的將是一個新的陣列。如果引數a的大小能裝下集合的所有元素,則返回的還是a,但a的內容用集合的元素來填充。尤其要注意的是,如果a的大小比集合元素的個數還多,a後面的部分全部被置為null。
最後一個最重要的方法是iterator(),返回一個Iterator(迭代子),用於遍歷集合的所有元素。
用Iterator模式實現遍歷集合
Iterator模式是用於遍歷集合類的標準訪問方法。它可以把訪問邏輯從不同型別的集合類中抽象出來,從而避免向客戶端暴露集合的內部結構。
例如,如果沒有使用Iterator,遍歷一個陣列的方法是使用索引:
for(int i=0; i
而訪問一個連結串列(LinkedList)又必須使用while迴圈:
while((e=e.next())!=null) { ... e.data() ... }
以上兩種方法客戶端都必須事先知道集合的內部結構,訪問程式碼和集合本身是緊耦合,無法將訪問邏輯從集合類和客戶端程式碼中分離出來,每一種集合對應一種遍歷方法,客戶端程式碼無法複用。
更恐怖的是,如果以後需要把ArrayList更換為LinkedList,則原來的客戶端程式碼必須全部重寫。
為解決以上問題,Iterator模式總是用同一種邏輯來遍歷集合:
for(Iterator it = c.iterater(); it.hasNext(); ) { ... }
奧秘在於客戶端自身不維護遍歷集合的"指標",所有的內部狀態(如當前元素位置,是否有下一個元素)都由Iterator來維護,而這個Iterator由集合類透過工廠方法生成,因此,它知道如何遍歷整個集合。
客戶端從不直接和集合類打交道,它總是控制Iterator,向它傳送"向前","向後","取當前元素"的命令,就可以間接遍歷整個集合。
首先看看java.util.Iterator介面的定義:
public interface Iterator {
boolean hasNext();
Object next();
void remove();
}
依賴前兩個方法就能完成遍歷,典型的程式碼如下:
for(Iterator it = c.iterator(); it.hasNext(); ) {
Object o = it.next();
// 對o的操作...
}
在JDK1.5中,還對上面的程式碼在語法上作了簡化:
// Type是具體的型別,如String。
for(Type t : c) {
// 對t的操作...
}
每一種集合類返回的Iterator具體型別可能不同,Array可能返回ArrayIterator,Set可能返回SetIterator,Tree可能返回TreeIterator,但是它們都實現了Iterator介面,因此,客戶端不關心到底是哪種Iterator,它只需要獲得這個Iterator介面即可,這就是物件導向的威力。
Iterator原始碼剖析
讓我們來看看AbstracyList如何建立Iterator。首先AbstractList定義了一個內部類(inner class):
private class Itr implements Iterator {
...
}
而iterator()方法的定義是:
public Iterator iterator() {
return new Itr();
}
因此客戶端不知道它透過Iterator it = a.iterator();所獲得的Iterator的真正型別。
現在我們關心的是這個申明為private的Itr類是如何實現遍歷AbstractList的:
private class Itr implements Iterator {
int cursor = 0;
int lastRet = -1;
int expectedModCount = modCount;
}
Itr類依靠3個int變數(還有一個隱含的AbstractList的引用)來實現遍歷,cursor是下一次next()呼叫時元素的位置,第一次呼叫next()將返回索引為0的元素。lastRet記錄上一次遊標所在位置,因此它總是比cursor少1。
變數cursor和集合的元素個數決定hasNext():
public boolean hasNext() {
return cursor != size();
}
方法next()返回的是索引為cursor的元素,然後修改cursor和lastRet的值:
public Object next() {
checkForComodification();
try {
Object next = get(cursor);
lastRet = cursor++;
return next;
} catch(IndexOutOfBoundsException e) {
checkForComodification();
throw new NoSuchElementException();
}
}
expectedModCount表示期待的modCount值,用來判斷在遍歷過程中集合是否被修改過。AbstractList包含一個modCount變數,它的初始值是0,當集合每被修改一次時(呼叫add,remove等方法),modCount加1。因此,modCount如果不變,表示集合內容未被修改。
Itr初始化時用expectedModCount記錄集合的modCount變數,此後在必要的地方它會檢測modCount的值:
final void checkForComodification() {
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
}
如果modCount與一開始記錄在expectedModeCount中的值不等,說明集合內容被修改過,此時會丟擲ConcurrentModificationException。
這個ConcurrentModificationException是RuntimeException,不要在客戶端捕獲它。如果發生此異常,說明程式程式碼的編寫有問題,應該仔細檢查程式碼而不是在catch中忽略它。
但是呼叫Iterator自身的remove()方法刪除當前元素是完全沒有問題的,因為在這個方法中會自動同步expectedModCount和modCount的值:
public void remove() {
...
AbstractList.this.remove(lastRet);
...
// 在呼叫了集合的remove()方法之後重新設定了expectedModCount:
expectedModCount = modCount;
...
}
要確保遍歷過程順利完成,必須保證遍歷過程中不更改集合的內容(Iterator的remove()方法除外),因此,確保遍歷可靠的原則是隻在一個執行緒中使用這個集合,或者在多執行緒中對遍歷程式碼進行同步。
最後給個完整的示例:
Collection c = new ArrayList();
c.add("abc");
c.add("xyz");
for(Iterator it = c.iterator(); it.hasNext(); ) {
String s = (String)it.next();
System.out.println(s);
}
如果你把第一行程式碼的ArrayList換成LinkedList或Vector,剩下的程式碼不用改動一行就能編譯,而且功能不變,這就是針對抽象程式設計的原則:對具體類的依賴性最小。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10901326/viewspace-965669/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 深入探討單例模式單例模式
- 深入探討ROP 載荷分析
- Java HashMap工作原理深入探討JavaHashMap
- 深入探討、理解Java的CLASSPATHJava
- 深入探討 Java 類載入器Java
- Java執行緒的深入探討Java執行緒
- 深入探討 UndefinedUndefined
- IsPostBack深入探討
- Java執行緒的深入探討 (轉)Java執行緒
- Oracle Stream 深入探討Oracle
- BeeHive 1.6.0 原始碼閱讀探討Hive原始碼
- 深入探討 Java Spring 框架事務註釋JavaSpring框架
- Java併發:深入淺出AQS之獨佔鎖模式原始碼分析JavaAQS模式原始碼
- 窺探React – 原始碼分析React原始碼
- 窺探React - 原始碼分析React原始碼
- 深入探討JavaScript函式物件JavaScript函式物件
- Java 基礎(二)集合原始碼解析 IteratorJava原始碼
- 責任鏈模式探討模式
- 深入探討Java中的異常與錯誤處理Java
- 深入探討前端元件化開發前端元件化
- 探討代理模式與Java反射機制的應用模式Java反射
- Android設計模式探討--Builder模式Android設計模式UI
- Android設計模式探討 Builder模式Android設計模式UI
- oracle 雙機部署模式探討Oracle模式
- 單體模式探討(原創)模式
- JdonFramework程式碼探討Framework
- ConcurrentModificationException,iterator迭代問題[原始碼分析]Exception原始碼
- Java非同步程式設計——深入原始碼分析FutureTaskJava非同步程式設計原始碼
- 深入探討 Room 2.4.0 的最新進展OOM
- Sql Server深入的探討鎖機制SQLServer
- IsPostBack深入探討(轉轉轉轉轉)
- CSS中Position、Float屬性深入探討CSS
- 探討阻塞佇列和執行緒池原始碼佇列執行緒原始碼
- 窺探React-原始碼分析(二)React原始碼
- Java容器類原始碼分析之Iterator與ListIterator迭代器(基於JDK8)Java原始碼JDK
- Android設計模式探討--單例模式Android設計模式單例
- Android設計模式探討 單例模式Android設計模式單例
- Web 框架的架構模式探討Web框架架構模式