Primitive Typen vs. Gepackte primitive Typen

• Primitive Typen: int, double, boolean usw.
• Gepackte primitive Typen: Ganzzahl, Doppelt, Boolesch usw.
• Java hat ein doppeltes Typsystem: primitive Typen und Referenztypen (Objekte).
• Jeder primitive Typ hat eine entsprechende Wrapper-Klasse.

Hauptunterschiede

• Identität vs. Wert:
  Primitive: Sie haben keine Identität; Zwei Grundelemente mit demselben Wert sind immer gleich.
  Verpackt: Sie sind Objekte und haben eine Identität; Zwei Objekte können den gleichen Wert, aber unterschiedliche Identitäten haben.

• Nullwerte:
  Primitive: Haben immer einen Standardwert (z. B. 0 für int).
  Gepackt: Kann null sein, was bei unsachgemäßer Behandlung zu NullPointerException-Ausnahmen führen kann.

• Leistung:
  Primitive: Effizienter in Bezug auf Zeit und Raum.
  Verpackt: Führt zu Mehraufwand aufgrund der Erstellung zusätzlicher Objekte.

Häufige Probleme beim Mischen von Grundelementen und Paketen

• 1. Identität statt Wertevergleich
• Wenn Sie mit == gepackte Objekte vergleichen, vergleichen Sie Objektreferenzen, nicht die Werte. Dies kann zu unerwarteten Ergebnissen führen.

Problematisches Beispiel:

Comparator naturalOrder = (i, j) -> (i 



Problem: Vergleich i == j vergleicht Referenzen, keine Werte.

Falsches Verhalten: naturalOrder.compare(new Integer(42), new Integer(42)) gibt 1 statt 0 zurück.

Lösung:

Verwenden Sie die Methode „compareTo“ oder Hilfsmethoden der Klasse „Integer.
“.


Comparator naturalOrder = Integer::compare;





Oder, Korrektur des ursprünglichen Komparators:


Comparator naturalOrder = (iBoxed, jBoxed) -> {
    int i = iBoxed;
    int j = jBoxed;
    return (i 



2. Autounboxing und NullPointerException

Wenn gepackte Typen verwendet werden, die null sein können, kann das automatische Unboxing Ausnahmen auslösen, wenn das Objekt null ist.

Problematisches Beispiel:


Integer i = null;
if (i == 42) {
    System.out.println("Inacreditável");
}





Problem: i ist null; Beim Vergleich mit 42 kommt es zu einem Null-Autounboxing, was zu einer NullPointerException führt.
Lösung: Verwenden Sie nach Möglichkeit primitive Typen.


int i = 0;
if (i == 42) {
    System.out.println("Inacreditável");
}





3. Beeinträchtigte Leistung aufgrund von Autoboxing/Unboxing

Die versehentliche Verwendung umschlossener Typen bei intensiven Vorgängen kann aufgrund von Autoboxing und unnötiger Objekterstellung zu Leistungseinbußen führen.

Problematisches Beispiel:


Long sum = 0L;
for (long i = 0; i 



Problem: Summe ist ein gepackter Long; In jeder Iteration findet Autoboxing/Unboxing statt.

Auswirkung: Viel langsamerer Code und übermäßige Speichernutzung.
Lösung:

Verwenden Sie primitive Typen für lokale Variablen in intensiven Operationen.


long sum = 0L;
for (long i = 0; i 



Wann werden gepackte Typen verwendet?

Sammlungen: Sie können keine primitiven Typen in generischen Sammlungen (z. B. Liste) verwenden.
Generische Parameter: Generische Typen unterstützen keine primitiven Typen (z. B. ThreadLocal).
APIs, die Objekte erfordern: Bestimmte APIs erfordern Objekte anstelle von primitiven Typen.
Gute Praktiken

Primitive Typen bevorzugen: Verwenden Sie nach Möglichkeit primitive Typen aus Gründen der Einfachheit und Effizienz.
Vorsicht vor Autoboxing/Unboxing: Autoboxing reduziert die Ausführlichkeit, kann aber zu subtilen Fehlern führen.
Vergleiche mit == in Wrapped vermeiden: Verwenden Sie Methoden wie equal() oder vergleichen Sie die unverpackten Werte.
Auf Nullen prüfen: Beachten Sie beim Arbeiten mit gepackten Typen, dass diese null sein und eine NullPointerException verursachen können.
Zusammenfassung
Primitive Typen:

Einfacher und schneller.

Sie dürfen nicht null sein.

Sie haben keine Identität (nur Wert).

Gepackte Typen:

Erforderlich für die Verwendung in Sammlungen und generischen APIs.

Sie können null sein.

Sie haben Objektidentität.