er Javas automatiske konvertering mellem (, ) og deres (, ). Det er praktisk, men har subtile faldgruber — ydeelsesoverhead, overraskende -adfærd og risiko for .
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
Det sker automatisk, fordi collections og generics kræver objekter (du kan ikke have List<int>), så Java boxer primitiver transparent.
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
Dette er lumsk: == på Integer virker for små værdier (cachede), men fejler for store — kode, der ser korrekt ud i tests, bryder i produktion. Brug altid .equals() til wrapper-værdisammenligning, eller unbox til primitiver først.
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
Unboxing af null wrapper kaster en NPE — et almindeligt, overraskende nedbrud, især med map-opslag, der returnerer 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
Gentagen boxing/unboxing skaber overdrevne objekter, hvilket skader ydeelsen i stramme løkker.
Autoboxing er praktisk og allestedsnærværende (collections, generics er afhængige af det), men dets faldgruber forårsager virkelige, svært diagnosticerbare fejl.
==-fælden er særlig farlig: sammenligning af Integer med == virker for cachede små værdier (-128 til 127), men fejler stille for større — en fejl, der består tests og bryder i produktion — gør .equals() (eller unboxing) essentiel til wrapper-sammenligning. NullPointerExceptions fra unboxing af null wrappers (almindelig med map-opslag) er et andet hyppigt nedbrud.
Og boxing i hot loops skaber unødvendige objekter, hvilket skader ydeelsen.
At forstå hvornår boxing sker, værdier-mod-reference-sammenligningsproblem, null-unboxing-risiko og brugen af primitiver i ydelelseskritisk kode er vigtig for at skrive korrekt, effektiv Java — og Integer-cache ==-adfærd er et klassisk interviewspørgsmål, der afslører dyb forståelse.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér