on Javan automaattinen muunnos (, ) ja niiden (, ) välillä. Se on kätevää, mutta siihen liittyy hienovaraisia sudenkuoppia — suorituskykyhaitta, yllättävä -käyttäytyminen ja -riski.
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
Se tapahtuu automaattisesti, koska kokoelmat ja generiikka vaativat objekteja (sinulla ei voi olla List<int>), joten Java wrapper primitiivejä läpinäkyvästi.
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
Tämä on petollista: == Integer-objektille toimii pienille arvoille (välimuistissa), mutta epäonnistuu suurille — koodi, joka näyttää oikealta testeissä, hajoaa tuotannossa. Käytä aina .equals() wrapper-arvojen vertailuun tai unboxaa primitiiveiksi ensin.
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
Null wrapper-objektin unboxing heittää NPE:n — tavallinen, yllättävä kaatuminen, varsinkin kartan hakujen kanssa, jotka palauttavat null.
// ❌ 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
Toistuvat boxing/unboxing-operaatiot luovat liian monta objektia, mikä heikentää suorituskykyä kireissä silmukoissa.
Autoboxing on kätevää ja kaikkialla läsnä (kokoelmat, generiikka riippuvat siitä), mutta sen sudenkuopat aiheuttavat todellisia, vaikeasti diagnosoitavia virheitä.
==-ansa on erityisen vaarallinen: Integer-objektien vertaaminen ==-operaattorilla toimii välimuistissa oleville pienille arvoille (-128–127), mutta epäonnistuu hiljaa suuremmille arvoille — virhe, joka läpäisee testit mutta hajoaa tuotannossa — tekee .equals()-metodin (tai unboxingista) oleellisen wrapper-vertailulle. NullPointerExceptions null wrapper-objektien unboxingista (yleinen kartan haulla) on toinen usein esiintyvä kaatuminen.
Ja boxing kuumissa silmukoissa luo tarpeettomia objekteja, mikä heikentää suorituskykyä.
Ymmärtäminen siitä, milloin boxing tapahtuu, arvo- ja viittaus vertailun ongelma, null-unboxing-riski ja primitiivien käyttö suorituskyvyn kannalta kriittisessä koodissa ovat tärkeitä oikean ja tehokkaan Javan kirjoittamiseen — ja Integer-välimuistin ==-käyttäytyminen on klassinen haastattelukysymys, joka paljastaa syvällistä ymmärrystä.
Kirjasto IT-haastattelukysymyksiä yksityiskohtaisine vastauksineen — Juniorista Senioriin.
Lahjoita