問題タブ [hashcode]

ジェネリックリスナーの通知束用に抽象ジェネリックプロバイダーを実装しました。E子孫はnotifyListener(E)特定の通知コードでオーバーライドする必要があります。リスナーのバッキング リストには、 を選択しますWeakHashMap<K,V>。リスナーは弱参照として保持する必要があります。

典型的な使用:

すべてがうまく機能しますが、AbstractListリスナーとして子孫クラスが必要な場合、バッキングWeakHashMapはリスナーインスタンスを 1 つしか受け入れません! 明らかです-メソッドhashCode()とequals()リスナーはすべてのインスタンス（空のリスト）に対して同じ値を返すため、WeakHashMap.put以前に追加されたリスナーのみを置き換えます。

最善の解決策は何ですか？

1. 別の非 hashCode バッキング コレクションを使用します -- しかしWeakHashMap、弱い参照を自動的に管理するので、私にとってはとても便利です。

2. 単純な実装の抽象クラスなど、非汎用リスナーを使用しますequals() { return (this == object); }が、これはそれほど柔軟ではありません

3. addListener(E)単純な equals() を使用してリスナーにラッパーを使用します -- ただし、このラッパーは弱い参照のために呼び出し元に対して透過的ではありません

別のアイデア？

そのため、実装する必要がある一連のメソッドとのインターフェイスがあり、メソッド名は関係ありません。

このインターフェースを実装するオブジェクトは、多くの場合、コレクションに入れられ、使用したい特別な toString() 形式も持っています。

したがって、hashCode()、equals()、および toString() をインターフェースに配置して、これらのデフォルト メソッドをオーバーライドすることを忘れないようにすると便利だと思いました。しかし、これらのメソッドをインターフェイスに追加すると、これらの 3 つのメソッドが実装されていなくても、明示的にインターフェイスに配置しても、IDE/コンパイラは文句を言いません。

これが強制されないのはなぜですか? 他のメソッドを実装しないと不平を言いますが、これらの 3 つを強制することはありません。何を与える？手がかりはありますか？

java.util.HashMap私はとの内部実装を理解しようとしてきましたjava.util.HashSet。

以下は、しばらくの間私の頭に浮かんだ疑問です。

1. @Override public int hashcode()HashMap / HashSetでの重要性は何ですか？このハッシュコードは内部でどこで使用されていますか？
2. 私は一般的に、HashMapのキーがのStringようになるのを見てきましたmyMap<String,Object>。someObjectのように（文字列ではなく）値をマップできますmyMap<someObject, Object>か？これが成功するために私が従う必要があるすべての契約は何ですか？

前もって感謝します ！

編集：

1. キーのハッシュコード（チェック！）は、値がハッシュテーブルにマップされる実際のものであると言っていますか？そして、myMap.get(someKey);Javaが内部的に呼び出しsomeKey.hashCode()て、ハッシュテーブル内の数値を取得し、結果の値を探しますか？

回答：はい。

編集2：

2. でjava.util.HashSet、ハッシュテーブル用に生成されたキーはどこからですか？追加するのはオブジェクトからですか。mySet.add(myObject);次にmyObject.hashCode()、これをハッシュテーブルのどこに配置するかを決定しますか？（HashSetではキーを提供しないため）。

回答：追加されたオブジェクトがキーになります。値はダミーです！

私が知っているハッシュ構造 - HashTable、HashSet & HashMap。

それらはすべてバケット構造を使用していますか?つまり、2 つのハッシュコードがまったく同じである場合 、一方の要素が他方を上書きせず、そのハッシュコードに関連付けられた同じバケットに配置されますか?

Eclipse 3.5 には、Java hashCode() 関数を生成する非常に優れた機能があります。たとえば、生成されます（少し短縮されます:)

(クラスにさらに属性がある場合は、result = prime * result + attribute.hashCode();追加の属性ごとに繰り返されます。int の場合、.hashCode() は省略できます。)

これは問題ないように見えますが、プライムの選択は 31 です。これはおそらく、Java String の hashCode 実装から取られています。これは、ハードウェア乗算器の導入後、長い間使用されなくなったパフォーマンス上の理由から使用されていました。ここでは、i と j の小さな値に対して多くのハッシュコードの衝突があります。たとえば、(0,0) と (-1,31) は同じ値です。小さな値が頻繁に発生するので、これは Bad Thing(TM) だと思います。String.hashCode の場合、「Ca」や「DB」など、同じハッシュコードを持つ短い文字列も多数見つかります。大きな素数を取る場合、素数権を選択すればこの問題はなくなります。

私の質問: 選択するのに適した素数は何ですか? それを見つけるためにどのような基準を適用しますか？

これは一般的な質問であるため、i と j の範囲を示したくありません。しかし、ほとんどのアプリケーションでは、比較的小さな値が大きな値よりも頻繁に発生すると思います。(大きな値を持っている場合、素数の選択はおそらく重要ではありません。) 大きな違いはないかもしれませんが、より良い選択はこれを改善するための簡単で明白な方法です。Commons lang HashCodeBuilderも、奇妙なことに小さい値を提案します。

(明確化: これはWhy does Java's hashCode() in String use 31 as a Multiplier? の複製ではありません。なぜなら、私の質問は JDK の 31 の歴史には関係なく、新しいコードでより良い値になるものについてです同じ基本的なテンプレートを使用します.そこにある答えはどれもそれに答えようとしません.)

セット内のすべてのオブジェクトに対して一意の値を生成する必要があるタスクがあります。ハッシュコードコントラクトで衝突が許可されていない場合は、ハッシュコードを使用するのが最適です。

1つのアイデア：すべてのオブジェクトのハッシュコードをマルチセットに記録します。次に、一意の識別子としてハッシュコードを使用しますが、そのハッシュコードがセットに複数回含まれている場合は、セットに含まれていない別の値を使用します。しかし、これはかさばり、ぎこちなく感じます。

より良いアイデア？

これが私がすでに持っているものです：

編集：これは元々明確ではなかったと思いますが、ID番号はオブジェクトの関数である必要があります。これは、何度も呼び出され、同じ値に対して同じ結果が得られるgetVertexName(V)ことを期待しているためです。V

また、頂点タイプはジェネリックです。したがって、これを修正するために特定のクラスに変更を加えることはできません。

Stateオブジェクト（KeyとしてCharacter、ValueとしてStateを持つHas​​hMapsをallStatesという名前のArrayListに配置したい。ここでequalsメソッドとhashCodeメソッドをオーバーライドする必要がありますか？なぜですか？どのように？

このコードは、これまでに作成したAutomatonクラスとStateクラス用です。

オブジェクトのコレクションを行で表示するアプリケーションがあります。1 つのオブジェクト = 1 つの行です。オブジェクトは HashMap に格納されます。行の順序は、アプリケーションの機能には影響しません (そのため、ソート可能なコレクションの代わりに HashMap が使用されました)。

しかし、Java 仮想マシンの 2 つの異なるバージョンを使用して実行すると、同じアプリケーションが異なる方法で実行されることに気付きました。このアプリケーションは JDK 5 を使用してコンパイルされており、Java 5 または Java 6 ランタイムのいずれかを使用して実行でき、機能上の違いはありません。

問題のオブジェクトはオーバーライドjava.lang.Object#hashCode()され、明らかに Java API で指定された契約に従うように注意が払われています。これは、(同じ Java ランタイムで) アプリケーションを実行するたびに常に同じ順序で表示されるという事実によって証明されます。

念のために言っておきますが、Java ランタイムの選択が順序に影響するのはなぜですか?

私はこのテストコードを持っています:

// public int hashCode() { return 9; }コメントを外し た場合はm.size()2 を返し、コメントを残した場合は 3 を返します。なんで？

私は、エンティティにハッシュコードとイコールを実装することが一般的に良い方法であるかどうかを処理する最善の方法について推論しようとしています (一般的な意味でのエンティティを意味しますが、ほとんどの場合、JPA エンティティになります)。

Hibernate マニュアルhttp://docs.jboss.org/hibernate/core/3.3/reference/en/html/best-practices.htmlの第 24 章には、次のように書かれています...

すべてのエンティティの自然キーを特定し、 を使用してそれらをマッピングします。equals() と hashCode() を実装して、自然キーを構成するプロパティを比較します。

.equals と .hashcode にこれらの自然キーのみを含めることは理にかなっていますが、同じエンティティのインスタンスが複数ある場合 (自然 ID が同じであるため、ハッシュコードが同じ) はどうでしょうか? このプラクティスは、アプリケーションの他の場所に微妙な影響を与える可能性があるようです。これを大規模に試した人はいますか？