Beste Implementierung für die hashCode-Methode für eine Sammlung

Wie entscheiden wir uns für die beste Implementierung der hashCode()Methode für eine Sammlung (vorausgesetzt, die Methode equals wurde korrekt überschrieben)?

Die beste Implementierung? Das ist eine schwierige Frage, da sie vom Verwendungsmuster abhängt.

A für fast alle Fälle angemessen gute Umsetzung wurde vorgeschlagen Josh Bloch ‚s Effective Java in Punkt 8 (zweite Auflage). Das Beste ist, es dort nachzuschlagen, weil der Autor dort erklärt, warum der Ansatz gut ist.

Eine kurze Version

1. Erstellen Sie einen Wert int resultund weisen Sie einen Wert ungleich Null zu.

2. Berechnen Sie für jedes f in der equals()Methode getestete Feld einen Hash-Code cmit:

   • Wenn das Feld f a ist boolean: berechnen (f ? 0 : 1);
   • Wenn das Feld f a byteist char, shortoder int: berechnen (int)f;
   • Wenn das Feld f a ist long: berechnen (int)(f ^ (f >>> 32));
   • Wenn das Feld f a ist float: berechnen Float.floatToIntBits(f);
   • Wenn das Feld f a ist double: Berechnen Double.doubleToLongBits(f)und behandeln Sie den Rückgabewert wie jeden langen Wert;
   • Wenn das Feld f ein Objekt ist : Verwenden Sie das Ergebnis der hashCode()Methode oder 0 if f == null;
   • Wenn das Feld f ein Array ist : Sehen Sie jedes Feld als separates Element und berechnen Sie den Hash-Wert rekursiv und kombinieren Sie die Werte wie nachfolgend beschrieben.

3. Kombinieren Sie den Hashwert cmit result:

   result = 37 * result + c

4. Rückkehr result

Dies sollte für die meisten Verwendungssituationen zu einer ordnungsgemäßen Verteilung der Hashwerte führen.

Wenn Sie mit der von dmeister empfohlenen effektiven Java-Implementierung zufrieden sind, können Sie einen Bibliotheksaufruf verwenden, anstatt Ihren eigenen zu rollen:

@Override
public int hashCode() {
    return Objects.hashCode(this.firstName, this.lastName);
}

Dies erfordert entweder Guava ( com.google.common.base.Objects.hashCode) oder die Standardbibliothek in Java 7 ( java.util.Objects.hash), funktioniert jedoch auf die gleiche Weise.

Es ist besser, die von Eclipse bereitgestellten Funktionen zu verwenden, die ziemlich gute Arbeit leisten, und Sie können Ihre Anstrengungen und Energie in die Entwicklung der Geschäftslogik stecken.

Obwohl dies mit der AndroidDokumentation (Wayback Machine) und meinem eigenen Code auf Github verbunden ist funktioniert es im Allgemeinen für Java. Meine Antwort ist eine Erweiterung von dmeisters Antwort mit nur Code, der viel einfacher zu lesen und zu verstehen ist.

@Override 
public int hashCode() {

    // Start with a non-zero constant. Prime is preferred
    int result = 17;

    // Include a hash for each field.

    // Primatives

    result = 31 * result + (booleanField ? 1 : 0);                   // 1 bit   » 32-bit

    result = 31 * result + byteField;                                // 8 bits  » 32-bit 
    result = 31 * result + charField;                                // 16 bits » 32-bit
    result = 31 * result + shortField;                               // 16 bits » 32-bit
    result = 31 * result + intField;                                 // 32 bits » 32-bit

    result = 31 * result + (int)(longField ^ (longField >>> 32));    // 64 bits » 32-bit

    result = 31 * result + Float.floatToIntBits(floatField);         // 32 bits » 32-bit

    long doubleFieldBits = Double.doubleToLongBits(doubleField);     // 64 bits (double) » 64-bit (long) » 32-bit (int)
    result = 31 * result + (int)(doubleFieldBits ^ (doubleFieldBits >>> 32));

    // Objects

    result = 31 * result + Arrays.hashCode(arrayField);              // var bits » 32-bit

    result = 31 * result + referenceField.hashCode();                // var bits » 32-bit (non-nullable)   
    result = 31 * result +                                           // var bits » 32-bit (nullable)   
        (nullableReferenceField == null
            ? 0
            : nullableReferenceField.hashCode());

    return result;

}

BEARBEITEN

Wenn Sie überschreiben hashcode(...), möchten Sie normalerweise auch überschreiben equals(...). Für diejenigen, die bereits implementiert haben oder bereits implementiert haben equals, ist hier eine gute Referenz von meinem Github ...

@Override
public boolean equals(Object o) {

    // Optimization (not required).
    if (this == o) {
        return true;
    }

    // Return false if the other object has the wrong type, interface, or is null.
    if (!(o instanceof MyType)) {
        return false;
    }

    MyType lhs = (MyType) o; // lhs means "left hand side"

            // Primitive fields
    return     booleanField == lhs.booleanField
            && byteField    == lhs.byteField
            && charField    == lhs.charField
            && shortField   == lhs.shortField
            && intField     == lhs.intField
            && longField    == lhs.longField
            && floatField   == lhs.floatField
            && doubleField  == lhs.doubleField

            // Arrays

            && Arrays.equals(arrayField, lhs.arrayField)

            // Objects

            && referenceField.equals(lhs.referenceField)
            && (nullableReferenceField == null
                        ? lhs.nullableReferenceField == null
                        : nullableReferenceField.equals(lhs.nullableReferenceField));
}

Stellen Sie zunächst sicher, dass equals korrekt implementiert ist. Aus einem IBM DeveloperWorks-Artikel :

• Symmetrie: Für zwei Referenzen, a und b, a.equals (b) genau dann, wenn b.equals (a)
• Reflexivität: Für alle Nicht-Null-Referenzen gilt a.equals (a)
• Transitivität: Wenn a.equals (b) und b.equals (c), dann a.equals (c)

Stellen Sie dann sicher, dass die Beziehung zu hashCode den Kontakt berücksichtigt (aus demselben Artikel):

• Konsistenz mit hashCode (): Zwei gleiche Objekte müssen denselben hashCode () -Wert haben

Schließlich sollte eine gute Hash-Funktion danach streben, sich der idealen Hash-Funktion anzunähern .

about8.blogspot.com, sagten Sie

Wenn equals () für zwei Objekte true zurückgibt, sollte hashCode () denselben Wert zurückgeben. Wenn equals () false zurückgibt, sollte hashCode () unterschiedliche Werte zurückgeben

Ich kann dir nicht zustimmen. Wenn zwei Objekte denselben Hashcode haben, muss dies nicht bedeuten, dass sie gleich sind.

Wenn A gleich B ist, muss A.hashcode gleich B.hascode sein

aber

Wenn A.hashcode gleich B.hascode ist, bedeutet dies nicht, dass A gleich B sein muss

Wenn Sie Eclipse verwenden, können Sie Folgendes generieren equals()und hashCode()verwenden:

Quelle -> Generiere hashCode () und equals ().

Mit dieser Funktion können Sie entscheiden, welche Felder Sie für die Berechnung von Gleichheit und Hashcode verwenden möchten, und Eclipse generiert die entsprechenden Methoden.

Es gibt eine gute Umsetzung der Effective Java ‚s hashcode()und equals()Logik in Apache Commons Lang . Kasse HashCodeBuilder und EqualsBuilder .

Nur eine kurze Anmerkung zum Ausfüllen anderer detaillierterer Antworten (in Bezug auf den Code):

Wenn ich die Frage betrachte, wie ich eine Hash-Tabelle in Java erstelle, und insbesondere den jGuru-FAQ-Eintrag , glaube ich, dass einige andere Kriterien, anhand derer ein Hash-Code beurteilt werden könnte, sind:

• Synchronisation (unterstützt der Algo gleichzeitigen Zugriff oder nicht)?
• Fail-Safe-Iteration (erkennt der Algo eine Sammlung, die sich während der Iteration ändert)
• Nullwert (unterstützt der Hash-Code den Nullwert in der Sammlung)

Wenn ich Ihre Frage richtig verstehe, haben Sie eine benutzerdefinierte Auflistungsklasse (dh eine neue Klasse, die sich über die Auflistungsschnittstelle erstreckt) und möchten die Methode hashCode () implementieren.

Wenn Ihre Auflistungsklasse AbstractList erweitert, müssen Sie sich keine Sorgen machen. Es gibt bereits eine Implementierung von equals () und hashCode (), bei der alle Objekte durchlaufen und ihre hashCodes () addiert werden.

   public int hashCode() {
      int hashCode = 1;
      Iterator i = iterator();
      while (i.hasNext()) {
        Object obj = i.next();
        hashCode = 31*hashCode + (obj==null ? 0 : obj.hashCode());
      }
  return hashCode;
   }

Wenn Sie nun den Hash-Code für eine bestimmte Klasse am besten berechnen möchten, verwende ich normalerweise den Operator ^ (bitweise exklusiv oder), um alle Felder zu verarbeiten, die ich in der Methode equals verwende:

public int hashCode(){
   return intMember ^ (stringField != null ? stringField.hashCode() : 0);
}

@ about8: da ist ein ziemlich schwerwiegender Fehler.

Zam obj1 = new Zam("foo", "bar", "baz");
Zam obj2 = new Zam("fo", "obar", "baz");

gleicher Hashcode

Sie wollen wahrscheinlich so etwas wie

public int hashCode() {
    return (getFoo().hashCode() + getBar().hashCode()).toString().hashCode();

(Kann man hashCode heutzutage direkt von int in Java bekommen? Ich denke, es macht ein Autocasting. Wenn das der Fall ist, überspringe den toString, es ist hässlich.)

Da Sie speziell nach Sammlungen gefragt haben, möchte ich einen Aspekt hinzufügen, den die anderen Antworten noch nicht erwähnt haben: Eine HashMap erwartet nicht, dass ihre Schlüssel ihren Hashcode ändern, sobald sie der Sammlung hinzugefügt werden. Würde den ganzen Zweck besiegen ...

Verwenden Sie die Reflektionsmethoden für Apache Commons EqualsBuilder und HashCodeBuilder .

Ich benutze einen winzigen Wrapper, Arrays.deepHashCode(...)weil er Arrays, die als Parameter geliefert werden, korrekt behandelt

public static int hash(final Object... objects) {
    return Arrays.deepHashCode(objects);
}

Jede Hashing-Methode, die den Hash-Wert gleichmäßig über den möglichen Bereich verteilt, ist eine gute Implementierung. Siehe effektives Java ( http://books.google.com.au/books?id=ZZOiqZQIbRMC&dq=effective+java&pg=PP1&ots=UZMZ2siN25&sig=kR0n73DHJOn-D77qGj0wOxAxiZw&hl=en=res ) dort für die Implementierung von Hashcode (Punkt 9 denke ich ...).

Ich bevorzuge die Verwendung von Dienstprogrammmethoden aus der Google Collections-Bibliothek der Klasse Objects , mit denen ich meinen Code sauber halten kann. Sehr oft equalsund hashcodeMethoden werden aus der IDE-Vorlage erstellt, sodass sie nicht sauber zu lesen sind.

Hier ist eine weitere Demonstration des JDK 1.7+ -Ansatzes mit berücksichtigten Superklassenlogiken. Ich sehe es als ziemlich praktisch an, wenn die Objektklasse hashCode () berücksichtigt wird, reine JDK-Abhängigkeit und keine zusätzliche manuelle Arbeit. bitte beachten SieObjects.hash() tolerant ist.

Ich habe keine equals()Implementierung aufgenommen, aber in Wirklichkeit werden Sie sie natürlich brauchen.

import java.util.Objects;

public class Demo {

    public static class A {

        private final String param1;

        public A(final String param1) {
            this.param1 = param1;
        }

        @Override
        public int hashCode() {
            return Objects.hash(
                super.hashCode(),
                this.param1);
        }

    }

    public static class B extends A {

        private final String param2;
        private final String param3;

        public B(
            final String param1,
            final String param2,
            final String param3) {

            super(param1);
            this.param2 = param2;
            this.param3 = param3;
        }

        @Override
        public final int hashCode() {
            return Objects.hash(
                super.hashCode(),
                this.param2,
                this.param3);
        }
    }

    public static void main(String [] args) {

        A a = new A("A");
        B b = new B("A", "B", "C");

        System.out.println("A: " + a.hashCode());
        System.out.println("B: " + b.hashCode());
    }

}

Die Standardimplementierung ist schwach und führt zu unnötigen Kollisionen. Stellen Sie sich a

class ListPair {
    List<Integer> first;
    List<Integer> second;

    ListPair(List<Integer> first, List<Integer> second) {
        this.first = first;
        this.second = second;
    }

    public int hashCode() {
        return Objects.hashCode(first, second);
    }

    ...
}

Jetzt,

new ListPair(List.of(a), List.of(b, c))

und

new ListPair(List.of(b), List.of(a, c))

haben das gleiche hashCode, nämlich 31*(a+b) + cals Multiplikator fürList.hashCode verwendete hier wiederverwendet wird. Kollisionen sind natürlich unvermeidlich, aber unnötige Kollisionen zu erzeugen ist einfach ... unnötig.

Es ist nichts wesentlich Kluges an der Verwendung 31. Der Multiplikator muss ungerade sein, um Informationsverluste zu vermeiden (jeder gerade Multiplikator verliert mindestens das höchstwertige Bit, Vielfache von vier verlieren zwei usw.). Jeder ungerade Multiplikator ist verwendbar. Kleine Multiplikatoren können zu einer schnelleren Berechnung führen (die JIT kann Verschiebungen und Additionen verwenden), aber da die Multiplikation bei modernen Intel / AMD nur eine Latenz von drei Zyklen aufweist, spielt dies kaum eine Rolle. Kleine Multiplikatoren führen auch zu mehr Kollisionen bei kleinen Eingaben, was manchmal ein Problem sein kann.

Die Verwendung einer Primzahl ist sinnlos, da Primzahlen im Ring Z / (2 ** 32) keine Bedeutung haben.

Daher würde ich empfehlen, eine zufällig ausgewählte große ungerade Zahl zu verwenden (zögern Sie nicht, eine Primzahl zu nehmen). Da i86 / amd64-CPUs einen kürzeren Befehl für Operanden verwenden können, die in ein einzelnes vorzeichenbehaftetes Byte passen, gibt es für Multiplikatoren wie 109 einen winzigen Geschwindigkeitsvorteil. Nehmen Sie zur Minimierung von Kollisionen etwa 0x58a54cf5.

Die Verwendung verschiedener Multiplikatoren an verschiedenen Orten ist hilfreich, reicht jedoch wahrscheinlich nicht aus, um die zusätzliche Arbeit zu rechtfertigen.

Beim Kombinieren von Hashwerten verwende ich normalerweise die Kombinationsmethode, die in der Boost C ++ - Bibliothek verwendet wird, nämlich:

seed ^= hasher(v) + 0x9e3779b9 + (seed<<6) + (seed>>2);

Dies sorgt für eine ziemlich gleichmäßige Verteilung. Weitere Informationen zur Funktionsweise dieser Formel finden Sie im Beitrag zu StackOverflow: Magische Zahl in boost :: hash_combine

Es gibt eine gute Diskussion über verschiedene Hash-Funktionen unter: http://burtleburtle.net/bob/hash/doobs.html

Für eine einfache Klasse ist es oft am einfachsten, hashCode () basierend auf den Klassenfeldern zu implementieren, die von der equals () -Implementierung überprüft werden.

public class Zam {
    private String foo;
    private String bar;
    private String somethingElse;

    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        }

        if (obj == null) {
            return false;
        }

        if (getClass() != obj.getClass()) {
            return false;
        }

        Zam otherObj = (Zam)obj;

        if ((getFoo() == null && otherObj.getFoo() == null) || (getFoo() != null && getFoo().equals(otherObj.getFoo()))) {
            if ((getBar() == null && otherObj. getBar() == null) || (getBar() != null && getBar().equals(otherObj. getBar()))) {
                return true;
            }
        }

        return false;
    }

    public int hashCode() {
        return (getFoo() + getBar()).hashCode();
    }

    public String getFoo() {
        return foo;
    }

    public String getBar() {
        return bar;
    }
}

Das Wichtigste ist, hashCode () und equals () konsistent zu halten: Wenn equals () für zwei Objekte true zurückgibt, sollte hashCode () denselben Wert zurückgeben. Wenn equals () false zurückgibt, sollte hashCode () unterschiedliche Werte zurückgeben.