Java文字列でのhashCode（）の一貫性

Java StringのhashCode値は（String.hashCode（））として計算されます。

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

次の式がfalseと評価される状況（JVMバージョン、ベンダーなど）はありますか？

boolean expression = "This is a Java string".hashCode() == 586653468

更新＃1：「はい、そのような状況があります」と答えた場合は、「これはJava文字列です」という具体的な例を挙げてください。hashCode（）！=586653468。具体的/具体的になるようにしてください。できるだけ。

アップデート＃2：一般に、hashCode（）の実装の詳細に依存することは悪いことです。ただし、私は特にString.hashCode（）について話しているので、答えをString.hashCode（）に集中させてください。Object.hashCode（）は、この質問のコンテキストではまったく無関係です。

私はそのドキュメントをJava 1.2までさかのぼって見ることができます。

一般的に、ハッシュコードの実装が同じであることに依存すべきではないのは事実ですが、これはの動作が文書化されているためjava.lang.String、変更すると既存の規約に違反すると見なされます。

可能な限り、バージョン間で同じであるハッシュコードに依存するべきではありません。ただしjava.lang.String、アルゴリズムが指定されているというだけの理由で、私の考えは特別なケースです...以前のリリースとの互換性を放棄するつもりであればもちろん、アルゴリズムが指定されました。

JDK 1.0と1.1および> = 1.2について何かを見つけました。

JDK 1.0.xおよび1.1.xでは、長い文字列のhashCode関数は、n番目ごとの文字をサンプリングすることで機能していました。これにより、多くの文字列が同じ値にハッシュされるため、Hashtableルックアップが遅くなります。JDK 1.2では、これまでの結果に31を掛け、次の文字を順番に追加するように関数が改善されています。これは少し遅くなりますが、衝突を回避するにははるかに優れています。ソース： http //mindprod.com/jgloss/hashcode.html

あなたは数が必要なように見えるので、何か違います：ハッシュコードの代わりにCRC32またはMD5を使用してどうですか？

ハッシュコードが特定の値と等しいことに依存すべきではありません。同じ実行で一貫した結果が返されるだけです。APIドキュメントは次のように言っています：

hashCodeの一般的な規約は次のとおりです。

• Javaアプリケーションの実行中に同じオブジェクトで複数回呼び出される場合、オブジェクトの等値比較で使用される情報が変更されていなければ、hashCodeメソッドは常に同じ整数を返す必要があります。この整数は、アプリケーションのある実行から同じアプリケーションの別の実行まで一貫性を保つ必要はありません。

編集 String.hashCode（）のjavadocは文字列のハッシュコードの計算方法を指定しているため、これに違反するとパブリックAPI仕様に違反します。

上記のように、一般に、クラスのハッシュコードが同じであることに依存すべきではありません。注意あってもその後の実行、同じアプリケーションで同じVM異なるハッシュ値を生成することができます。申し訳ありませんが、Sun JVMのハッシュ関数は実行ごとに同じハッシュを計算しますが、これは保証されていません。

これは理論的なものではないことに注意してください。java.lang.Stringのハッシュ関数はJDK1.2 で変更されました（古いハッシュは、URLやファイル名などの階層文字列に問題がありました。これは、末尾のみが異なる文字列に対して同じハッシュを生成する傾向があったためです）。

java.lang.Stringは特殊なケースです。そのhashCode（）のアルゴリズムは（現在）文書化されているため、おそらくこれに依存できます。私はそれを悪い習慣だと考えています。ドキュメント化された特別なプロパティを持つハッシュアルゴリズムが必要な場合は、1つだけ記述してください:-)。

心配すべきもう1つの問題（！）は、Javaの初期バージョンと最新バージョンの間で実装が変更される可能性があることです。実装の詳細が確定しているとは思わないので、将来の Javaバージョンにアップグレードすると問題が発生する可能性があります。

結論は、私はの実装に依存しません hashCode()。

おそらく、このメカニズムを使用して実際に解決しようとしている問題を強調表示できます。これにより、より適切なアプローチが強調表示されます。

あなたの質問に答えるだけで、議論を続けるのではありません。Apache Harmony JDK実装は異なるアルゴリズムを使用しているようですが、少なくとも完全に異なるように見えます。

Sun JDK

public int hashCode() {
    int h = hash;
    if (h == 0) {
        int off = offset;
        char val[] = value;
        int len = count;

        for (int i = 0; i < len; i++) {
            h = 31*h + val[off++];
        }
        hash = h;
    }
    return h;
}

アパッチハーモニー

public int hashCode() {
    if (hashCode == 0) {
        int hash = 0, multiplier = 1;
        for (int i = offset + count - 1; i >= offset; i--) {
            hash += value[i] * multiplier;
            int shifted = multiplier << 5;
            multiplier = shifted - multiplier;
        }
        hashCode = hash;
    }
    return hashCode;
}

ご自由にご確認ください...

変更や、互換性のないVMが心配な場合は、既存のハッシュコード実装を独自のユーティリティクラスにコピーし、それを使用してハッシュコードを生成します。

ハッシュコードは、文字列内の文字のASCII値に基づいて計算されます。

これは文字列クラスの実装です。

public int hashCode() {
    int h = hash;
    if (h == 0 && value.length > 0) {
        hash = h = isLatin1() ? StringLatin1.hashCode(value)
                              : StringUTF16.hashCode(value);
    }
    return h;
}

ハッシュコードの衝突は避けられません。たとえば、文字列「Ea」と「FB」は2236と同じハッシュコードを提供します