Optimization Techniques

Look for += String building inside the loop — that's almost certainly the culprit, because it copies everything each turn (O(n^2)). Replace it with a StringBuilder (append in the loop, toString once), pre-size it if you can estimate the length, and re-profile to confirm the time and garbage dropped.

Eager init is slower to start but every request is fast and predictable; lazy init starts faster but the first user of each lazy thing pays a latency spike. Choose eager for things always needed or latency-sensitive, lazy for rarely-used expensive things, and warm up critical paths to hide the spike.

Every optimization that makes code harder to read or change has a cost you pay forever. Only accept it when measurement shows a meaningful, needed gain on a real hotspot — and document why, so future readers don't "simplify" it back.

Don't guess — profile. Check allocation rate and GC time; if boxed wrappers dominate, optimize the hot path with primitives or primitive collections. For cold or rarely-run code, leave the readable boxed version. Project Valhalla aims to let value/primitive classes remove much of this cost in the future.

Streams usually can't pre-size their result because the element count isn't known until the stream finishes — collectors append into a default-capacity collection that grows as usual. If you know the size and it's a hot path, build the collection manually with a pre-sized constructor, or use a collector supplier that creates a pre-sized container.

Lock elision is when the JIT removes the locking from a synchronized block because escape analysis proves the lock object can only ever be touched by one thread. If no other thread can see the object, the lock protects nothing, so it is safe to delete.

Almost never by default — write simple, predictable loops and let the JIT and CPU optimize. Only after a profiler proves a specific hot loop is the bottleneck, and only if simpler fixes (better algorithm or data structure) don't suffice, should you reshape data, go branchless, or use the Vector API — then re-measure to confirm it actually helped.

Escape analysis only optimizes objects it can prove never leave a method. Returning the object, storing it in a field, or passing it to a method the JIT can't see into all make it escape. It also depends on inlining, so anything that prevents inlining indirectly defeats it.

First measure: profile allocation and GC to confirm object creation is actually a problem. Only pool if the object is expensive to make or scarce, like threads, connections, or big buffers. For ordinary objects, prefer letting the GC work. If you do pool, use a proven library, not hand-rolled code.