1樓：Spongecaptain
這是乙個有意思的問題，可以從必要性得到解釋。
試圖將一大堆 key-value 對放入到乙個HashMap 中，我們目標就是乙個 HashMap，自然需要自動擴容機制。
補充乙個外鏈，和我的說法有著類似的道理。
2樓：youngc
為了減少 hashmap 自動擴容次數，鼓勵在建立 hashmap 物件時估算實際儲存的元素數量指定初始容量。假如說你建立時告訴我你可能需要存256個鍵值對，初始化陣列長度為256， 存2刪1剩下1個鍵值對，那麼勢必會觸發動態縮容，那建立物件時估算容量就毫無意義了。
3樓：josan
之前，我也有同樣的想法。但是，後來我被放棄這個想法。
remove的時候，將Node實體的指標已經置為null, GC會釋放實體。所以鍊錶+紅黑樹的結點談不上縮容。
細想，你縮容縮的是什麼？
縮的是那個已經分配的陣列。
你比如clear()，將每個tab slot置為null，假設tab.len=2^10次方，假設每個節點的空指標佔4個位元組（32 bit jvm） 實際節約空間是4B * 2^10 = 4KB. 與每次縮容，又要重rehash相比，縮容操作的價效比不是很高。
4樓：JasonMing
不要說hashmap不支援，就算是執行緒池和連線池的大多數都不會用上縮容的功能。
因為有增有減很容易出現反覆橫跳的場景，這樣對於業務處理沒有好處。
大多做法是預估好容量，直接分配個固定值，超過就拒絕服務。很多時候是沒有必要動態擴容和縮容的。
java中hashmap為什麼key的值不一樣呼叫hashcode的hash值為什麼相同？
Intopass 因為KEY的 容量 有可能超過雜湊值 int型別 的容量，你從乙個大範圍對映到小範圍必然不可能保證一對一，只能是多對一。 hashcode的目的是實現對若干物件分批次，key的值不一樣 意味著不同的key之間呼叫equals 方法返回false。hashcode分批次的目的是，把大...
java 中的hashmap在多執行緒中是不安全的，開發中還經常用，是spring框架幫忙解決了嗎 ？
程式猿弟弟 不安全 第一時間就會想到多執行緒吧。只有在多執行緒併發的情況下才會出現不安全的。我們在開發的過程中，乙個請求就是乙個執行緒。在乙個執行緒裡面做hashmap儲存是沒有問題的。我覺得樓主提的問題應該是spring在使用單利bean物件是如何保證request執行緒的隔離。這樣問才有意義。 ...
為什麼 HashMap 中的load factor在各個語言的實現中都在 0 6 0 8 之間？
乾貨滿滿張雜湊 首先，這個基於乙個假設，那麼就是當乙個事件發生的概率大於 0.5，那麼這件事就是很可能發生的。然後，假設當前有 s 個桶，那麼每次放入乙個元素進入某乙個桶的概率就是 放入了第 n 個元素，那麼，某乙個桶元素個數為e的概率，根據二項式分布就是 將e 0代入，得出 讓這個概率大於 0.5...