DEV Community

Jagadish Rajasekar
Jagadish Rajasekar

Posted on

Java Performance Tuning – Advanced

In high-stakes performance testing, interviewers often go beyond threads and GC basics and dive into advanced JVM optimizations.

This post is an advanced refresher on Java performance tuning concepts for performance engineers.

🔹 1. JIT Compilation & HotSpot Optimizations

Q1. What is JIT?

  • JIT (Just-In-Time compiler) compiles bytecode to native code at runtime.
  • Optimizations: inlining, constant folding, loop unrolling, escape analysis.

💡 Interview Angle: JIT reduces interpretation overhead and adapts to runtime workload.

Q2. Tiered Compilation

  • C1 (client compiler) → fast startup.
  • C2 (server compiler) → long-running, highly optimized.
  • Tiered compilation uses both.

Q3. Escape Analysis

  • Determines if an object escapes a method.
  • If not → allocate on stack instead of heap → reduces GC pressure.

Example:

public int sum() {
    Point p = new Point(1, 2); // may stay on stack
    return p.x + p.y;
}
Enter fullscreen mode Exit fullscreen mode


`

🔹 2. Advanced GC Concepts

Q4. G1 GC Tuning

  • Splits heap into regions (not contiguous generations).
  • Prioritizes regions with most garbage.
  • Flags:

bash
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200

Q5. ZGC & Shenandoah

  • ZGC (low-latency GC) → pauses < 10ms, heaps up to TBs.
  • Shenandoah → concurrent compacting, predictable pauses.

💡 Interview Angle: If interviewer asks “Which GC for ultra-low latency trading systems?” → ZGC/Shenandoah.

Q6. GC Logging

bash
-Xlog:gc*:file=gc.log:time,uptime,level,tags

Analyze GC logs with tools like GCViewer or GCEasy.

🔹 3. JVM Internals

Q7. Class Loading

  • Bootstrap → Extension → Application class loaders.
  • Common performance issue: classloader leaks in app servers.

Q8. Code Cache

  • JIT-compiled code stored in Code Cache.
  • If full → java.lang.OutOfMemoryError: CodeCache is full.
  • Tune with:

bash
-XX:ReservedCodeCacheSize=256m

Q9. Java Memory Model (JMM)

  • Defines how threads interact with memory.
  • Guarantees: happens-before relationship.
  • Volatile, synchronized, final → affect visibility & ordering.

Q10. False Sharing

  • Multiple threads modify variables in the same CPU cache line.
  • Fix: padding or @sun.misc.Contended.

🔹 4. Locking & Synchronization

Q11. Lock Optimizations

  • Biased locking → lock owned by one thread, no contention.
  • Lightweight locking → CAS (compare-and-swap) before heavyweight monitor.

💡 Optimizations reduce overhead of synchronized.

Q12. Lock Contention Analysis

  • Tools: jstack, jfr (Java Flight Recorder).
  • Look for threads in BLOCKED state.

Q13. Optimistic vs Pessimistic Concurrency

  • Optimistic → assume no conflict (AtomicInteger, CAS).
  • Pessimistic → lock resources (synchronized, ReentrantLock).

🔹 5. Advanced Tuning Flags

Q14. Heap Sizing

bash
-Xms4g -Xmx4g -XX:+AlwaysPreTouch

  • Pre-touch ensures memory pages allocated upfront → reduces latency spikes.

Q15. Thread Stack Size

bash
-Xss512k

  • Tune per thread stack size to balance memory footprint vs recursion depth.

Q16. Large Pages

bash
-XX:+UseLargePages

  • Uses OS large pages for lower TLB misses.

🔹 6. Profiling & Monitoring

Q17. JFR (Java Flight Recorder)

  • Low overhead profiler, built into JVM.
  • Records GC, CPU, locks, threads.

Q18. Async Profiler

  • Flame graphs to identify hot methods.
  • Useful for CPU vs allocation profiling.

Q19. APM Tools

  • Dynatrace, AppDynamics, New Relic.
  • Correlate JVM metrics with transaction SLAs.

🔹 7. Key Advanced Interview Questions

Q20. How do you reduce GC pauses in high-throughput systems?

  • Use G1/ZGC.
  • Increase heap size.
  • Reduce object churn.
  • Tune MaxGCPauseMillis.

Q21. What is the difference between volatile and synchronized?

  • volatile → visibility guarantee, not atomicity.
  • synchronized → visibility + atomicity, but heavier.

Q22. What are safepoints in JVM?

  • Locations where JVM can pause all threads (e.g., GC).
  • Too many safepoints = performance issues.

Q23. How does JIT inlining affect performance?

  • Eliminates method call overhead.
  • But too much inlining → bloated code cache.

Q24. What is escape analysis and scalar replacement?

  • Escape analysis → checks if object escapes method.
  • Scalar replacement → replaces object with primitives if possible.

Q25. How do you analyze a production JVM performance issue?

  • Gather GC logs + thread dumps + heap dump.
  • Correlate with APM metrics.
  • Look for bottlenecks → GC thrashing, lock contention, DB waits.

✅ Final Takeaway

For advanced Java performance tuning, focus on:

  • JIT compiler optimizations (inlining, escape analysis)
  • Modern garbage collectors (G1, ZGC, Shenandoah)
  • JVM internals (classloading, memory model, safepoints)
  • Locking optimizations & false sharing
  • Advanced tuning flags & profiling tools

Top comments (0)