此問題涉及Java集合 - 特別是Hashtable和Vector - 但也可能適用於其他地方。對接口和同步集合進行編程
我讀過很多地方編程接口有多好,我同意100%。例如,在不考慮底層實現的情況下編程到List接口的能力對解耦和測試目的無疑是有幫助的。通過集合,我可以看到ArrayList和LinkedList如何在不同的情況下適用,考慮到內部存儲結構,隨機訪問時間等方面的差異。然而,這兩個實現可以在相同的接口下使用......是很棒的。
我似乎無法放置的是某些同步實現(特別是Hashtable和Vector)如何適合這些接口。對我來說,他們似乎不適合這個模型。大多數底層數據結構的實現似乎在數據存儲方式(LinkedList,Array,排序樹等)方面有所不同,而同步則處理可以訪問數據的條件(鎖定條件)。讓我們看一個方法返回一個Map集合的例子:
public Map<String, String> getSomeData();
讓我們假設應用程序根本不關心併發性。在這種情況下,我們在任何通過接口返回的實現上進行操作......每個人都很高興。世界是穩定的。
但是,如果應用程序現在需要關注併發前端呢?我們現在無法在不考慮底層實現的情況下運行 - 散列表將會很好,但其他實現必須滿足。我們來考慮3種情況:
1)使用同步塊等在使用集合添加/刪除時強制進行同步。但是,如果同步實現(Hashtable)被返回,那麼這不會是過度的嗎?
2)更改方法簽名以返回Hashtable。然而,這將我們緊緊綁定到Hashtable實現,因此,編程接口的優勢被拋出窗口。
3)使用併發包並更改方法簽名以返回ConcurrentMap接口的實現。對我而言,這似乎是前進的方向。
從本質上講,似乎某些同步實現在集合框架內有點不適合,因爲在編程到接口時,同步問題幾乎迫使人們想到底層實現。
我完全忽略了這一點嗎?
謝謝。
我認爲關鍵是在這裏或那裏添加一些「同步」關鍵字並不會使您的程序線程安全。即使使用java.util.concurrent集合,也希望將它們保留爲私有實現細節。 – 2009-10-19 21:50:50