Boxing will frequently create objects, increasing memory overhead and GC pressure; 2. The cache is only valid for small-scale values such as Integer between -128 and 127, and objects will still be created in large quantities after they are exceeded; 3. Null value checks are required when unboxing, which may cause NullPointerException and bring additional performance losses; 4. The use of wrapper classes in the collection will cause frequent boxing and unboxing during traversal and calculation, affecting the locality of the CPU cache; priority should be given to using native collection libraries such as basic type arrays or FastUtil to reduce performance overhead and avoid implicit type conversion in hotspot code.

Although Java's autoboxing and unboxing make conversion between basic types and corresponding packaging classes more convenient, they may bring overhead that cannot be ignored in performance-sensitive scenarios. Understanding these performance impacts can help write more efficient and stable code.

1. Object creation overhead and memory pressure

The boxing operation converts the primitive type (such as int ) to the corresponding wrapper class object (such as Integer ), which means that each time the boxing is a new object on the heap (unless you use a cached value, see below).

 List<Integer> list = new ArrayList<>();
for (int i = 0; i < 100000; i ) {
    list.add(i); // Automatic boxing: int → Integer
}

In the above loop, each add(i) will trigger a boxing, generating 100,000 Integer objects. These objects:

• Takes up more memory (object header, alignment padding, etc.)
• Increased GC pressure, which may lead to more frequent garbage collections
• Object allocation itself also has CPU overhead

In contrast, using primitive arrays or int[] , or specialized primitive collection libraries (such as Eclipse Collections, Trove, FastUtil) can avoid these overheads.

2. Limitations of the cache mechanism

Java caches objects within a certain range for some wrapper classes (such as Integer ). For example, Integer.valueOf(int) returns a cache object for values between -128 and 127:

 Integer a = 127;
Integer b = 127;
System.out.println(a == b); // true (cache object)

Integer c = 128;
Integer d = 128;
System.out.println(c == d); // false (new object)

Although this cache reduces duplicate creation of small integers,

• Only available for Integer , Short , Byte , Character , Long
• Using new Integer(100) will bypass the cache and create new objects directly
• Once the cache range is exceeded, objects will still be created frequently, and the performance will be significantly reduced.

Therefore, the dependency on cache cannot be completely avoided by object overhead.

3. Unboxing empty pointer risk and performance loss

If the wrapper class object is null when unboxing, NullPointerException will be thrown:

 Integer value = null;
int x = value; // Throw NullPointerException

This is not only a runtime risk, the JVM must insert a null value check when unboxing, bringing additional runtime overhead. In hotspot code, this implicit check accumulates into considerable performance losses.

Additionally, frequent packing/unboxing mixing operations (such as in a loop) can result in:

• Repeatedly create and discard objects
• More memory reading and writing
• Poor CPU cache locality

4. Performance traps in collections and generics

Java collection frameworks (such as ArrayList , HashMap ) can only store objects, so it is inevitable to use wrapper classes such as Integer , Double , etc. But this also means:

• All basic elements must be packed
• Unboxing again during traversal
• High-frequency operation (such as numerical calculations, accumulation) performance has significantly decreased

For example:

 List<Integer> nums = Arrays.asList(1, 2, 3, 4, 5);
int sum = 0;
for (Integer num : nums) {
    sum = num; // every time = triggers unboxing}

Here, every time num is used, it must be unboxed. If the data volume is large, this overhead cannot be ignored.

How to optimize?

• Avoid boxing/unboxing in loops : Try to handle type conversion outside the loop
• Use primitive arrays : such as int[] instead of Integer[]
• Use proprietary collection libraries : For example, FastUtil and Trove provide primitive types such as IntList and DoubleArrayList to avoid wrapping classes
• Use Integer , etc. carefully as variable types that are frequently calculated
• On performance critical paths, prioritize long over Long , double over Double

Summarize

Boxing and unboxing improve the simplicity of the code, but at the cost:

• Additional object creation and memory overhead
• Increase GC pressure
• Potential null pointer exception
• Increased CPU instructions (empty check, object access)

In high concurrency, large data volume or low latency scenarios, unnecessary packing and unboxing operations should be minimized. Understanding the mechanism behind it helps to make a reasonable trade-off between convenience and performance.

Basically all this is not complicated but easy to ignore.

The above is the detailed content of Performance Implications of Java Boxing and Unboxing. For more information, please follow other related articles on the PHP Chinese website!