Konsistenz von hashCode () in einer Java-Zeichenfolge

Der hashCode-Wert eines Java- Strings wird wie folgt berechnet: ( String.hashCode () ):

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

Gibt es Umstände (z. B. JVM-Version, Anbieter usw.), unter denen der folgende Ausdruck als falsch ausgewertet wird?

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

Update Nr. 1: Wenn Sie behaupten, dass die Antwort "Ja, es gibt solche Umstände" lautet, geben Sie bitte ein konkretes Beispiel dafür, wann "Dies ist eine Java-Zeichenfolge" .hashCode ()! = 586653468. Versuchen Sie, so spezifisch / konkret zu sein wie möglich.

Update Nr. 2: Wir alle wissen, dass es im Allgemeinen schlecht ist, sich auf die Implementierungsdetails von hashCode () zu verlassen. Ich spreche jedoch speziell über String.hashCode (). Bitte konzentrieren Sie die Antwort auf String.hashCode (). Object.hashCode () ist im Kontext dieser Frage völlig irrelevant.

Ich kann diese Dokumentation bereits in Java 1.2 sehen.

Zwar sollten Sie sich im Allgemeinen nicht darauf verlassen, dass eine Hash-Code-Implementierung gleich bleibt, aber das Verhalten ist jetzt dokumentiert. Eine java.lang.StringÄnderung würde daher als Bruch bestehender Verträge gelten.

Wo immer möglich, sollten Sie nicht auf Hash - Codes angewiesen , um das gleiche über Versionen bleiben usw. - aber in meinem Kopf java.lang.Stringist ein Sonderfall , weil der Algorithmus hat angegeben ... solange Sie bereit bist , die Kompatibilität verlassen mit Releases vor dem Natürlich wurde ein Algorithmus angegeben.

Ich habe etwas über JDK 1.0 und 1.1 gefunden und> = 1.2:

In JDK 1.0.x und 1.1.x arbeitete die HashCode-Funktion für lange Strings, indem jedes n-te Zeichen abgetastet wurde. Dies ist ziemlich sicher, dass Sie viele Strings-Hashing auf den gleichen Wert haben würden, wodurch die Hashtable-Suche verlangsamt wird. In JDK 1.2 wurde die Funktion verbessert, um das bisherige Ergebnis mit 31 zu multiplizieren und dann das nächste Zeichen nacheinander hinzuzufügen. Dies ist etwas langsamer, kann aber Kollisionen viel besser vermeiden. Quelle: http://mindprod.com/jgloss/hashcode.html

Etwas anderes, weil Sie anscheinend eine Nummer benötigen: Wie wäre es mit CRC32 oder MD5 anstelle von Hashcode und Sie können loslegen - keine Diskussionen und überhaupt keine Sorgen ...

Sie sollten sich nicht darauf verlassen, dass ein Hash-Code einem bestimmten Wert entspricht. Nur dass es konsistente Ergebnisse innerhalb derselben Ausführung zurückgibt. In den API-Dokumenten heißt es:

Der allgemeine Vertrag von hashCode lautet:

• Immer wenn es während einer Ausführung einer Java-Anwendung mehr als einmal für dasselbe Objekt aufgerufen wird, muss die hashCode-Methode konsistent dieselbe Ganzzahl zurückgeben, sofern keine Informationen geändert werden, die für gleiche Vergleiche für das Objekt verwendet werden. Diese Ganzzahl muss von einer Ausführung einer Anwendung zu einer anderen Ausführung derselben Anwendung nicht konsistent bleiben.

BEARBEITEN Da das Javadoc für String.hashCode () angibt, wie der Hash-Code eines Strings berechnet wird, würde ein Verstoß gegen diese die öffentliche API-Spezifikation verletzen.

Wie oben erwähnt, sollten Sie sich im Allgemeinen nicht darauf verlassen, dass der Hash-Code einer Klasse gleich bleibt. Beachten Sie, dass auch nachfolgende Ausführungen derselben Anwendung auf derselben VM ausgeführt werden möglicherweise unterschiedliche Hashwerte erzeugen. Die Hash-Funktion von AFAIK the Sun JVM berechnet bei jedem Lauf den gleichen Hash, dies ist jedoch nicht garantiert.

Beachten Sie, dass dies nicht theoretisch ist. Die Hash-Funktion für java.lang.String wurde in JDK1.2 geändert (der alte Hash hatte Probleme mit hierarchischen Zeichenfolgen wie URLs oder Dateinamen, da er tendenziell denselben Hash für Zeichenfolgen erzeugte, die sich nur am Ende unterschieden).

java.lang.String ist ein Sonderfall, da der Algorithmus von hashCode () (jetzt) ​​dokumentiert ist, sodass Sie sich wahrscheinlich darauf verlassen können. Ich würde es immer noch als schlechte Praxis betrachten. Wenn Sie einen Hash-Algorithmus mit speziellen, dokumentierten Eigenschaften benötigen, schreiben Sie einfach einen :-).

Ein weiteres (!) Problem, über das Sie sich Sorgen machen müssen, ist die mögliche Änderung der Implementierung zwischen frühen / späten Java-Versionen. Ich glaube nicht, dass die Implementierungsdetails in Stein gemeißelt sind, und daher könnte ein Upgrade auf eine zukünftige Java-Version möglicherweise Probleme verursachen.

Fazit ist, ich würde mich nicht auf die Implementierung von verlassen hashCode().

Vielleicht können Sie mit diesem Mechanismus hervorheben, welches Problem Sie tatsächlich lösen möchten, und dies wird einen geeigneteren Ansatz hervorheben.

Nur um Ihre Frage zu beantworten und keine Diskussionen fortzusetzen. Die Apache Harmony JDK-Implementierung scheint einen anderen Algorithmus zu verwenden, zumindest sieht sie völlig anders aus:

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;
}

Apache Harmony

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;
}

Fühlen Sie sich frei, es selbst zu überprüfen ...

Wenn Sie sich Sorgen über Änderungen und möglicherweise inkompatible VMs machen, kopieren Sie einfach die vorhandene Hashcode-Implementierung in Ihre eigene Dienstprogrammklasse und generieren Sie damit Ihre Hashcodes.

Der Hashcode wird basierend auf den ASCII-Werten der Zeichen in der Zeichenfolge berechnet.

Dies ist die Implementierung in der String-Klasse wie folgt

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

Kollisionen im Hashcode sind unvermeidlich. Beispielsweise geben die Zeichenfolgen "Ea" und "FB" den gleichen Hashcode wie 2236 an