हे Java चे (, ) आणि त्यांच्या (, ) यांच्यातील स्वयंचलित रूपांतरण आहे. हे सुविधाजनक आहे परंतु त्यामध्ये सूक्ष्म नुकसान आहेत — कार्यक्षमता ओव्हरहेड, आश्चर्यकारक वर्तन, आणि जोखीम.
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 ला पारदर्शकपणे 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 वर == काम करते (कॅश केलेले), परंतु मोठ्या मूल्यांसाठी अयशस्वी होते — चाचणीमध्ये योग्य असलेला कोड उत्पादनात खंडित होतो. Wrapper मूल्य तुलनासाठी नेहमी .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 फेकते — एक सामान्य, आश्चर्यकारक क्रॅश, विशेषत: map lookups सह जे 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
वारंवार boxing/unboxing अत्यधिक objects निर्माण करते, घट्ट loops मध्ये कार्यक्षमता दुखापत करते.
Autoboxing सुविधाजनक आणि व्यापक आहे (collections, generics सब त्यावर अवलंबून आहेत), परंतु त्याचे नुकसान वास्तविक, निदान करणे कठिण bugs निर्माण करते.
== जाळ्या विशेषत: धोकादायक आहे: Integer सह == ने तुलना केल्याने कॅश केलेल्या लहान मूल्यांसाठी (-128 ते 127) काम करते परंतु मोठ्या मूल्यांसाठी शांतपणे अयशस्वी होते — एक bug जो tests पास करतो आणि उत्पादनात खंडित होतो — wrapper तुलनासाठी .equals() (किंवा unboxing) आवश्यक बनवते. Null wrapper (map lookups सह सामान्य) ला unbox करून येणारे NullPointerExceptions हा आणखी एक वारंवार क्रॅश आहे.
आणि गरम loops मध्ये boxing अनावश्यक objects निर्माण करते, कार्यक्षमता दुखापत करते.
Boxing कधी घडते, value-vs-reference तुलना समस्या, null-unboxing जोखीम, आणि कार्यक्षमता-महत्वाच्या कोडमध्ये primitives वापरणे समजून घेणे योग्य, कार्यक्षम Java लिहिण्यासाठी महत्वाचे आहे — आणि Integer-cache == वर्तन ही एक शास्त्रीय मुलाखत प्रश्न आहे जी खोल समज प्रकट करते.