(, ) और उनके (, ) के बीच Java का स्वचालित रूपांतरण है। यह सुविधाजनक है लेकिन इसमें सूक्ष्म pitfalls हैं — performance overhead, आश्चर्यजनक behavior, और का जोखिम।
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
यह स्वचालित रूप से होता है क्योंकि collections और generics को objects की आवश्यकता होती है (आपके पास List<int> नहीं हो सकता), इसलिए Java primitives को transparently box करता है।
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
यह कपटी है: Integer पर == छोटे values के लिए काम करता है (cached) लेकिन बड़े values के लिए विफल हो जाता है — ऐसा code जो testing में सही लगता है production में टूट जाता है। wrapper value तुलना के लिए हमेशा .equals() का उपयोग करें, या पहले primitives में unbox करें।
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
एक null wrapper को unbox करना एक NPE फेंकता है — एक आम, आश्चर्यजनक crash, विशेष रूप से उन map lookups के साथ जो null return करते हैं।
// ❌ 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
बार-बार boxing/unboxing अत्यधिक objects बनाता है, tight loops में performance को नुकसान पहुंचाता है।
Autoboxing सुविधाजनक और व्यापक है (collections, generics सभी इस पर निर्भर करते हैं), लेकिन इसके pitfalls वास्तविक, निदान में कठिन bugs उत्पन्न करते हैं।
== trap विशेष रूप से खतरनाक है: Integers की == से तुलना cached छोटे values (-128 से 127) के लिए काम करती है लेकिन बड़े values के लिए चुपचाप विफल हो जाती है — एक bug जो tests पास करता है और production में टूट जाता है — जिससे wrapper तुलना के लिए .equals() (या unboxing) आवश्यक हो जाता है। null wrappers को unbox करने से NullPointerExceptions (map lookups के साथ आम) एक और अक्सर होने वाला crash है।
और hot loops में boxing अनावश्यक objects बनाता है, performance को नुकसान पहुंचाता है।
यह समझना कि boxing कब होती है, value-बनाम-reference तुलना का मुद्दा, null-unboxing जोखिम, और performance-critical code में primitives का उपयोग सही, efficient Java लिखने के लिए महत्वपूर्ण है — और Integer-cache == behavior एक classic interview प्रश्न है जो गहरी समझ प्रकट करता है।