Java: intero è uguale a ==

A partire da Java 1.5, puoi praticamente scambiarti Integercon intmolte situazioni.

Tuttavia, ho trovato un potenziale difetto nel mio codice che mi ha sorpreso un po '.

Il seguente codice:

Integer cdiCt = ...;
Integer cdsCt = ...;
...
if (cdiCt != null && cdsCt != null && cdiCt != cdsCt)
    mismatch = true;

sembra che abbia impostato erroneamente la mancata corrispondenza quando i valori erano uguali, anche se non riesco a determinare in quali circostanze. Ho impostato un punto di interruzione in Eclipse e ho visto che i Integervalori erano entrambi 137, e ho ispezionato l'espressione booleana e ha detto che era falso, ma quando l'ho scavalcato, stava impostando la mancata corrispondenza su vero.

Modifica del condizionale in:

if (cdiCt != null && cdsCt != null && !cdiCt.equals(cdsCt))

risolto il problema.

Qualcuno può fare luce sul perché questo è successo? Finora ho visto solo il comportamento sul mio localhost sul mio PC. In questo caso particolare, il codice ha superato con successo circa 20 confronti, ma non è riuscito il 2. Il problema era costantemente riproducibile.

Se si tratta di un problema prevalente, dovrebbe causare errori negli altri nostri ambienti (sviluppo e test), ma finora nessuno ha segnalato il problema dopo centinaia di test che eseguono questo frammento di codice.

Non è ancora legittimo utilizzare ==per confrontare due Integervalori?

Oltre a tutte le risposte dettagliate di seguito, il seguente link stackoverflow contiene alcune informazioni aggiuntive. In realtà avrebbe risposto alla mia domanda originale, ma poiché non ho menzionato l'autoboxing nella mia domanda, non è stato visualizzato nei suggerimenti selezionati:

Perché il compilatore / JVM non può semplicemente fare in modo che l'autoboxing “funzioni”?

La JVM sta memorizzando nella cache i valori interi. == funziona solo con numeri compresi tra -128 e 127 http://www.owasp.org/index.php/Java_gotchas#Immutable_Objects_.2F_Wrapper_Class_Caching

Non è possibile confrontare due Integercon un semplice ==sono gli oggetti, quindi il più delle volte i riferimenti non saranno gli stessi.

C'è un trucco, Integertra -128 e 127, i riferimenti saranno gli stessi degli usi di autoboxing Integer.valueOf()che memorizzano nella cache piccoli numeri interi.

Se il valore p in box è vero, falso, un byte, un carattere nell'intervallo da \ u0000 a \ u007f o un numero int o short tra -128 e 127, quindi lasciare che r1 e r2 siano i risultati di due conversioni di boxe di p. È sempre il caso che r1 == r2.

Risorse:

• JLS - Pugilato

Sullo stesso argomento:

• boxe automatica vs boxe manuale java

Il problema è che i tuoi due oggetti Integer sono proprio questi, oggetti. Non corrispondono perché stai confrontando i due riferimenti a oggetti, non i valori all'interno. Ovviamente .equalsviene sovrascritto per fornire un confronto di valori anziché un confronto di riferimento di oggetti.

Integersi riferisce al riferimento, ovvero quando si confrontano i riferimenti che si stanno confrontando se puntano allo stesso oggetto, non al valore. Quindi, il problema che stai vedendo. Il motivo per cui funziona così bene con i inttipi semplici è che decomprime il valore contenuto da Integer.

Posso aggiungere che se stai facendo quello che stai facendo, perché ifiniziare la frase?

mismatch = ( cdiCt != null && cdsCt != null && !cdiCt.equals( cdsCt ) );

"==" confronta sempre la posizione della memoria o i riferimenti agli oggetti dei valori. Il metodo equals confronta sempre i valori. Ma uguale utilizza indirettamente anche l'operatore "==" per confrontare i valori.

Integer utilizza la cache Integer per memorizzare i valori da -128 a +127. Se l'operatore == viene utilizzato per verificare la presenza di valori compresi tra -128 e 127, restituisce true. per diversi da questi valori restituisce false.

Fare riferimento al collegamento per alcune informazioni aggiuntive

Inoltre, per la correttezza dell'uso ==, puoi semplicemente decomprimere uno dei Integervalori confrontati prima di fare un ==confronto, come:

if ( firstInteger.intValue() == secondInteger ) {..

Il secondo verrà automaticamente decompresso (ovviamente devi nullprima verificare la presenza di messaggi di posta elettronica).

Oltre a queste ottime risposte, quello che ho imparato è che:

MAI confrontare oggetti con == a meno che tu non intenda confrontarli con i loro riferimenti.