我想知道有關參數的用於構造ConcurrentHashMap：ConcurrentHashMap構造函數參數？
initialCapacity是16由默認值（理解）。loadFactor默認爲0.75。concurrencyLevel默認爲16。我的問題是：
loadFactor向上或向下？concurrencyLevel向上或向下？此外：
謝謝！
簡短回答：將「初始容量」設置爲您預期放置在地圖上的映射數量，並將其他參數保留爲默認值。
龍答案：
負載因素是 數在地圖和 預期元件的數量「桶」的之間的比率;
0.75通常是一個合理的妥協 - 正如我記得，這意味着，與一個 良好的散列函數，平均我們 預計約1。6重定向，以在地圖（或圍繞該圖）中找到 元素;
改變負載 因素變化 更多重定向之間的妥協找到一個元素，但 少浪費space--放0.75是 真的通常一個很好的價值;
原則，設置ConcurrencyLevel到 併發線程的數量，您 希望有修改地圖， 雖然高估，這並不 似乎有其他 不是浪費記憶不好的影響（我寫了一個小 上的情況下，ConcurrentHashMap performance 前一陣子你 感興趣）
通俗地說，你的哈希函數應該基本上旨在儘可能多地在這些位中具有「隨機性」。或者更嚴格地說，給定元素的哈希碼應該給每個比特大概50％的機會被設置。用一個例子來說明這一點實際上更容易：再次，您可能對我寫的關於how the String hash function works和相關的hash function guidelines的一些內容感興趣。任何這些東西都歡迎反饋意見。
有一件事我也提到在某些時候是，你不必過於偏執的做法：如果你的哈希函數產生的位的一些「合理的」隨機性的量，那麼它通常會好的。在最壞的情況下，將代表性的數據片段粘貼到一個字符串中並採用該字符串的哈希代碼實際上並不會如此糟糕。
loadFactor：控制實現何時決定調整散列表的大小。太高的價值會浪費空間;太低的值將導致昂貴的調整大小操作。
concurrencyLevel：指示實現嘗試針對給定數量的寫入線程進行優化。根據API文檔，關閉10倍不會對性能產生太大影響。
更新 操作中允許的併發由可選 concurrencyLevel構造參數 （默認16），其被用作用於內部施膠的提示 引導。該表爲 內部分區以嘗試 允許指定數量的 併發更新而沒有爭用。 因爲在散列表中放置的數據實質上是隨機的，所以實際的併發性會有所不同。理想情況下，您應該選擇一個值來容納 儘可能多的線程，並且會同時修改該表。使用 明顯高於你的值可能會浪費空間和時間，而明顯更低的值可能導致 線程爭用。但高估 並低估 的幅度通常不會有太大的 明顯的影響。
一個好的散列碼實現將在任何時間間隔內均勻散佈散列值。如果事先知道該組密鑰，則可以定義一個「完美」散列函數，爲每個密鑰創建一個唯一的散列值。
loadFactor設定爲0.75默認情況下， 什麼標準應該被用來調整 這種向上或向下？
您需要一些背景知道哈希映射如何工作，然後才能理解它的工作原理。地圖本質上是一系列的桶。根據散列碼的不同，映射中的每個值都會被放入一個存儲桶中。該loadFactor意味着，如果桶超過75％滿，地圖應該調整
concurrencyLevel被 默認設置爲16，我們如何建立 數量的併發更新 線程？應該用什麼標準 來調整這個向上或向下？
這是問多少線程你希望併發修改地圖（同時）
哈希代碼，請參見約書亞布洛赫的Effective Java
負荷率主要與哈希的質量功能。即使散列函數不是很好，負載因子越接近零，碰撞的可能性越小。權衡是內存佔用更大。換句話說，HashMap沒有爲每個獨立的散列碼在單獨的桶中分佈條目，而是將它們按鄰域分組，因此它擁有的桶越多，分佈越分散，出現衝突的可能性就越小。
因此，根據您的需求和您在Map中存儲的對象，您可以根據負載因子調整查找時間或減少內存。
ConcurrencyLevel實際上取決於您的應用程序。如果你只有兩個或三個線程在應用程序中運行，那麼你就去。如果您是一個具有任意數量線程的應用程序服務器，那麼您需要了解您的負載容量以及您希望優化的點數。
質量良好的散列碼實現提供儘可能廣泛的對象潛在值的分佈，儘可能減少衝突次數，同時遵守合同。換句話說，它允許HashMap（或根據具體情況設置）將對象分佈到單獨的存儲桶中，從而加快查找速度。
謝謝戴夫，好多了我會把我的隊列從你身上 – 2009-10-15 17:58:47