2015-07-23 26 views

risposta

-1

Beh, per cominciare, mentre il Sistema ovviamente ha un metodo hashCode() (ogni oggetto ha una), non vedo molte ragioni nel chiamarlo. O qualsiasi possibilità di ottenere anche un oggetto di sistema per chiamarlo, come sistema è final e il costruttore è private. Quindi, probabilmente "praticamente mai" per hashCode(), credo.

Quindi, questo ci lascia con System.identityHashCode(Object) che fornisce semplicemente il valore hashcode predefinito per qualsiasi oggetto. Quindi, in altre parole, non ne hai bisogno molto spesso, perché se non si esegue l'override del metodo hashCode() nella classe, si otterrà lo stesso valore restituito per impostazione predefinita per gli oggetti (perché in pratica il codice hash predefinito(), quando non hai sovrascritto il metodo hashCode(), è semplicemente System.identityHashCode(this)). Potrebbero esserci alcuni casi d'uso quando usarlo, ma sono piuttosto rari.

0

Alcune delle tue classi potrebbero sostituire il metodo hashcode() nel tuo sistema. Per quegli oggetti, questo metodo fornisce il codice hash dell'oggetto fornito come verrebbe restituito dal genitore finale java.lang.Object. Consultare Java API per vedere la descrizione dai progettisti di linguaggi.

Credo che l'uso sia quando si desidera creare oggetti quasi non univoci per alcuni motivi. Quando dico quasi, ci possono essere oggetti con lo stesso codice hash. In questo modo si riduce al minimo l'uso dei metodi equals.

0

Dal documentation: int identityHashCode public static

(Object x)

restituisce lo stesso codice hash per l'oggetto dato come sarebbe restituito dal metodo predefinito hashCode(), se o non la classe dell'oggetto data sovrascrive hashCode(). Il codice hash per il riferimento null è zero.

Nota che identityHashCode restituisce il hashCode come implementato nella classe Object e che non è quello che di solito si desidera, così si dovrebbe semplicemente usare yourObject.hashCode().

Per quanto riguarda se ci potrebbero essere alcuni casi di utilizzo di questo metodo, se si dispone di una vasta gamma di Objects si sta scorrendo che potrebbe avere qualche null in esso, ed è necessario il hashCode di quegli oggetti, utilizzando System.identityHashCode(obj) potrebbe risparmiare un assegno nulla, non un grosso miglioramento.

2

Secondo il javadoc, il System.identityHashCode(Object o):

restituisce lo stesso codice hash per l'oggetto dato come sarebbe restituito dal metodo predefinito hashCode(), se la classe dell'oggetto data la priorità hashCode() . Il codice hash per il riferimento null è zero.

Così, al primo posto, System.identityHashCode(nullReference) vi darà sempre 0, invece di nullReference.hashCode() che ovviamente vi darà una NullPointerException a runtime.

Diciamo, però, considerare la seguente classe:

public class MysteriousOne { 
    @Override 
    public int hashCode() { 
     return 0xAAAABBBB; 
    } 

    //override equals() and so on... 
} 

La classe ignora hashCode(), che è perfettamente bene, anche se il codice hash per ogni istanza sarebbe lo stesso, che però non va bene, se vuoi distinguere le identità di più istanze. Di solito, provate l'output del metodo .toString() (che per impostazione predefinita fornisce il nome classe, seguito da un @ seguito dall'uscita hashCode()), ad esempio, per scoprire la vera identità di un oggetto, ma in questo caso il uscita sarebbe la stessa:

MysteriousOne first = new MysteriousOne(); 
MysteriousOne second = new MysteriousOne(); 
System.out.println("First: " + first); 
System.out.println("Second: " + second); 

il risultato sarebbe:

First: [email protected] 
Second: [email protected] 

Quindi, che sia tale implementazione di hashCode() è impossibile distinguere tra identità dei diversi casi. Che è dove System.identityHashCode() è a portata di mano.

Se fai

System.out.println("First: " + System.identityHashCode(first)); 
System.out.println("Second: " + System.identityHashCode(second)); 

si otterrebbe due numeri diversi per le diverse istanze, anche se il hashCode() della loro attuazione classe restituisce una costante (in realtà qui l'attuazione di override hashCode() non sarà chiamato a tutti, come da javadoc):

First: 366712642 
Second: 1829164700 

Inoltre, si può anche passare primitive per System.identityHashCode(Object o), poichè saranno inscatolati a loro involucri corrispondenti:

int i = 5; 
System.out.println(System.identityHashCode(i)); 

Maggiori informazioni:

+0

Non sono d'accordo con questa risposta, invece di usare 'identityHashCode' l'autore di' hashCode () dovrebbe invece aver risolto quella funzione :), avendo la stessa costante 'hashCode' per ogni istanza di oggetto sembra un'implementazione impropria del metodo. Questo non sembra un buon caso d'uso per 'identityHashCode'. –

+1

Era solo un esempio per sottolineare che con la chiamata 'System.identityHashCode()', l'implementazione sovrascritta 'hashCode()' non verrà presa in considerazione. –

0

Lo System.identityhashcode() restituiscono sempre l'implementazione predefinita java.lang.Object, anche se la classe per un particolare oggetto priorità su questa e calcola un diverso codice hash.

In alcune circostanze, potrebbe essere necessario questo tipo di definizione: Due oggetti o1 e o2 sono considerati uguali se e solo se o1 == o2. Nelle normali implementazioni, due oggetti o1 e o2 sono considerati uguali se e solo se o1 == null? o2 == null: o1.equals (o2). Se due oggetti sono uguali se e solo se o1 == o2, devono avere lo stesso codice hash. Quindi dovresti usare System.identityhashcode().

Ecco alcuni frammenti di codice che ho trovato.


private static int hash(Object x, int length) { 
    int h = System.identityHashCode(x); 
    // Multiply by -127, and left-shift to use least bit as part of hash 
    return ((h << 1) - (h << 8)) & (length - 1); 
} 

IdentityHashMap.java

public int hashCode() { 
    return System.identityHashCode(instance); 
} 

@Override 
@SuppressWarnings("rawtypes") 
public boolean equals(final Object other) { 
    return other instanceof IdentityWrapper && 
     ((IdentityWrapper) other).instance == instance; 
} 

IdentityWrapper.java (da Apache Commons Pool 2)

Problemi correlati