為什么我們可以為TreeSet提供比較器，而不能為HashSet提供類似Hasher的東西？

Question

在Java 6中，我的理解是，在創建樹集時可以向樹集提供一個比較器，以覆蓋集合中對象的“自然順序”。

您是否有想到，為什么Java不支持提供“哈希器”來覆蓋集合中對象的“自然哈希”呢？

編輯：在將來設計API時，從您那里獲得輸入可能會幫助我。

謝謝。

Answer 1

Hasher對象對於Object類中的hashCode()方法將是多余的。

如果要影響哈希的性質，則應重寫Object定義的hashCode()方法。 只需確保也重寫equals(Object) ，因為這兩個應該始終在一起。

HashSet或其他類似的數據結構將使用對象hashCode()方法獲取哈希值來確定bin存儲。 然后，它將使用equals()將該對象與同一bin中的其他對象進行比較以確定是否相等。

生成的哈希碼對於特定的對象類別必須是唯一的。 只需重寫hashCode()方法即可確保這一點，而無需在實現之間進行更改。 Hasher對象只會混淆並且沒有其他目的。 我想不出一個用例，其中需要多個哈希碼來存儲在不同的數據結構中。

Answer 2

以下是幾種可能的原因：

• 簡單性 -大多數人不需要多個哈希函數，因此，保持API的簡單性有必要依靠單個Object.hashCode（）方法

• 性能 -至少在標准庫中，由於HashSets和HashMaps等被廣泛使用，因此需要對其進行大量優化。 擁有一個單獨的“哈希器”的開銷是沒有意義的，盡管開銷可能很小。

• 私有字段 -存在hashCode（）可能依賴私有字段的問題，可能難以為某些對象創建外部“哈希”。

Answer 3

是的！ 簽出Object.hashCode方法。

再次閱讀您的問題后，我可能會開槍。 現在，我看到您說的是“替代”自然提示。 通常，我們在對象級別覆蓋哈希值，並放棄使用覆蓋的Hasher。

散列意味着比比較器更通用。 也就是說，散列幾乎總是應該創建統一的不信任值，並且幾乎不會發生沖突。 使用它們的容器應該很少需要專門的哈希機。

Answer 4

已經有人問過了。

Answer 5

您可以通過包裝一個對象來更改對象的哈希碼，該對象將以您的方式填充哈希碼。 假設您可能想讓一個對象以多種方式排序，但沒有多個哈希策略。

cf Trove4j為其HashMap支持哈希策略，而當我使用該庫時，一旦我記得就只使用了自定義哈希策略。