est la conversion automatique de Java entre les (, ) et leurs (, ). C'est pratique mais comporte des pièges subtils — surcharge de performance, comportement surprenant de , et risque 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
Cela se produit automatiquement car les collections et les génériques nécessitent des objets (on ne peut pas avoir List<int>), donc Java encapsule les primitives de manière transparente.
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
C'est insidieux : == sur Integer fonctionne pour les petites valeurs (en cache) mais échoue pour les grandes — du code qui semble correct en test se casse en production. Utilisez toujours .equals() pour comparer les valeurs des wrappers, ou déboîtez d'abord les primitives.
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
Déboîter un wrapper null lève une NPE — un crash courant et surprenant, particulièrement avec les recherches dans des maps qui retournent 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
Le boxing/unboxing répété crée des objets excessifs, nuisant à la performance dans les boucles serrées.
L'autoboxing est pratique et omniprésent (les collections, les génériques en dépendent tous), mais ses pièges causent de vrais bugs difficiles à diagnostiquer.
Le piège == est particulièrement dangereux : comparer des Integers avec == fonctionne pour les petites valeurs en cache (-128 à 127) mais échoue silencieusement pour les plus grandes — un bug qui passe les tests et se casse en production — rendant .equals() (ou le déboîtage) essentiel pour la comparaison des wrappers. Les NullPointerExceptions provenant du unboxing de wrappers null (courant avec les recherches dans des maps) sont un autre crash fréquent.
Et le boxing dans les boucles critiques crée des objets inutiles, nuisant à la performance.
Comprendre quand le boxing se produit, le problème de comparaison valeur-vs-référence, le risque du unboxing null, et utiliser les primitives dans le code critique pour la performance est important pour écrire du Java correct et efficace — et le comportement == du cache Integer est une question classique d'entretien qui révèle une compréhension profonde.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don