DEV Community: Md Marzukul Islam

Understanding Integer Caching in Java, The Hidden Optimization You Might’ve Missed

Md Marzukul Islam — Mon, 10 Nov 2025 10:03:59 +0000

Ever wondered why sometimes two seemingly identical Integer objects in Java are actually the same object in memory, and sometimes they aren’t?

Welcome to the fascinating world of Integer Caching, a small but clever optimization built right into the Java Virtual Machine (JVM) that quietly boosts performance and saves memory.

What Is `Integer Caching`?

In Java, objects like Integer, Long, Byte, and Character are immutable wrapper classes around primitive types. Whenever you use autoboxing, such as:

    Integer a = 100;  // autoboxing of int to Integer

the JVM doesn’t always create a new Integer object. Instead, it might reuse an existing one, thanks to Integer caching.

How It Works

By default, Java maintains a cache of Integer objects for values between -128 and +127.

So when you write:

    Integer x = 100;
    Integer y = 100;
    System.out.println(x == y);  // true

Both x and y refer to the same cached object from the JVM’s internal pool.

However, when you go beyond this range:

    Integer p = 128;
    Integer q = 128;
    System.out.println(p == q);  // false

Each value gets a new Integer object, since 128 is outside the default cache range.

Why -128 to 127?

This range was chosen because:

These values are commonly used (especially in loops, small counters, array indexes, etc.).
-128 to 127 fits neatly within a single byte (Byte range).

This small range gives a big payoff, fewer object allocations and faster comparisons for the most frequently used numbers.

JVM Customization For Caching Range

The upper limit of the cache can actually be customized!

You can modify it using the JVM option:

    -Djava.lang.Integer.IntegerCache.high=<value>

For example, if your application heavily uses numbers up to 1000, you could extend the cache like this:

    -Djava.lang.Integer.IntegerCache.high=1000

A Common Pitfall

It’s important to remember that == compares object references, not values.

That’s why you might see confusing results:

    Integer a = 100;
    Integer b = 100;
    System.out.println(a == b); // true (cached)

    Integer c = 128;
    Integer d = 128;
    System.out.println(c == d); // false (not cached)

When comparing numeric values, always use .equals() instead:

    System.out.println(c.equals(d)); // true

A Tiny Decimal That Caused Big Trouble, Until I Learned About BigDecimal

Md Marzukul Islam — Mon, 03 Nov 2025 07:02:35 +0000

If you’ve ever wondered why developers always say “never use double for money”, here’s the real reason, and why BigDecimal solves the problem perfectly.

1. The Root Cause: `Binary` VS `Decimal` Representation

A double in Java uses IEEE 754 binary floating point, meaning it represents numbers as sums of powers of 2, not 10.

That works fine for many numbers, but not for decimals like 0.1 or 0.2, because they can’t be represented exactly in binary.
They become repeating binary fractions:

    0.1₁₀ = 0.0001100110011001100...₂ (infinite)

So this simple code:

    System.out.println(0.1 + 0.2);

prints:

    0.30000000000000004

That tiny error is a rounding artifact, and in finance or accounting, it’s unacceptable.

2. How `BigDecimal` Fixes It

BigDecimal doesn’t use floating-point math at all.
Internally, it stores two things:

    BigInteger intVal;  // exact integer value
    int scale;          // how many digits after the decimal point

For example:

    BigDecimal x = new BigDecimal("123.45");

is stored as:

    intVal = 12345
    scale  = 2
    value  = 12345 × 10^-2 = 123.45

Which is 100% exact, no rounding errors.

That’s because:

BigInteger holds whole numbers precisely in binary.
The scale simply shifts the decimal point in base 10.

3. Why `BigDecimal` Is Perfect for Money

Money works in decimal, not binary.

BigDecimal uses decimal arithmetic, so values like 0.1, 19.99, or 123456.78 are stored and calculated exactly as written, no binary drift, no rounding surprises.

Yes, it’s slower than double, but it’s correct and correctness is what matters in financial systems.