Java Developer interview questions

I would size the whole process first and load-test several heap points rather than assign all 8 GiB to `-Xmx`.

• Reserve measured space for metaspace, code cache, thread stacks, direct buffers, native libraries, and roughly 10% to 15% container headroom.
• Start near `-Xms4g -Xmx4g`, then compare allocation stalls, GC CPU, live-set margin, pause percentiles, RSS, and p99 under sustained 1.2 GiB/s allocation.
• Keep the smallest heap that meets 120 ms p99 and throughput without old-generation growth or container memory pressure.

I would benchmark ZGC first because a 10 ms pause target on 32 GiB favors concurrent relocation, while keeping G1 as the throughput baseline.

• ZGC usually keeps pauses short across large heaps but consumes concurrent CPU and extra memory, so the available 25% headroom must be verified.
• G1 may deliver better throughput if its young and mixed collections remain below 10 ms with the measured live set and allocation rate.
• The decision uses p99 and p99.9 pauses, application throughput, GC CPU, RSS, allocation stalls, and recovery after traffic bursts.

I would capture a steady workload and unified GC logs before changing one flag at a time.

• Record allocation rate, live set after full marking, young and mixed pause distributions, remembered-set work, promotion, evacuation failures, concurrent-cycle timing, and GC CPU.
• Lowering `MaxGCPauseMillis` can shrink young collections and increase their frequency, while manual young sizing can fight G1 ergonomics.
• A change stays only if end-to-end p99, throughput, and CPU improve across warm-up, steady state, and old-generation pressure.

I would test Generational ZGC when most objects die young and non-generational ZGC spends unnecessary work scanning the whole allocation stream.

• Enable the supported Java 21 option in an isolated benchmark and keep identical heap, workload, warm-up, and container limits for comparison.
• Measure pause percentiles, allocation stalls, concurrent GC CPU, remembered-set overhead, live-set recovery, throughput, and RSS over several hours.
• Adopt it only if the 3 GiB/s workload gains CPU or throughput without regressing latency or operational supportability.

I would keep the temporary objects local and nonescaping so C2 can scalar-replace them after inlining.

• Returning the object, storing it in a field, passing it to opaque code, or losing inlining can make the allocation escape and remain on the heap.
• JFR or async-profiler allocation profiles verify whether compiled code still allocates, while JIT compilation logs explain failed inlining or deoptimization.
• A JMH benchmark with consumed results and warmed forks must show lower allocation and equal behavior before rewriting readable domain code.

I would reduce allocation only in measured hot paths because 900 MiB/s still consumes GC CPU and memory bandwidth even with short pauses.

• TLAB makes individual allocations cheap, but refills, young-region turnover, survivor copying, and promotion consume shared resources.
• Profile bytes and objects by allocation site, then target boxing, temporary collections, string formatting, and oversized buffers with clear ownership.
• Accept the change only if CPU, throughput, or capacity improves without unsafe pooling or a readability cost larger than the gain.

I would separate time to reach the safepoint from the 12 ms stop-the-world operation.

• Threads in native calls, long counted loops, or paths with delayed polling can postpone global synchronization even when collector work is short.
• Safepoint logs, JFR thread states, and stack samples identify the slow thread and whether JNI, compiler activity, or a diagnostic action is involved.
• The fix targets the blocking native or polling path; changing collector pause flags cannot remove 168 ms spent reaching the safepoint.

I would compare dominators and GC-root paths at equivalent workload points and relate growth to an explicit retention policy.

• A leak typically grows through listeners, static collections, thread locals, class loaders, or keys that should have expired.
• A legitimate cache should have a configured maximum, eviction metrics, hit value, and retained size correlated with expected key cardinality.
• MAT histograms and dominator deltas identify the owners of the extra 2.3 GiB, while forced full GC only confirms reachability, not usefulness.

I would give each deployment one disposable child class loader and remove every strong reference when the plugin stops.

• Threads, thread locals, JDBC drivers, logging registries, executors, MBeans, and static parent caches commonly retain old loaders.
• Class-unload and Native Memory Tracking metrics plus `jcmd VM.classloader_stats` verify whether loader generations disappear after full marking.
• A churn test must load and unload well beyond 400 versions with bounded metaspace before the lifecycle is accepted.

I would treat the 2 GiB as a measured native budget, not guaranteed spare memory.

• Account for direct buffers, metaspace, JIT code cache, thread stacks, GC structures, JNI libraries, memory mappings, and allocator fragmentation.
• Monitor RSS, NMT categories, Netty allocator metrics, thread count, and `BufferPoolMXBean`, then cap direct memory and pools from the observed peak.
• Leave container headroom for bursts and kernel accounting; if the native peak exceeds the budget, reduce heap or concurrency rather than wait for an OOM kill.

I would use the networking library's bounded direct-buffer pool if profiling shows copy or allocation cost, not build an unbounded custom pool.

• Direct buffers reduce native I/O copies but have allocation and cleanup costs and consume memory outside the Java heap.
• Size arenas and maximum retained capacity from concurrency and payload percentiles, and reject oversized buffers from returning to common pools.
• Compare throughput, CPU, RSS, allocator fragmentation, pool hit rate, and tail latency against heap buffers under 40,000 RPS.

I would separate startup capacity from steady-state capacity and warm the real hot paths before declaring a replica ready.

• JFR and compilation logs show tiered compilation, code-cache pressure, inlining, uncommon traps, and methods repeatedly deoptimized.
• A representative warm-up must preserve branch and type profiles; synthetic calls that exercise different receivers can produce misleading compiled code.
• Capacity planning includes 90-second readiness, rollout surge, and cold-replica routing, while tuning compiler flags is secondary to fixing unstable profiles.

I would check whether the larger heap disabled compressed ordinary object pointers or changed object alignment.

• Compressed oops often work below a JVM-dependent addressable threshold near 32 GiB, reducing reference and header width.
• `jcmd VM.info`, startup logs, JOL, and a class histogram confirm pointer mode and actual object layout rather than relying on the nominal threshold.
• Compare total RSS, live-set bytes, cache locality, pause behavior, and p99; a 40 GiB heap can provide less effective capacity than expected.

I would benchmark a primitive-oriented layout because 30 million object headers and references can dominate the actual price data.

• Records improve immutability and API clarity but remain heap objects and do not automatically remove headers or pointer chasing.
• Parallel primitive arrays or a packed off-heap structure improve density and locality but add indexing, lifecycle, and safety complexity.
• Choose from measured bytes per entry, scan throughput, update pattern, GC pressure, serialization cost, and maintainability.

I would record low-overhead JFR continuously and trigger async-profiler during a reproduced burst for higher-resolution stacks.

• JFR correlates CPU, allocation, locks, threads, GC, safepoints, I/O, and application events on one timeline.
• async-profiler adds wall-clock, CPU, allocation, and lock flame graphs with AsyncGetCallTrace or perf-based sampling that avoids safepoint bias.
• The same 30-second window and request IDs must connect hot stacks to latency, otherwise a flame graph can optimize unrelated background work.

I would publish an immutable configuration through a volatile reference or another explicit happens-before edge.

• A volatile write of the reference happens-before later volatile reads, making all prior constructor writes visible to readers.
• Final fields add initialization guarantees only when `this` does not escape during construction; they do not publish the reference by themselves.
• Replacing the complete object avoids readers observing a mix of old and new values across its fields.

I would use `LongAdder` when high write throughput matters more than an atomic instantaneous total.

• `AtomicLong` performs CAS on one cache line, so retries and coherence traffic rise sharply under 32-core contention.
• `LongAdder` spreads updates across cells and sums them on read, trading extra memory and non-linearizable snapshots for write scalability.
• A JMH contention benchmark plus the metric's accuracy contract decides whether the 8-million-per-second gain is useful.

I would start with `synchronized` for simple mutual exclusion and choose `ReentrantLock` only for a required capability proven by contention tests.

• `ReentrantLock` adds timed and interruptible acquisition, multiple conditions, and optional fairness, which can reduce throughput.
• Forty microseconds times 32 contenders may make lock partitioning or shorter critical sections more valuable than lock implementation choice.
• JFR lock events and a production-shaped benchmark compare wait time, throughput, p99, and cancellation behavior.

I would keep slow I/O outside the map's atomic computation and store a short-lived future or promise per key.

• The first caller installs a `CompletableFuture`, performs loading on a bounded executor, and followers share the same result without duplicate calls.
• Failures remove or expire the placeholder deliberately so one exceptional future does not poison the key forever.
• Bound total in-flight loads and measure bin contention, duplicate suppression, loader p99, memory, and timeout behavior at 5,000 keys per second.

The rough blocking ratio suggests about 160 runnable and waiting threads for full CPU utilization, but throughput demand makes the downstream capacity the real bound.

• The estimate is 16 times 1 plus 45 divided by 5, yielding about 160 threads before scheduling and memory overhead.
• At 2,000 RPS and 45 ms wait, Little's Law gives roughly 90 concurrent I/O operations, which must fit connection pools and downstream limits.
• Load-test queue delay, CPU, thread count, connection use, p99, and rejection, then use a bounded queue rather than absorb unlimited work.