java中如何選擇Collection Class--java線程（第3版）

        使用哪個collection是最好的？很明顯，沒有單一的答案能夠適合全部的狀態。不管如何，如下仍是有一些通用的建議。遵循這些建議，咱們就能夠縮小collection的選擇範圍。

• 使用collection class 的時候，經過接口來運用。

  如同全部的java程序設計，接口能夠隔離開實現的細節。經過使用接口，程序設計師能夠輕易地只以修改初始程序代碼就將程序重構成使用不一樣collection的實現。

• 使用沒有被同步化過的collection會有小小的性能提高。

  這可能會讓許多開發者吃驚---要了解lock取得的性能問題，詳見第14章。簡單地說，取得lock的性能問題只會發生在競爭的時候。然而，沒有被同步化過的collection應該不會競爭lock。若是確實有競爭，那麼race condition的問題的可能性會比性能要高。

• 對許多有競爭的算法，考慮改用併發的collection。

  在J2SE5.0中加入的set、hashmap與list collection 有高度的最佳化。若是程序的算法適用其中一種interface，就要考慮J2SE5.0的collection來替換被同步化過的JDK1.2班的collection。併發的collection對多線程的訪問有更好的最優化。

• 對生產者/消費者模式的程序，考慮使用queue來做爲collection。

  queue最適合生產者/消費者模式是有許多緣由的。首先，queue提供對請求的排序，能夠防止數據飢餓。第二，queue被高度地最佳化過，有最少的同步、atomic的訪問以及在許多狀況下甚至能夠安全的並行訪問。使用這些collection，大量的線程也能夠並行地運做 而只有在對queue的訪問上有小小的瓶頸。

• 若是可能的話，儘可能減小明確同步的使用。iterator與其餘須要遍歷過整個collection的支持性method可能會比collection提供更多的同步。當有許多線程涉入的時候這可能會是個問題。

• 限制對copy-on-write這類collection使用iterator。

  首先，只在collection的元素數量不多的時候使用這些class，這是因爲copy-on-write操做所須要的時間與空間。其次，你的程序不須要collection有最新的信息，iterator只帶有建立時間點上的collection的信息而已。

• 考慮使用多個collection。

  雖然某些collection有最小的同步，但在有多個線程涉入的時候這些同步過程仍是有問題。考慮使用

多個分段的collecton的算法來代替多個線程使用同一個collection的通常實現方式。



• set與map間有少量的差別。

  理論上，set與map有好幾個方面的差別，但以實現的觀點來講，只有一點點的不一樣。許多set collection就是用map collection實現出來的。這意味着選擇實際上並非選擇：存儲在set中的元素幾乎就是在map中存儲的key。