集合總是需要迭代的，我們確實需要探察集合中的每一個元素，所以集合接口都無一例外的繼承了Iterable<T> 接口 ，而該接口的唯一方法 ：
可以返回一個所有集合接口都繼承了的Iteraor接口，如此集合框架的所有子類都可以迭代顯示其元素！
例如下：集合的根接口Collection繼承了Iterator接口：
- public interface Collection<E>
- extends Iterable<E>
- Collection 層次結構 中的根接口。Collection 表示一組對象，這些對象也稱為 collection包 (bag) 或多集合 (multiset)（可能包含重復元素的無序 collection）應該直接實現此接口。
- 所有通用的 Collection 實現類（通常通過它的一個子接口間接實現 Collection）應該提供兩個“標准”構造方法：一個是 void（無參數）構造方法，用於創建空 collection；另一個是帶有 Collection 類型單參數的構造方法，用於創建一個具有與其參數相同元素新的 collection。實際上，後者允許用戶復制任何 collection，以生成所需實現類型的一個等效 collection。盡管無法強制執行此約定（因為接口不能包含構造方法），但是 Java 平台庫中所有通用的 Collection 實現都遵從它。
- 此接口中包含的“破壞性”方法，是指可修改其所操作的 collection 的那些方法，如果此 collection 不支持該操作，則指定這些方法拋出 UnsupportedOperationException。如果是這樣，那麼在調用對該 collection 無效時，這些方法可能，但並不一定拋出 UnsupportedOperationException。例如，如果要添加的 collection 為空且不可修改，則對該 collection 調用
addAll(Collection) 方法時，可能但並不一定拋出異常。
- 一些 collection 實現對它們可能包含的元素有所限制。例如，某些實現禁止 null 元素，而某些實現則對元素的類型有限制。試圖添加不合格的元素將拋出一個未經檢查的異常，通常是 NullPointerException 或 ClassCastException。試圖查詢是否存在不合格的元素可能拋出一個異常，或者只是簡單地返回 false；某些實現將表現出前一種行為，而某些實現則表現後一種。較為常見的是，試圖對某個不合格的元素執行操作且該操作的完成不會導致將不合格的元素插入 collection 中，將可能拋出一個異常，也可能操作成功，這取決於實現本身。這樣的異常在此接口的規范中標記為“可選”。
此接口是 Java Collections Framework 的成員。
Collections Framework 接口中的很多方法是根據 equals 方法定義的。例如，contains(Object o) 方法的規范聲明：“當且僅當此 collection 包含至少一個滿足 (o==null ? e==null :o.equals(e)) 的元素 e 時，才返回 true。”不 應將此規范理解為它暗指調用具有非空參數 o 的 Collection.contains 方法會導致為任意的 e 元素調用 o.equals(e) 方法。可隨意對各種實現執行優化，只要避免調用 equals 即可，例如，通過首先比較兩個元素的哈希碼。（Object.hashCode() 規范保證哈希碼不相等的兩個對象不會相等）。較為常見的是，各種 Collections Framework 接口的實現可隨意利用基礎 Object 方法的指定行為，而不管實現程序認為它是否合適。
集合Collection的父接口所返回的Iterator接口的意義：
public interface Iterator<E>
對集合進行迭代的迭代器。迭代器代替了 Java Collections Framework 中的 Enumeration。迭代器與枚舉有兩點不同：
- 迭代器允許調用方利用定義良好的語義在迭代期間從迭代器所指向的集合移除元素。
- 方法名稱得到了改進。
