Migliore implementazione per il metodo hashCode per una raccolta

Come possiamo decidere la migliore implementazione del hashCode()metodo per una raccolta (supponendo che il metodo uguale sia stato sovrascritto correttamente)?

La migliore implementazione? Questa è una domanda difficile perché dipende dal modello di utilizzo.

Una per quasi tutti i casi l'attuazione ragionevole buon stato proposto in Josh Bloch s' Effective Java nel punto 8 (seconda edizione). La cosa migliore è guardarlo lì perché l'autore spiega perché l'approccio è buono.

Una versione corta

1. Creare a int resulte assegnare un valore diverso da zero .

2. Per ogni campo f testato nel equals()metodo, calcola un codice hash cper:

   • Se il campo f è a boolean: calcola (f ? 0 : 1);
   • Se il campo f è una byte, char, shorto int: calcolare (int)f;
   • Se il campo f è a long: calcola (int)(f ^ (f >>> 32));
   • Se il campo f è a float: calcola Float.floatToIntBits(f);
   • Se il campo f è a double: calcola Double.doubleToLongBits(f)e gestisci il valore di ritorno come ogni valore lungo;
   • Se il campo f è un oggetto : utilizzare il risultato del hashCode()metodo o 0 se f == null;
   • Se il campo f è un array : vedi ogni campo come elemento separato e calcola il valore di hash in modo ricorsivo e combina i valori come descritto di seguito.

3. Combina il valore hash ccon result:

   result = 37 * result + c

4. Ritorno result

Ciò dovrebbe comportare una corretta distribuzione dei valori di hash per la maggior parte delle situazioni d'uso.

Se sei soddisfatto dell'implementazione effettiva di Java consigliata da dmeister, puoi usare una chiamata in libreria invece di eseguire il roll-roll del tuo:

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

Ciò richiede Guava ( com.google.common.base.Objects.hashCode) o la libreria standard in Java 7 ( java.util.Objects.hash) ma funziona allo stesso modo.

È meglio usare la funzionalità fornita da Eclipse che fa un ottimo lavoro e puoi mettere i tuoi sforzi ed energia nello sviluppo della logica di business.

Sebbene sia collegato alla Androiddocumentazione (Wayback Machine) e al mio codice su Github , funzionerà per Java in generale. La mia risposta è un'estensione della Risposta di dmeister con solo codice che è molto più facile da leggere e comprendere.

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

}

MODIFICARE

In genere, quando si esegue l'override hashcode(...), si desidera anche eseguire l'override equals(...). Quindi, per quelli che saranno o sono già stati implementati equals, ecco un buon riferimento dal mio 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));
}

Innanzitutto assicurarsi che equals sia implementato correttamente. Da un articolo IBM DeveloperWorks :

• Simmetria: per due riferimenti, aeb, a.equals (b) se e solo se b.equals (a)
• Riflessività: per tutti i riferimenti non nulli, a.equals (a)
• Transitività: se a.equals (b) e b.equals (c), quindi a.equals (c)

Quindi assicurati che la loro relazione con hashCode rispetti il ​​contatto (dallo stesso articolo):

• Coerenza con hashCode (): due oggetti uguali devono avere lo stesso valore hashCode ()

Infine, una buona funzione hash dovrebbe sforzarsi di avvicinarsi alla funzione hash ideale .

about8.blogspot.com, hai detto

se equals () restituisce true per due oggetti, hashCode () dovrebbe restituire lo stesso valore. Se equals () restituisce false, allora hashCode () dovrebbe restituire valori diversi

Non posso essere d'accordo con te. Se due oggetti hanno lo stesso hashcode non significa che siano uguali.

Se A è uguale a B, allora A.hashcode deve essere uguale a B.hascode

ma

se A.hashcode è uguale a B.hascode, ciò non significa che A deve essere uguale a B

Se usi eclipse, puoi generare equals()e hashCode()usare:

Sorgente -> Genera hashCode () ed equals ().

Utilizzando questa funzione è possibile decidere quali campi si desidera utilizzare per il calcolo dell'uguaglianza e del codice hash ed Eclipse genera i metodi corrispondenti.

C'è un'implementazione bene della Effective Java s' hashcode()e equals()la logica in Apache Commons Lang . Acquista HashCodeBuilder ed EqualsBuilder .

Solo una breve nota per completare un'altra risposta più dettagliata (in termini di codice):

Se considero la domanda come faccio a creare una tabella hash-in-java e soprattutto la voce FAQ di jGuru , credo che alcuni altri criteri su cui si possa giudicare un codice hash sono:

• sincronizzazione (l'algo supporta l'accesso simultaneo o no)?
• iterazione sicura (l'algo rileva una raccolta che cambia durante l'iterazione)
• valore null (il codice hash supporta il valore null nella raccolta)

Se capisco correttamente la tua domanda, hai una classe di raccolta personalizzata (ovvero una nuova classe che si estende dall'interfaccia di Raccolta) e vuoi implementare il metodo hashCode ().

Se la tua classe di raccolta estende AbstractList, quindi non devi preoccuparti, esiste già un'implementazione di equals () e hashCode () che funziona iterando attraverso tutti gli oggetti e aggiungendo i loro hashCodes () insieme.

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

Ora, se quello che vuoi è il modo migliore per calcolare il codice hash per una classe specifica, normalmente uso l'operatore ^ (bitwise exclusive o) per elaborare tutti i campi che utilizzo nel metodo equals:

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

@ about8: c'è un bug piuttosto grave lì.

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

stesso hashcode

probabilmente vuoi qualcosa del genere

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

(puoi ottenere hashCode direttamente da int in Java in questi giorni? Penso che faccia un po 'di autocasting .. in tal caso, salta il toString, è brutto.)

Come hai specificamente richiesto le raccolte, vorrei aggiungere un aspetto che le altre risposte non hanno ancora menzionato: una HashMap non si aspetta che le loro chiavi cambino il loro codice hash una volta che sono state aggiunte alla raccolta. Avrebbe sconfitto l'intero scopo ...

Usa i metodi di riflessione su Apache Commons EqualsBuilder e HashCodeBuilder .

Uso un piccolo wrapper Arrays.deepHashCode(...)perché gestisce correttamente le matrici fornite come parametri

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

qualsiasi metodo di hashing che distribuisce uniformemente il valore di hash nell'intervallo possibile è una buona implementazione. Vedere java efficace ( http://books.google.com.au/books?id=ZZOiqZQIbRMC&dq=effective+java&pg=PP1&ots=UZMZ2siN25&sig=kR0n73DHJOn-D77qGj0wOxAxiZw&hl=en&sa=X&oi=book_result&resnum=1&ct=result ), v'è una buona mancia lì dentro per l'implementazione dell'hashcode (elemento 9 penso ...).

Preferisco utilizzare metodi di utilità dalla libreria di Google Collections della classe Oggetti che mi aiutano a mantenere pulito il mio codice. Molto spesso equalse i hashcodemetodi sono fatti dal modello IDE, quindi non sono puliti da leggere.

Ecco un'altra dimostrazione di approccio JDK 1.7+ con logiche di superclasse prese in considerazione. Lo vedo abbastanza comodo con la classe Object hashCode () spiegata, pura dipendenza JDK e nessun lavoro manuale aggiuntivo. notare cheObjects.hash() è tollerante null.

Non ho incluso alcuna equals()implementazione, ma in realtà ovviamente ne avrai bisogno.

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

}

L'implementazione standard è debole e il suo utilizzo porta a collisioni non necessarie. Immagina 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);
    }

    ...
}

Adesso,

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

e

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

hanno lo stesso hashCode, vale 31*(a+b) + ca dire il moltiplicatore utilizzato perList.hashCode viene riutilizzato qui. Ovviamente, le collisioni sono inevitabili, ma produrre collisioni inutili è solo ... inutile.

Non c'è nulla di sostanzialmente intelligente nell'uso 31. Il moltiplicatore deve essere dispari per evitare di perdere informazioni (qualsiasi moltiplicatore pari perde almeno il bit più significativo, i multipli di quattro ne perdono due, ecc.). È possibile utilizzare qualsiasi moltiplicatore dispari. I piccoli moltiplicatori possono portare a un calcolo più rapido (la JIT può utilizzare turni e aggiunte), ma dato che la moltiplicazione ha una latenza di soli tre cicli sui moderni Intel / AMD, questo non ha importanza. I piccoli moltiplicatori portano anche a una maggiore collisione per piccoli input, che a volte può essere un problema.

L'uso di un numero primo è inutile poiché i numeri primi non hanno alcun significato nell'anello Z / (2 ** 32).

Quindi, consiglierei di usare un grande numero dispari scelto casualmente (sentiti libero di prendere un numero primo). Poiché le CPU i86 / amd64 possono utilizzare un'istruzione più breve per gli operandi che si adattano a un singolo byte con segno, esiste un vantaggio di velocità minuscola per moltiplicatori come 109. Per ridurre al minimo le collisioni, prendere qualcosa come 0x58a54cf5.

L'uso di moltiplicatori diversi in luoghi diversi è utile, ma probabilmente non è sufficiente per giustificare il lavoro aggiuntivo.

Quando combino i valori hash, di solito utilizzo il metodo di combinazione utilizzato nella libreria boost c ++, vale a dire:

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

Questo fa un buon lavoro nel garantire una distribuzione uniforme. Per alcune discussioni sul funzionamento di questa formula, vedere il post StackOverflow: numero magico in boost :: hash_combine

C'è una buona discussione delle diverse funzioni hash su: http://burtleburtle.net/bob/hash/doobs.html

Per una classe semplice è spesso più semplice implementare hashCode () in base ai campi della classe che sono controllati dall'implementazione equals ().

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

La cosa più importante è mantenere hashCode () ed equals () coerenti: se equals () restituisce true per due oggetti, allora hashCode () dovrebbe restituire lo stesso valore. Se equals () restituisce false, allora hashCode () dovrebbe restituire valori diversi.