a Java automatikus konverziója a (, ) és azok (, ) között. Kényelmes, de rejtett buktatói vannak — teljesítménybeli többletterhelés, meglepő viselkedés és kockázat.
intdoubleIntegerDouble==NullPointerExceptionInteger boxed = 42; // autoboxing: int → Integer (Integer.valueOf(42))
int unboxed = boxed; // auto-unboxing: Integer → int (boxed.intValue())
List<Integer> nums = new ArrayList<>();
nums.add(5); // autoboxes int 5 → Integer (collections need objects)
int x = nums.get(0); // auto-unboxes Integer → int
Automatikusan megtörténik, mert a kollekciók és generikusok objektumokat igényelnek (nem lehet List<int>), így a Java transzparensen dobozol primitíveket.
Integer a = 1000;
Integer b = 1000;
a == b; // ❌ FALSE — different Integer OBJECTS (reference comparison)
a.equals(b); // ✅ true — value comparison
// the WORSE trap — the Integer cache makes small values seem to work:
Integer c = 100, d = 100;
c == d; // TRUE — Java CACHES Integers from -128 to 127 (same object)
Integer e = 200, f = 200;
e == f; // FALSE — outside the cache range → different objects
Ez tüneményes: az Integer típuson az == kis értékeknél működik (gyorsítótárazva), de nagy értékeknél meghibásodik — a tesztelésben helyesnek tűnő kód termelésben összetörik. Mindig az .equals() módszert használja a wrapper érték összehasonlításához, vagy előbb unboxolja a primitíveket.
Integer value = null; // a wrapper can be null
int x = value; // 💥 NullPointerException — unboxing null calls null.intValue()
Map<String, Integer> map = new HashMap<>();
int count = map.get("missing"); // 💥 NPE — get() returns null, then unboxing fails
A null wrapper unboxingja NPE-t dob — gyakori, meglepő összeomlás, különösen a null-t visszaadó térképkereséseknel.
// ❌ autoboxing in a hot loop — creates millions of Integer objects (GC pressure, slow)
Long sum = 0L; // WRONG type — wrapper
for (long i = 0; i < 1_000_000; i++) {
sum += i; // unbox, add, re-box → new Long each iteration!
}
// ✅ use primitives in hot paths
long sum = 0L; // primitive — no boxing
A ismételt boxolás/unboxolás túlzott számú objektumot hoz létre, ami rontja a teljesítményt szoros cikluskban.
Az autoboxing kényelmes és mindenütt jelen van (kollekciók, generikusok mind támaszkodnak rá), de buktatói valós, nehezen diagnosztizálható hibákat okoznak.
A == csapda különösen veszélyes: az Integerek ==-vel való összehasonlítása a gyorsítótárazott kis értékeknél (-128 és 127 között) működik, de nagyobb értékeknél csendesen meghibásodik — olyan hiba, amely átmegy a teszteken és termelésben összetörik — ezért az .equals() (vagy unboxolás) kötelező a wrapper összehasonlításhoz. Az NullPointerExceptionek a null wrapperek unboxingból (gyakori a térképkeresésekben) egy másik gyakori összeomlás.
A boxolás a forró cikluskban szükségtelen objektumokat hoz létre, ami rontja a teljesítményt.
Annak megértése, hogy mikor történik boxolás, az érték és referencia összehasonlítási kérdése, a null-unboxolás kockázata, valamint a primitívek használata teljesítménykritikus kódban fontos a helyes és hatékony Java írásához — az Integer-gyorsítótár == viselkedése pedig egy klasszikus interjúkérdés, amely mélyreható megértést mutat.