é a conversão automática do Java entre (, ) e seus (, ). É conveniente, mas tem armadilhas sutis — overhead de performance, comportamento surpreendente com e risco de .
é a conversão automática do Java entre (, ) e seus (, ). É conveniente, mas tem armadilhas sutis — overhead de performance, comportamento surpreendente com e risco de .
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
Isso acontece automaticamente porque coleções e genéricos exigem objetos (você não pode ter List<int>), então Java encapsula primitivos transparentemente.
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
Isso é insidioso: == em Integer funciona para valores pequenos (em cache), mas falha para valores grandes — código que parece correto em testes quebra em produção. Sempre use .equals() para comparação de valores wrapper, ou desencapsule para primitivos primeiro.
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
Desencapsular um wrapper null lança uma NPE — um crash comum e surpreendente, especialmente com buscas em mapas que retornam 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
Encapsulamento/desencapsulamento repetido cria objetos excessivos, prejudicando a performance em loops apertados.
Autoboxing é conveniente e onipresente (coleções e genéricos dependem dele), mas suas armadilhas causam bugs reais e difíceis de diagnosticar.
A armadilha do == é especialmente perigosa: comparar Integers com == funciona para valores pequenos em cache (-128 a 127), mas silenciosamente falha para valores maiores — um bug que passa em testes e quebra em produção — tornando .equals() (ou desencapsulamento) essencial para comparação de wrappers. NullPointerExceptions de desencapsulamento de wrappers null (comum em buscas em mapas) são outro crash frequente.
E encapsulamento em loops quentes cria objetos desnecessários, prejudicando a performance.
Compreender quando o encapsulamento acontece, a questão de comparação valor-vs-referência, o risco de desencapsular null e usar primitivos em código crítico para performance é importante para escrever Java correto e eficiente — e o comportamento do cache de Integer com == é uma questão clássica de entrevista que revela compreensão profunda.