är Javas automatiska konvertering mellan (, ) och deras (, ). Det är bekvämt men har subtila fallgropar — prestandakostnader, överraskande -beteende och risk för .
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 händer automatiskt eftersom samlingar och generiker kräver objekt (du kan inte ha List<int>), så Java boxar primitiva typer 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
Detta är illvilligt: == på Integer fungerar för små värden (cachade) men misslyckas för större — kod som ser korrekt ut vid testning bryter i produktion. Använd alltid .equals() för jämförelse av wrapper-värden, eller unboxa till primitiva typer 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 av en null wrapper kastar en NPE — en vanlig, överraskande krasch, särskilt vid map-uppslag som returnerar 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
Upprepad boxning/unboxing skapar alltför många objekt, vilket skadar prestandan i täta loopar.
Autoboxing är bekvämt och allmänt förekommande (samlingar och generiker förlitar sig helt på det), men dess fallgropar orsakar verkliga, svårdiagnostiserade buggar.
==-fällan är särskilt farlig: jämförelse av Integer med == fungerar för cachade små värden (-128 till 127) men misslyckas tyst för större — en bugg som passerar tester och bryter i produktion — vilket gör .equals() (eller unboxing) väsentlig för jämförelse av wrapper-objekt. NullPointerExceptions från unboxing av null-wrapper (vanligt vid map-uppslag) är en annan vanlig krasch.
Och boxning i heta loopar skapar onödiga objekt, vilket skadar prestandan.
Att förstå när boxning inträffar, problemet med jämförelse av värde kontra referens, risken för null-unboxing och användningen av primitiva typer i prestationskritisk kod är viktigt för att skriva korrekt och effektiv Java — och beteendet för Integer-cache == är en klassisk intervjufråga som avslöjar djup förståelse.
Ett bibliotek med IT-intervjufrågor och detaljerade svar — från Junior till Senior.
Donera