Wie in Punkt 6 erwähnt, ist der Unterschied zwischen dem primitiven Typ (im Folgenden "primitiv") und dem primitiven Typ (im Folgenden "primitiv") aufgrund des automatischen Boxens und des automatischen Entpackens nicht eindeutig. Es gibt jedoch Unterschiede zwischen den beiden, und Sie müssen sich der Unterschiede bewusst sein, wenn Sie sie verwenden. Es gibt drei Unterschiede
Auf den ersten Blick sieht der folgende Code wie eine Methode aus, die einen guten Vergleich ermöglicht.
// Broken comparator - can you spot the flaw?
Comparator<Integer> naturalOrder =
(i, j) -> (i < j) ? -1 : (i == j ? 0 : 1);
Wenn Sie diese Methode jedoch wie `` naturalOrder.compare (neue Ganzzahl (42), neue Ganzzahl (42)) `verwenden, sollte sie 0 zurückgeben, da sie gleich sein soll, aber tatsächlich 1 zurückgibt. ..
Das erste Urteil (i <j) wird automatisch entpackt und funktioniert korrekt.
Andererseits betrachtet das zweite Urteil (i == j) den gleichen Wert, dh ob die Referenzen gleich sind. Daher ist dieser Vergleich nicht wahr und 1 wird als Ergebnis zurückgegeben. Es ist normalerweise falsch, den Operator == für Grundelemente mit Kästchen zu verwenden.
Um den obigen Fehler zu vermeiden, verwenden Sie `Comparator.naturalOrder ()` oder führen Sie einen primitiven Vergleich wie folgt durch, wenn Sie einen eigenen Vergleicher schreiben.
Comparator<Integer> naturalOrder = (iBoxed, jBoxed) -> {
int i = iBoxed, j = jBoxed; // Auto-unboxing
return i < j ? -1 : (i == j ? 0 : 1);
};
Im folgenden Programm tritt nullpo auf.
package tryAny.effectiveJava;
public class BoxedPrimitive {
static Integer i;
public static void main(String[] args) {
if (i == 42)
System.out.println("Unbelievable");
}
}
Bei i == 47 werden Integer und int verglichen. In einem Prozess, in dem Boxed Primitive und Primitive gemischt werden, ** wird Boxed Primitive in den meisten Fällen automatisch entpackt. ** ** ** Das Entpacken eines Objekts, das auf null verweist, führt zu nullpo, was hier geschieht.
Das folgende Programm wird in Punkt 6 behandelt.
package tryAny.effectiveJava;
public class BoxedPrimitive2 {
// Hideously slow program! Can you spot the object creation?
public static void main(String[] args) {
Long sum = 0L;
for (long i = 0; i < Integer.MAX_VALUE; i++) {
sum += i;
}
System.out.println(sum);
}
}
Dies ist viel langsamer als wenn der lokale Variablentyp auf long eingestellt ist, da das Ein- und Auspacken wiederholt erfolgt.
Es gab drei Probleme, die ersten beiden hatten schlechte Ergebnisse und das letzte hatte eine schlechte Leistung.
Bei Verwendung des umrahmten Grundelements gibt es die folgenden Fälle.
`ThreadLocal <int>` `nicht deklarieren, aber Sie können` ThreadLocal Recommended Posts