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。

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