1樓：Intopass
因為KEY的「容量」有可能超過雜湊值「int型別」的容量，你從乙個大範圍對映到小範圍必然不可能保證一對一，只能是多對一。
2樓：
hashcode的目的是實現對若干物件分批次，「key的值不一樣」意味著不同的key之間呼叫equals()方法返回false。
hashcode分批次的目的是，把大量的物件對映到固定空間的桶中。物件個數是足夠多的，而桶的數量是固定的，根據抽屜原理，必有一些桶，中間包含超過乙個物件。
那麼，在同乙個桶中的這些物件，以什麼規則判斷他們就該放在乙個桶呢？
根據：hashcode相同（或者說hashcode % 桶長度的餘數相同）。
這樣就要求：
1，同乙個物件，不改變內部屬性的時候，每次呼叫hashcode()必須返回相同數值。否則，要是每次呼叫返回不同的hashcode，那麼每次在HashMap中尋找這個物件的時候，會找到其他桶去，從而判定錯誤。
2，hashcode的返回值，要盡可能的雜湊開來，意思是，儘量減少兩個物件hashcode相同或者扎堆的情況，避免HashMap中有些桶塞得很多，有些塞的很少，從而降低了HashMap的效能。
java 中的hashmap在多執行緒中是不安全的，開發中還經常用，是spring框架幫忙解決了嗎 ？
程式猿弟弟 不安全 第一時間就會想到多執行緒吧。只有在多執行緒併發的情況下才會出現不安全的。我們在開發的過程中，乙個請求就是乙個執行緒。在乙個執行緒裡面做hashmap儲存是沒有問題的。我覺得樓主提的問題應該是spring在使用單利bean物件是如何保證request執行緒的隔離。這樣問才有意義。 ...
為什麼java的hashmap不支援動態縮小容量？
Spongecaptain 這是乙個有意思的問題，可以從必要性得到解釋。試圖將一大堆 key value 對放入到乙個HashMap 中，我們目標就是乙個 HashMap，自然需要自動擴容機制。補充乙個外鏈，和我的說法有著類似的道理。 youngc 為了減少 hashmap 自動擴容次數，鼓勵在建立...
為什麼 HashMap 中的load factor在各個語言的實現中都在 0 6 0 8 之間？
乾貨滿滿張雜湊 首先，這個基於乙個假設，那麼就是當乙個事件發生的概率大於 0.5，那麼這件事就是很可能發生的。然後，假設當前有 s 個桶，那麼每次放入乙個元素進入某乙個桶的概率就是 放入了第 n 個元素，那麼，某乙個桶元素個數為e的概率，根據二項式分布就是 將e 0代入，得出 讓這個概率大於 0.5...