Fail-Fast機制：
我們知道java.util.HashMap不是線程安全的，因此如果在使用迭代器的過程中有其他線程修改了map，那么將拋出ConcurrentModificationException，這就是所謂fail-fast策略。
這一策略在源碼中的實現是通過modCount域，modCount顧名思義就是修改次數，對HashMap內容的修改都將增加這個值，那么在迭代器初始化過程中會將這個值賦給迭代器的expectedModCount。
- HashIterator() {
- expectedModCount = modCount;
- if (size > 0) { // advance to first entry
- Entry[] t = table;
- while (index < t.length && (next = t[index++]) == null)
- ;
- }
- }
在迭代過程中，判斷modCount跟expectedModCount是否相等，如果不相等就表示已經有其他線程修改了Map：
注意到modCount聲明為volatile，保證線程之間修改的可見性。
- final Entry<K,V> nextEntry() {
- if (modCount != expectedModCount)
- throw new ConcurrentModificationException();
在HashMap的API中指出：
由所有HashMap類的“collection 視圖方法”所返回的迭代器都是快速失敗的：在迭代器創建之后，如果從結構上對映射進行修改，除非通過迭代器本身的 remove 方法，其他任何時間任何方式的修改，迭代器都將拋出ConcurrentModificationException。因此，面對並發的修改，迭代器很快就會完全失敗，而不冒在將來不確定的時間發生任意不確定行為的風險。
注意，迭代器的快速失敗行為不能得到保證，一般來說，存在非同步的並發修改時，不可能作出任何堅決的保證。快速失敗迭代器盡最大努力拋出 ConcurrentModificationException。因此，編寫依賴於此異常的程序的做法是錯誤的，正確做法是：迭代器的快速失敗行為應該僅用於檢測程序錯誤。
JDK1.0引入了第一個關聯的集合類HashTable，它是線程安全的。HashTable的所有方法都是同步的。
JDK2.0引入了HashMap，它提供了一個不同步的基類和一個同步的包裝器synchronizedMap。synchronizedMap被稱為有條件的線程安全類。
JDK5.0util.concurrent包中引入對Map線程安全的實現ConcurrentHashMap，比起synchronizedMap，它提供了更高的靈活性。同時進行的讀和寫操作都可以並發地執行。
所以在開始的測試中，如果我們采用ConcurrentHashMap，它的表現就很穩定，所以以后如果使用Map實現本地緩存，為了提高並發時的穩定性，還是建議使用ConcurrentHashMap。
====================================================================
另外，還有一個我們經常使用的ArrayList也是非線程安全的，網上看到的有一個解釋是這樣：
一個 ArrayList 類，在添加一個元素的時候，它可能會有兩步來完成：1. 在 Items[Size] 的位置存放此元素；2. 增大 Size 的值。
在單線程運行的情況下，如果 Size = 0，添加一個元素后，此元素在位置 0，而且 Size=1；
而如果是在多線程情況下，比如有兩個線程，線程 A 先將元素存放在位置 0。但是此時 CPU 調度線程A暫停，線程 B 得到運行的機會。線程B也將元素放在位置0，（因為size還未增長），完了之后，兩個線程都是size++，結果size變成2，而只有items[0]有元素。
util.concurrent包也提供了一個線程安全的ArrayList替代者CopyOnWriteArrayList