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 پر == چھوٹی قدریوں کے لیے کام کرتا ہے (cached) لیکن بڑی قدریوں کے لیے ناکام ہوتا ہے — وہ کوڈ جو ٹیسٹنگ میں صحیح لگتا ہے production میں ٹوٹ جاتا ہے۔ 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 بنتے ہیں، جو tight loops میں کارکردگی کو نقصان پہنچاتے ہیں۔
Autoboxing سہل اور پھیلا ہوا ہے (collections، generics سب اس پر منحصر ہیں)، لیکن اس کے نقصانات حقیقی، تشخیص میں مشکل bugs کا سبب بنتے ہیں۔
== کا پھندا خاص طور پر خطرناک ہے: Integer کا == سے موازنہ cached چھوٹی قدریوں (-128 سے 127) کے لیے کام کرتا ہے لیکن بڑی قدریوں کے لیے خاموشی سے ناکام ہوتا ہے — ایک bug جو ٹیسٹ میں پاس ہوتا ہے اور production میں ٹوٹتا ہے — wrapper موازنے کے لیے .equals() (یا unboxing) ضروری بناتا ہے۔ NullPointerExceptions null wrappers کو unbox کرنے سے (عام طور پر map lookups کے ساتھ) ایک اور عام خرابی ہے۔
اور hot loops میں boxing سے غیر ضروری objects بنتے ہیں، جو کارکردگی کو نقصان پہنچاتا ہے۔
یہ سمجھنا کہ boxing کب ہوتی ہے، value-vs-reference موازنے کا مسئلہ، null-unboxing کا خطرہ، اور کارکردگی سے متعلقہ کوڈ میں primitives استعمال کرنا صحیح، موثر Java لکھنے کے لیے اہم ہے — اور Integer-cache == رویہ ایک کلاسیک انٹرویو سوال ہے جو گہری سمجھ کا مظہر ہے۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں