Java ਦਾ (, ) ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ (, ) ਵਿਚਕਾਰ ਸਵੈਚਲਿਤ ਪਰਿਵਰਤਨ ਹੈ। ਇਹ ਸੁਵਿਧਾਜਨਕ ਹੈ ਪਰ ਵਿਸਤ੍ਰਿਤ ਨੁਕਸਾਨ ਹਨ — performance ਓਵਰਹੈੱਡ, ਅਚਨਚੇਤ ਵਿਵਹਾਰ, ਅਤੇ ਦਾ ਜੋਖਮ।
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 ਖਿੰਡੋ ਦਿੰਦਾ ਹੈ — ਇੱਕ ਆਮ, ਅਚਨਚੇਤ crash, ਖਾਸ ਕਰ ਕੇ 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 ਬਣਾਉਂਦਾ ਹੈ, ਤੰਗ ਲੂਪਾਂ ਵਿਚ performance ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ।
ਆਟੋਬਾਕਸਿੰਗ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਵਿਆਪਕ ਹੈ (collections, generics ਸਭ ਇਸ ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ), ਪਰ ਇਸਦੇ ਨੁਕਸਾਨ ਅਸਲ, ਮੁਸ਼ਕਲ-ਨਿਸ਼ਾਨ ਲਗਾਉਣ ਵਾਲੀਆਂ ਖਰਾਬੀਆਂ ਪੈਦਾ ਕਰਦੇ ਹਨ।
== trap ਖਾਸ ਤੌਰ ਤੇ ਖਤਰਨਾਕ ਹੈ: Integer ਦਾ == ਨਾਲ ਤੁਲਨਾ ਕੈਸ਼ ਕੀਤੀਆਂ ਛੋਟੀਆਂ ਕੀਮਤਾਂ (-128 ਤੋਂ 127) ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਵੱਡਿਆਂ ਲਈ ਖਮੋਸ਼ੀ ਨਾਲ ਅਸਫਲ ਹੁੰਦਾ ਹੈ — ਇੱਕ ਖਰਾਬੀ ਜੋ ਟੈਸਟ ਪਾਸ ਕਰਦਾ ਹੈ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਟੁੱਟ ਜਾਂਦਾ ਹੈ — wrapper ਤੁਲਨਾ ਲਈ .equals() (ਜਾਂ unboxing) ਜ਼ਰੂਰੀ ਬਣਾਉਂਦਾ ਹੈ। NullPointerExceptions null wrappers ਤੋਂ unboxing ਕਰਨਾ (map lookups ਨਾਲ ਆਮ) ਇੱਕ ਹੋਰ ਵਾਰ-ਵਾਰ crash ਹੈ।
ਅਤੇ hot loops ਵਿੱਚ boxing ਬੇਲੋੜੀਆਂ objects ਬਣਾਉਂਦਾ ਹੈ, performance ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ।
ਸਮਝਣਾ ਕਿ boxing ਕਦੋਂ ਹੁੰਦਾ ਹੈ, value-vs-reference ਤੁਲਨਾ ਮੁੱਦਾ, null-unboxing ਜੋਖਮ, ਅਤੇ performance-critical ਕੋਡ ਵਿੱਚ primitives ਦੀ ਵਰਤੋਂ ਸਹੀ, ਮਾਹਰ Java ਲਿਖਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ — ਅਤੇ Integer-cache == ਵਿਵਹਾਰ ਇੱਕ ਨਿਰਲੀ interview ਸਵਾਲ ਹੈ ਜੋ ਗਹਰੀ ਸਮਝ ਦੀ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ