Vad är autoboxing och vilka är dess fallgropar?

Question

Accepted Answer

**Autoboxing** är Javas automatiska konvertering mellan **primitiva typer** (`int`, `double`) och deras **wrapper-objekt** (`Integer`, `Double`). Det är bekvämt men har subtila fallgropar — prestandakostnader, överraskande `==`-beteende och risk för `NullPointerException`. ## Autoboxing och unboxing ```java Integer boxed = 42; // autoboxing: int → Integer (Integer.valueOf(42)) int unboxed = boxed; // auto-unboxing: Integer → int (boxed.intValue()) List 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`), så Java boxar primitiva typer transparent. ## Fallgrop 1: == jämför referenser, inte värden, för wrapper-objekt ```java 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. ## Fallgrop 2: NullPointerException vid unboxing ```java Integer value = null; // a wrapper can be null int x = value; // 💥 NullPointerException — unboxing null calls null.intValue() Map 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. ## Fallgrop 3: prestandakostnader ```java // ❌ 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. ## Varför det spelar roll 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.