JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 307 contents

https://www.youtube.com/watch?v=BNwJkrWezoo
The Next Evolution of Java: Achieving Hyper Performance and Efficiency in Cloud Native Workloads (Page last updated May 2026, Added 2026-06-28, Author Daniel Oh, Publisher Devoxx). Tips:

• Optimize Java for cloud native workloads by targeting fast startup, low memory use, and small container images.
• Don't just lift-and-shift large monoliths into Kubernetes; containerization often requires refactoring runtime, data, connection, and session design.
• Tune Kubernetes readiness and liveness probes carefully so slow-starting JVM apps are not killed before they become ready.
• Use frameworks designed for containers when startup time, memory footprint, and scale-out speed matter.
• Treat large container images carefully because they consume more storage, network, CPU, and memory.
• Use layered container images so code changes only rebuild the application layer, not the JVM and dependency layers.
• Make sure images have a mode for local development and debugging when heap dumps, familiar tooling, and easier troubleshooting matter.
• Consider CDS to share class metadata and reduce repeated startup parsing across multiple JVM applications.
• Consider CRaC/checkpoint-restore when you want JVM compatibility with much faster startup but do not need the smallest native binary.
• Add observability such as OpenTelemetry so containerized Java performance issues can be diagnosed in all environments.

https://www.youtube.com/watch?v=Q8AxEx5JK-M
Achieving Microsecond Latencies with Java (Page last updated May 2026, Added 2026-06-28, Author Stefan Angelov, Publisher Devoxx). Tips:

• Define your latency target first; microsecond systems require very different Java design choices than normal backend code.
• Warm up the JVM before real traffic so JIT compilation and profiling data are ready before latency-sensitive work begins.
• Avoid allocations on hot paths because garbage collection is unpredictable at microsecond latency targets.
• Reuse mutable objects in performance-critical paths to avoid immutable object churn.
• Be careful with refactoring; extracting methods can add call overhead or prevent JIT inlining.
• Use JVM diagnostics such as logging inlining to verify whether critical methods are actually being optimized.
• Guard expensive or disabled logging with if checks or use lazy logging so string creation does not allocate unnecessarily.
• Consider off-heap memory with ByteBuffer or similar buffers for predictable memory and fewer GC pauses.
• Use primitives and primitive-friendly data structures to avoid boxing and unboxing overhead.
• Prefer single-threaded or sharded-by-thread designs for hot data so you avoid locks and keep data cache-local.
• Avoid synchronized and contended shared state because cache invalidation, kernel transitions, and lock coordination add latency.
• Preallocate object pools or ring buffers at startup when you must process millions of operations per second.
• Use proven low-latency libraries such as LMAX Disruptor, Agrona, Chronicle Queue/Map, and OpenHFT Affinity instead of reinventing them.
• Use CPU-aware techniques such as padding, avoiding false sharing, branch-friendly data layouts, and thread affinity.

https://www.youtube.com/watch?v=8lswtL1wqxk
How to trace a Java Memory Leak (Page last updated April 2026, Added 2026-06-28, Author Victor Rentea, Publisher Devoxx). Tips:

• Configure production JVMs to exit on OutOfMemoryError and always write a heap dump to durable storage that survives pod restarts.
• Treat the heap dump as a main artifact; once you have it, most memory-leak investigations become much easier.
• Analyze retained size, not shallow size, because retained size shows what memory would be freed if an object became unreachable.
• Avoid high-cardinality metric tags such as UUIDs, request IDs, or dynamic URLs because otherwise observability can cause memory leaks.
• Test your OOM and heap-dump setup in pre-production so you know the dump is actually produced and retrievable.
• When streaming large Hibernate result sets, remember the first-level persistence context still retains entities unless you detach them or use a stateless session.
• Don't build your own unbounded cache; use a real cache such as Caffeine with size limits, eviction, and metrics.
• Monitor cache size, hit ratio, and miss ratio; a cache without metrics should not go to production.
• Be careful with cache keys: avoid per-request fields, ensure correct equals/hashCode, and don't use mutable entities whose IDs change after persistence.
• Avoid non-static inner classes, anonymous classes, and old double-brace initialization when they can accidentally retain references to enclosing objects.
• Don't parse arbitrary numeric-looking strings into huge objects like BigDecimal without bounds; malformed or surprising input can trigger OOMs.
• Remember that List.subList() returns a view backed by the original list; copy it or use a proper queue/deque for sliding-window logic.
• Always clear ThreadLocal values in a finally block, especially with pooled threads handling requests.
• Don't submit unbounded async work to the common ForkJoinPool; use a bounded executor, monitor queue size, and apply back pressure.
• Watch for executor self-submit deadlocks, where tasks running in a pool submit more work to the same pool and then block waiting for it.

Jack Shirazi Back to newsletter 307 contents