Autoboxing, Unboxing, and the Integer Cache
Fast recall
Quick revision
Core answer
Whether you understand the primitive/wrapper duality, the performance implications of autoboxing, and the identity trap with cached Integer values
Using == to compare Integer objects and getting bitten when values exceed the cache range (-128 to 127), or not realizing that unboxing a null wrapper throws NullPointerException
Explain the JLS-mandated cache range, mention that you can extend the upper bound with -XX:AutoBoxCacheMax, and discuss the performance cost of autoboxing in tight loops
Interview-ready guide
Interview answer
Autoboxing is the compiler inserting Integer.valueOf() to convert int to Integer, and unboxing is inserting intValue() to go the other direction — you never see these calls in source, but they have real costs.
Integer cache trap:
Integer.valueOf()caches values from -128 to 127 and returns the same object for each- Within that range,
==works by accident — you get the cached instance - At 128+,
valueOf()creates a new heap object —==returns false even though values are equal - Always use
.equals()for wrapper comparisons — never==
Production bugs:
- Boxing in tight loops: using
Long totalinstead oflong totalcreates millions of unnecessary heap allocations - Null unboxing:
Map.get()returning null assigned tointthrowsNullPointerExceptionat the unboxing step, not inside the map — confusing to debug
I recommend using primitives by default, wrappers only when nullability is genuinely needed, and .equals() always for wrapper comparisons.
Autoboxing, Unboxing, and the Integer Cache
Direct Answer
Autoboxing is the compiler's automatic conversion from a primitive to its wrapper (int → Integer). Unboxing is the reverse (Integer → int). The Integer cache trap: Integer.valueOf() caches instances for values -128 to 127, so == works by coincidence for small values but fails for 128+. Always use .equals() for wrapper comparisons.
Deep Dive & Architecture
Varargs (`Type...
args`) = syntactic sugar — compiler converts to array.
Must be last parameter, at most one per method. Can pass 0+ args or an explicit array. Heap pollution with generics (T... args) — @SafeVarargs when provably safe. Null trap: method(null) passes as null array — args.length throws NPE. Avoid combining varargs with overloading — compiler resolution can produce surprises.
Saying Java is pass-by-reference for objects because you can modify the object's fields inside a method
Common Mistakes & Pitfalls
Using == to compare Integer objects and getting bitten when values exceed the cache range (-128 to 127), or not realizing that unboxing a null wrapper throws NullPointerException
Check your understanding
Answer these without looking back at the article.
- Is Java pass-by-value or pass-by-reference?
- Varargs in Java — Variable Arguments and Heap Pollution
- How does HashMap work internally in Java?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.