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 306 contents

https://www.youtube.com/watch?v=7BK-Zq5WP3o
Tracing Java Performance Bottlenecks (Page last updated April 2026, Added 2026-05-26, Author Victor Rentea, Publisher Devoxx). Tips:

• Use JMH for microbenchmarking. JVM warmup and JIT compilation can completely distort results (JMH handles those).
• Use profilers to verify performance assumptions instead of guessing where time is lost.
• Load Java Flight Recorder recordings into tools like Java Mission Control to inspect production-like bottlenecks.
• Prefer sampling profilers for low-overhead investigation, but remember they need enough load and samples to be accurate.
• Read flame graphs from bottom to top and focus on split points where execution time branches into expensive paths.
• Avoid holding locks while doing database or remote API calls.
• Be careful with Spring @transactional; don't wrap read-only work or remote calls in transactions unnecessarily.
• Keep database connections for the shortest possible time, especially when the default pool may have only around 10 connections.
• Don't put expensive network calls inside aspects, interceptors, or hidden framework hooks.
• Check cheap preconditions before expensive work, such as checking annotations before fetching user roles remotely.
• Avoid generated toString() on JPA entities with lazy collections because logging can accidentally trigger database queries.
• Don't build log strings eagerly for disabled log levels; use parameterized logging or guard expensive log construction.
• Compare flame graphs before and after changes to confirm that the suspected bottleneck actually disappeared.
• Use async-profiler when you need visibility into native code that JFR may not explain.
• For distributed systems, propagate trace IDs with OpenTelemetry and use tail sampling so slow or failed traces are retained without storing everything.

https://www.infoq.com/presentations/latency-techniques/
Latency: the Race to Zero...Are We There Yet? (Page last updated April 2026, Added 2026-05-26, Author Amir Langer, Publisher InfoQ). Tips:

• Optimize for predictable latency, not just average latency; the latency of each critical operation matters.
• Treat communication as the main bottleneck in modern distributed systems.
• Don't assume adding more threads, CPUs, or memory will reduce latency; design the execution path deliberately.
• Separate concerns so each thread or component does one job and avoids waiting on unrelated work.
• Use ring buffers or efficient queues to pass work between stages with minimal allocation.
• Avoid memory allocation on hot paths; preallocate and reuse objects to protect predictable latency.
• Prefer asynchronous message processing so components can continue working instead of blocking for responses.
• Use IPC or shared memory when components can run on the same host and network transport is unnecessary.
• Use function calls instead of messaging when components can safely run in the same process.
• Design business logic as deterministic state machines that consume ordered events and emit output events.
• Use a totally ordered log to replicate state, coordinate checkpoints, and avoid clock drift issues.
• Keep business logic separate from log persistence, distribution, and consensus mechanics.
• Use quorum-based consensus for fault tolerance, but choose implementations that preserve predictable latency.
• Watch for fan-out bottlenecks where one input message creates many output messages through a single egress channel.
• Consider a sequencer architecture where a dedicated component orders events while state machines live in applications.

https://www.youtube.com/watch?v=kZX68ljA6J0
Faster or better designed? Choose any two! (Page last updated April 2026, Added 2026-05-26, Author Dmytro Vyazelenko, Publisher GeeCON). Tips:

• Define your latency target first; "low latency" requires different designs at millisecond, microsecond, and nanosecond scales.
• Avoid allocations on hot paths because GC pauses and cache misses can dominate latency.
• Prefer binary encodings over JSON/XML for performance-sensitive interfaces.
• Use flyweight objects, reusable buffers, and APIs that parse/process data without allocating.
• Use primitive collections where possible to avoid boxing and object churn.
• Batch naturally by decoupling producers from writers with a queue or ring buffer.
• Prefer a single-threaded design when it is simpler and fast enough; parallelism is not automatically faster.
• Use dedicated pipeline threads only when each stage has a clear, stable responsibility.
• Avoid shared mutable state; communicate between threads by passing messages.
• Use the single-writer principle for contended resources like sockets, logs, or databases.
• Keep exceptional cases out of the main hot path so the common path stays branch-light and JIT-friendly.
• Avoid unnecessary data copies, but do not share mutable state just to avoid copying.
• Aim for low system utilization; latency rises sharply as utilization approaches saturation.
• Measure tail latency, especially P99 and beyond, not just averages or P50.
• Use back pressure-aware, non-blocking APIs where possible so callers can decide whether to retry, shed load, or propagate pressure.

Jack Shirazi Back to newsletter 306 contents