autoboxing কি এবং এর ত্রুটিগুলি কী কী?

Question

Accepted Answer

**Autoboxing** হল Java-এর **primitives** (`int`, `double`) এবং তাদের **wrapper objects** (`Integer`, `Double`) এর মধ্যে স্বয়ংক্রিয় রূপান্তর। এটি সুবিধাজনক কিন্তু সূক্ষ্ম ত্রুটি রয়েছে — কর্মক্ষমতা overhead, আশ্চর্যজনক `==` আচরণ এবং `NullPointerException` ঝুঁকি। ## Autoboxing এবং 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 ``` এটি স্বয়ংক্রিয়ভাবে ঘটে কারণ collections এবং generics objects প্রয়োজন (আপনি `List` রাখতে পারবেন না), তাই Java স্বচ্ছভাবে primitives বক্সিং করে। ## ত্রুটি 1: == wrapper এর জন্য রেফারেন্স তুলনা করে, মান নয় ```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 ``` এটি ছলাকলাপূর্ণ: ছোট মান (ক্যাশ করা) এর জন্য `Integer` এ `==` কাজ করে কিন্তু **বড় মানের জন্য ব্যর্থ হয়** — টেস্টিংয়ে সঠিক বলে মনে হওয়া কোড production-এ ভেঙে পড়ে। wrapper মান তুলনার জন্য সর্বদা `.equals()` ব্যবহার করুন, অথবা প্রথমে primitives এ আনবক্স করুন। ## ত্রুটি 2: unboxing-এ NullPointerException ```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 ``` নালল wrapper আনবক্স করা একটি NPE নিক্ষেপ করে — একটি সাধারণ, আশ্চর্যজনক ক্র্যাশ, বিশেষত map lookups এর সাথে যা null রিটার্ন করে। ## ত্রুটি 3: কর্মক্ষমতা overhead ```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 ``` বারবার boxing/unboxing অত্যধিক objects তৈরি করে, tight loops-এ কর্মক্ষমতা হানি করে। ## এটি গুরুত্বপূর্ণ কেন Autoboxing সুবিধাজনক এবং সর্বব্যাপী (collections, generics সবই এটির উপর নির্ভর করে), কিন্তু এর ত্রুটিগুলি বাস্তব, কঠিন-নির্ণয়যোগ্য বাগ সৃষ্টি করে। **`==` ফাঁদ** বিশেষভাবে বিপজ্জনক: `Integer` তুলনা `==` দিয়ে ক্যাশ করা ছোট মানের জন্য কাজ করে (-128 থেকে 127) কিন্তু বড় মানের জন্য নিঃশব্দে ব্যর্থ হয় — একটি বাগ যা টেস্ট পাস করে এবং production-এ ভেঙে পড়ে — wrapper তুলনার জন্য `.equals()` (বা unboxing) অপরিহার্য করে তোলে। null wrappers আনবক্স করা থেকে **NullPointerExceptions** (map lookups এর সাথে সাধারণ) আরেকটি ঘন ঘন ক্র্যাশ। এবং **hot loops** এ boxing অপ্রয়োজনীয় objects তৈরি করে, কর্মক্ষমতা হানি করে। কখন boxing ঘটে বুঝা, মান-বনাম-রেফারেন্স তুলনা সমস্যা, null-unboxing ঝুঁকি এবং কর্মক্ষমতা-সমালোচনামূলক কোডে primitives ব্যবহার করা সঠিক, দক্ষ Java লেখার জন্য গুরুত্বপূর্ণ — এবং Integer-cache `==` আচরণ একটি ক্লাসিক সাক্ষাৎকার প্রশ্ন যা গভীর বোঝাপড়া প্রকাশ করে।