Optimization Techniques

Lazy initialization means you delay creating an object until the first time it is actually needed, instead of creating it up front. You use it when the object is expensive to build and might never be used.

It means don't make code faster before you know it's slow. First write clear, correct code, then measure where the real slowness is, and only optimize that part. Guessing usually wastes effort and hurts readability.

Strings in Java can't be changed, so each += makes a brand-new String by copying all the characters so far plus the new ones. Doing that every loop turn means you copy more and more text, so the total work grows much faster than the number of loops.

Integer.valueOf caches small Integer objects from -128 to 127 and reuses them. So two boxed 100s are the same object (== is true), but two boxed 1000s are different objects (== is false). Use .equals() to compare values, not ==, which compares object identity.

Pass capacity = expectedSize / 0.75 + 1, not the raw count. A HashMap resizes when it's about 75% full (the load factor), so if you pass the exact count it will still grow once you near it. Java 19+ has HashMap.newHashMap(n) that does this for you.

You put the value in a private static nested class. The JVM only loads that class the first time it is used, and class loading is automatically thread-safe, so the value is created lazily and safely without you writing any locks.

Because guesses about what's slow are usually wrong. A profiler runs your program and shows where time and memory actually go, so you fix the real hotspot instead of wasting effort on code that doesn't matter.

Use a StringBuilder: create one, call append in the loop, then toString at the end. If you know roughly how big the result will be, give the StringBuilder that size up front so it doesn't have to keep growing and copying its internal buffer.

Pre-sizing means telling a collection up front how many items you expect, via a constructor argument (e.g. new ArrayList<>(1000)). It avoids the collection having to grow and copy its internal array repeatedly as you add items, which saves time and memory churn.

Object pooling means keeping a set of reused objects instead of creating new ones each time. It is worth it only for expensive or scarce things like threads, database connections, or big buffers. For ordinary small objects, just let the garbage collector handle them.

Plain + is fine whenever you join a fixed, small number of strings in one expression and not inside a loop — like building a log message or a greeting. Use StringBuilder when you build up a string across loop iterations. String.format is for readable templated text when speed isn't critical.

Unboxing a null wrapper throws a NullPointerException. If an Integer is null and you assign it to an int, compare with ==, or do arithmetic on it, Java calls null.intValue() and crashes. Common with map lookups, nullable DB columns, and ternary expressions.

Stream<Integer> and List<Integer> store and process boxed Integer objects, allocating one per element. IntStream and primitive collections (like fastutil's IntArrayList) hold raw ints, so no wrapper objects are created and there's no per-element GC pressure.

Memory is slow, so the CPU keeps recently-used data in small fast caches, and it loads memory in chunks (cache lines). Reading an array in order uses each loaded chunk fully and lets the CPU prefetch the next, so it's fast. Random jumps or pointer-chasing keep missing the cache and waiting on slow memory.

Modern CPUs guess which way an if/branch will go before they know, to keep working ahead. With sorted data the pattern is regular so guesses are right; with random data guesses miss often, and each wrong guess wastes work, so the same loop runs slower.

When an ArrayList's backing array is full and you add one more element, it creates a new array about 1.5x larger, copies all existing elements over, and discards the old array. Building a big list from the default capacity (10) triggers many such grow-and-copy cycles; pre-sizing does the allocation once.

Escape analysis is a JIT compiler technique that figures out whether an object created in a method stays inside that method. If it never "escapes," the compiler can avoid allocating it on the heap, which removes work and garbage collection pressure.

Pooled objects can carry over old data if you forget to reset them, leak if you never return them, or get corrupted if two callers use the same one. The pool also needs locking, which can be slower than just creating objects, and it keeps objects alive so the GC moves them to the slower old generation.

Threads and connections are very expensive to create and limited in number, so reusing them saves real time and protects a scarce resource. Ordinary objects are cheap to create and the GC cleans them up almost for free, so reusing them adds cost without saving much.

A better algorithm (e.g. O(n log n) instead of O(n²)) scales far better than tiny tweaks as data grows. The 80/20 rule says most time is spent in a small part of the code, so fix that part first.

Java runs an interpreter first, then a JIT compiler turns hot loops into optimized machine code. It automatically unrolls loops and removes most array bounds checks. Because it does this for you using runtime profiling, hand-unrolling usually just makes code uglier without helping, or even blocks the JIT's own optimizations.

Pre-sizing only helps when the final size is known and the code is hot. If sizes are small, the path is cold, or the size is unknown, the constructor argument adds clutter without measurable benefit — and a bad over-estimate wastes memory. Measure first; apply it on proven hot, known-size build paths.

NoEscape means the object stays inside the method. ArgEscape means it is only handed to another method it calls. GlobalEscape means it leaks out — for example by being returned or stored in a field — so the JVM can no longer optimize away its allocation.

Scalar replacement means the JIT takes a non-escaping object and replaces it with its individual fields, held in CPU registers or on the stack, so the object is never actually created. There is no heap memory and nothing for the garbage collector to clean up, so the object costs almost nothing.

Double-checked locking checks a field for null without a lock, and only locks and builds the object if it's still null. Before Java 5 it could hand back a half-built object because writes could be reordered. Marking the field volatile prevents that reordering and makes the fix work.

You wrap the expensive computation in a Supplier and cache its result the first time it's called, so later calls return the cached value. Helpers like ConcurrentHashMap.computeIfAbsent or a memoizing Supplier make this thread-safe and let you parameterize or reset it, which the holder idiom can't.

Each thread gets its own slice of memory (a TLAB) so creating an object is just moving a pointer, with no locking. The JIT can also notice an object never leaves a method (escape analysis) and skip the heap entirely. Both make allocation so cheap that pooling plain objects rarely helps.

The JVM's JIT compiler turns hot code into fast native code (inlining, removing dead code, optimizing loops), and the garbage collector cheaply reclaims short-lived objects. So many manual tweaks are unnecessary — measure first; only hand-optimize what the JVM provably doesn't handle.

The compiler turns one concatenation expression (like a + b + c) into a single efficient operation, so plain + outside loops is fast. But in a loop, each += is its own separate step that depends on the previous turn's result, so the compiler can't merge them into one builder for you.