Q: A high-concurrency Java 21 backend service utilizing Virtual Threads experiences carrier thread starvation and latency spikes. Profiling reveals that worker tasks call synchronized blocks wrapping legacy cryptographic libraries. How do you diagnose virtual thread pinning using JFR events and replace monitors with ReentrantLock?

Virtual threads are cheap, JVM-scheduled threads mounted onto a small pool of OS "carrier" threads and unmounted whenever they block on I/O, letting the carrier run other virtual threads. But a synchronized block is special-cased: the JVM cannot unmount a virtual thread while it holds a monitor lock, so if that blocked call is slow, the carrier thread itself is stuck — pinned — and can't serve any other virtual thread. Enough pinned virtual threads exhaust the whole carrier pool and everything queues up. You diagnose it with JDK Flight Recorder's jdk.VirtualThreadPinned event (enable with -XX:StartFlightRecording and inspect in JFR/async-profiler, or set jdk.tracePinnedThreads=full for a direct warning) which names the exact stack frame holding the monitor. The fix is replacing synchronized with java.util.concurrent.locks.ReentrantLock, since it's not special-cased by the virtual thread scheduler — a virtual thread waiting on it can be safely unmounted. ```java private final ReentrantLock lock = new ReentrantLock(); public String encrypt(byte[] data) { lock.lock(); try { return legacyCryptoLib.encrypt(data); } finally { lock.unlock(); } } ```

Q: You are building a custom lock-free concurrent memory pool. Explain how memory address reuse can trigger the classic ABA problem in Compare-And-Swap (CAS) loops, and demonstrate how AtomicStampedReference uses integer version stamps to prevent data corruption.

A lock-free CAS loop assumes that if a memory location still holds the value you expect, nothing has changed since you last read it. But if another thread swaps the value from A to B and then back to A — or, with a memory pool, frees a node at address A and reallocates a completely different object at that same address — between your read and your CAS, your CAS still succeeds even though the underlying state actually changed twice in between. That's the ABA problem: the value looks unchanged, but the history isn't. AtomicStampedReference fixes this by pairing the reference with an integer "stamp" bumped on every update, so CAS checks both the reference and the stamp — even if the reference cycles back to the same address, the stamp will have changed. ```java AtomicStampedReference pool = new AtomicStampedReference<>(head, 0); int[] stampHolder = new int[1]; Node current = pool.get(stampHolder); int stamp = stampHolder[0]; Node next = current.next; boolean success = pool.compareAndSet(current, next, stamp, stamp + 1); ``` Any thread that reused that memory address would have had to bump the stamp too, so a stale CAS attempt fails cleanly instead of silently corrupting the pool.

Question 1

An engineer annotates a private or package-private helper method with @Transactional and calls it internally from a public method in the same @Service class, but rollback never triggers on exceptions. Explain how Spring's dynamic proxies (CGLIB/JDK) intercept method invocations and how to refactor the design using self-injection or extracting a separate delegate service.

Accepted Answer

Spring's @Transactional (like most Spring AOP-backed annotations: @Async, @Cacheable, @Secured) doesn't work by rewriting the bytecode of your class — it works by wrapping your bean in a proxy at container startup. When another bean calls a method on your service, it's actually calling the proxy, which opens a transaction, delegates to the real object, and commits/rolls back around it. But when you call a method from inside the same class (self-invocation), you're calling `this.method()` directly on the raw object — the proxy is completely bypassed, so no transaction ever starts and the exception just propagates like a plain method call.

```java
@Service
public class OrderService {
    public void placeOrder(Order o) {
        saveOrder(o); // calls "this", not the proxy — @Transactional below is ignored
    }
    @Transactional
    private void saveOrder(Order o) { /* ... */ }
}
```

Fix: extract `saveOrder` into a separate `@Service` bean and inject it (so the call goes through Spring's context and hits the proxy), or self-inject the proxy via `@Autowired private OrderService self;` and call `self.saveOrder(o)`, or use `AopContext.currentProxy()` with expose-proxy enabled. Extracting a delegate service is generally the cleanest fix since it also improves separation of concerns.

Question 2

A singleton @Service bean injects a @Scope("prototype") report-builder bean, but only a single instance of the report builder is ever created across all requests. How do you resolve this bean-scope mismatch using ObjectProvider<T>, @Lookup method injection, or scoped proxies?

Accepted Answer

Spring resolves scopes at injection time by default. When a singleton bean has a prototype-scoped bean wired in via a normal @Autowired field, Spring creates the prototype bean exactly once — at the moment the singleton itself is constructed — and then hands out that same instance forever, because the singleton's field reference never changes. The prototype scope guarantees a new instance per getBean() call, not per use, so if you never call getBean() again, you never get a fresh instance. Three fixes: (1) ObjectProvider — inject the provider and call .getObject() each time you need a fresh instance; (2) @Lookup method injection — an abstract method Spring overrides via CGLIB to return a new prototype bean every call; (3) a scoped proxy (@Scope(value="prototype", proxyMode=ScopedProxyMode.TARGET_CLASS)) that resolves a new instance on every method call. ```java @Service public class InvoiceService { @Autowired private ObjectProvider reportBuilderProvider; public void generate() { ReportBuilder rb = reportBuilderProvider.getObject(); // fresh instance every call } } ``` ObjectProvider is usually preferred today since it needs no CGLIB proxying and is explicit about the lazy-fetch semantics.

Question 3

After migrating an endpoint to Spring WebFlux, overall API latency degrades catastrophically under moderate load. BlockHound flags that a legacy blocking JDBC query is executing directly on the Netty event loop threads. How do you isolate and offload blocking I/O calls onto Schedulers.boundedElastic()?

Accepted Answer

WebFlux runs on a small, fixed pool of Netty event-loop threads (typically one per CPU core) that are meant to never block — the whole non-blocking model depends on those threads always being free to pick up the next I/O event. A single blocking JDBC call parked on an event-loop thread stalls every other request multiplexed onto that same thread, so under load you get cascading latency instead of a graceful slowdown — exactly what BlockHound is designed to catch.

Fix: wrap the blocking call so it runs on a separate thread pool sized for blocking work, then rejoin the reactive pipeline afterward.

```java
Mono<Order> order = Mono.fromCallable(() -> legacyJdbcRepository.findById(id))
    .subscribeOn(Schedulers.boundedElastic());
```

boundedElastic() is a scheduler specifically meant for legacy blocking calls — it grows a bounded thread pool (default 10x CPU cores) instead of exhausting the event loop. The real long-term fix is migrating that data access to a reactive driver (R2DBC), since boundedElastic is a bridge, not a substitute for genuinely non-blocking I/O.

Question 4

Starting in Spring Boot 2.6+, circular bean references are disabled by default and cause application startup failure between OrderService and BillingService. Walk through resolving this cycle cleanly using domain events (e.g., ApplicationEventPublisher), interface segregation, or @Lazy injection.

Accepted Answer

A circular bean dependency (OrderService needs BillingService, BillingService needs OrderService) used to be silently resolved by Spring inserting early, partially-initialized bean references. Spring Boot 2.6 turned that off by default because it usually signals a real design smell and can leave beans in a half-constructed state.

Three real fixes, in order of preference: (1) break the cycle with domain events — OrderService publishes an OrderPlacedEvent via ApplicationEventPublisher, and BillingService listens with @EventListener, so neither needs a direct reference to the other; (2) interface segregation — extract only the narrow method each side actually needs into a small interface, often revealing that the "cycle" was really one service doing two jobs; (3) @Lazy on one of the two @Autowired fields, which defers resolution until first use, breaking the eager-construction cycle.

@Lazy is the quick unblock; events or interface splitting are the actual architectural fix — re-enabling spring.main.allow-circular-references=true is the escape hatch to avoid, since it just restores the old silent behavior.

Question 5

A custom JWT authentication filter is never executed for public endpoints, but exceptions thrown inside the filter bypass the controller @ExceptionHandler and return generic 500 HTML pages. How do you configure SecurityFilterChain ordering and delegate filter authentication errors to Spring's HandlerExceptionResolver?

Accepted Answer

Two separate problems here. First, "public endpoints" only skip authentication if the SecurityFilterChain actually says so — via permitAll() for those paths — but Spring's servlet filters still run in the configured order for every request unless the filter explicitly checks the path and short-circuits. If your JWT filter isn't running at all for public paths, check it's registered with addFilterBefore at the right position and that the permitAll config reflects intent.

Second, exceptions thrown inside a filter happen before Spring MVC's DispatcherServlet and @ExceptionHandler machinery ever run — filters sit in the raw servlet filter chain, upstream of the framework that knows what a controller-level exception handler is. That's why they fall through to the container's generic error page instead of your JSON error response. The fix is to register Spring Security's ExceptionTranslationFilter (done automatically when you configure .exceptionHandling()) with a custom AuthenticationEntryPoint/AccessDeniedHandler, or wrap your filter's logic in a try/catch that manually delegates to HandlerExceptionResolver.resolveException() so it produces the same response shape your @ExceptionHandler-based controllers use.

Question 6

An asynchronous notification service uses Executors.newFixedThreadPool(20) to process outbound emails. During an email provider outage, the JVM crashes with OutOfMemoryError: Java heap space. Explain how LinkedBlockingQueue default capacity causes unbounded memory accumulation and how to configure a bounded ThreadPoolExecutor with a CallerRunsPolicy.

Accepted Answer

Executors.newFixedThreadPool(20) internally uses an unbounded LinkedBlockingQueue for its work queue. When the 20 worker threads are all busy (or blocked waiting on a downed email provider), every new submitted task just queues up — there's no backpressure, no rejection, nothing stopping the queue from growing to millions of pending Runnables, each holding a reference to its captured email payload, until the heap is exhausted.

The fix is to build the ThreadPoolExecutor explicitly with a bounded queue and a rejection policy that applies backpressure instead of silently accepting unlimited work.

```java
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    20, 20, 0L, TimeUnit.MILLISECONDS,
    new ArrayBlockingQueue<>(500),          // bounded — caps memory
    new ThreadPoolExecutor.CallerRunsPolicy() // pushes back on the submitting thread
);
```

CallerRunsPolicy makes the calling thread execute the rejected task itself once the queue is full, which naturally throttles the producer instead of crashing the JVM. This is exactly why Java style guides discourage the Executors factory methods in production and recommend constructing ThreadPoolExecutor directly.

Question 7

In a microservice orchestrating parallel calls via CompletableFuture.allOf(), one downstream call throws an exception, but the aggregated future hangs or fails to surface the underlying root cause. How do you implement robust exception propagation and fallback handling using .handle(), .exceptionally(), or .whenComplete()?

Accepted Answer

CompletableFuture.allOf() returns a CompletableFuture — it only tells you that all futures completed, not what any of them returned. If you don't explicitly handle each future's own exception, one failing call can leave the pipeline waiting on .get() with an unhelpful CompletionException wrapping the real cause, or make it unclear which downstream call actually failed. The robust pattern is to attach .exceptionally() or .handle() to each individual future before combining them, so each has a defined fallback, and unwrap the real cause at the top. ```java CompletableFuture f1 = callServiceA() .exceptionally(ex -> { log.warn("A failed", ex); return DEFAULT_A; }); CompletableFuture f2 = callServiceB() .exceptionally(ex -> { log.warn("B failed", ex); return DEFAULT_B; }); CompletableFuture.allOf(f1, f2) .thenRun(() -> combine(f1.join(), f2.join())) .exceptionally(ex -> { log.error("pipeline failed", ex.getCause()); return null; }); ``` .handle() is preferable over .exceptionally() when you need logic regardless of success/failure, while .whenComplete() is for side effects that don't change the result. The key discipline: never let a future without its own exception handling go into allOf() expecting the aggregate to explain which one broke.

Question 8

Two concurrent background worker threads attempt to transfer funds between Account A and Account B using pessimistic database locks (SELECT FOR UPDATE), resulting in sporadic database deadlocks. How do you design a deterministic resource-ordering mechanism based on entity IDs to guarantee deadlock-free locking?

Accepted Answer

Deadlocks happen here because the two worker threads lock accounts in opposite order: thread 1 locks A then tries to lock B, while thread 2 has already locked B and is waiting on A. Each holds what the other needs — a classic circular wait, and the database eventually kills one transaction with a deadlock error.

The fix doesn't touch the locking mechanism at all — it requires every thread to acquire locks in the same global order, regardless of which account is the source or destination in the business operation. Since account IDs are comparable, sort by ID before locking.

```java
Account first = accountA.getId().compareTo(accountB.getId()) < 0 ? accountA : accountB;
Account second = first == accountA ? accountB : accountA;

Account lockedFirst = accountRepository.findByIdForUpdate(first.getId());
Account lockedSecond = accountRepository.findByIdForUpdate(second.getId());
// now safe to debit/credit in any order
```

As long as every thread that ever locks two of the same rows resolves the order deterministically (lowest ID first), a circular wait becomes structurally impossible.

Question 9

A high-concurrency Java 21 backend service utilizing Virtual Threads experiences carrier thread starvation and latency spikes. Profiling reveals that worker tasks call synchronized blocks wrapping legacy cryptographic libraries. How do you diagnose virtual thread pinning using JFR events and replace monitors with ReentrantLock?

Accepted Answer

Virtual threads are cheap, JVM-scheduled threads mounted onto a small pool of OS "carrier" threads and unmounted whenever they block on I/O, letting the carrier run other virtual threads. But a synchronized block is special-cased: the JVM cannot unmount a virtual thread while it holds a monitor lock, so if that blocked call is slow, the carrier thread itself is stuck — pinned — and can't serve any other virtual thread. Enough pinned virtual threads exhaust the whole carrier pool and everything queues up.

You diagnose it with JDK Flight Recorder's jdk.VirtualThreadPinned event (enable with -XX:StartFlightRecording and inspect in JFR/async-profiler, or set jdk.tracePinnedThreads=full for a direct warning) which names the exact stack frame holding the monitor. The fix is replacing synchronized with java.util.concurrent.locks.ReentrantLock, since it's not special-cased by the virtual thread scheduler — a virtual thread waiting on it can be safely unmounted.

```java
private final ReentrantLock lock = new ReentrantLock();
public String encrypt(byte[] data) {
    lock.lock();
    try { return legacyCryptoLib.encrypt(data); }
    finally { lock.unlock(); }
}
```

Question 10

You are building a custom lock-free concurrent memory pool. Explain how memory address reuse can trigger the classic ABA problem in Compare-And-Swap (CAS) loops, and demonstrate how AtomicStampedReference uses integer version stamps to prevent data corruption.

Accepted Answer

A lock-free CAS loop assumes that if a memory location still holds the value you expect, nothing has changed since you last read it. But if another thread swaps the value from A to B and then back to A — or, with a memory pool, frees a node at address A and reallocates a completely different object at that same address — between your read and your CAS, your CAS still succeeds even though the underlying state actually changed twice in between. That's the ABA problem: the value looks unchanged, but the history isn't. AtomicStampedReference fixes this by pairing the reference with an integer "stamp" bumped on every update, so CAS checks both the reference and the stamp — even if the reference cycles back to the same address, the stamp will have changed. ```java AtomicStampedReference pool = new AtomicStampedReference<>(head, 0); int[] stampHolder = new int[1]; Node current = pool.get(stampHolder); int stamp = stampHolder[0]; Node next = current.next; boolean success = pool.compareAndSet(current, next, stamp, stamp + 1); ``` Any thread that reused that memory address would have had to bump the stamp too, so a stale CAS attempt fails cleanly instead of silently corrupting the pool.

Question 11

A REST API returning a paginated list of 50 customer orders executes 51 separate SQL queries to fetch customer profile records due to lazy loading. Compare fixing this N+1 query problem using JOIN FETCH queries versus Spring Data JPA @EntityGraph definitions, noting the impact on pagination in memory.

Accepted Answer

Lazy loading means each order.getCustomer() access, if not already loaded, fires its own SELECT — so for 50 orders you get 1 query for the orders plus 50 more for each order's customer, the classic N+1 problem. JOIN FETCH in a JPQL query eagerly pulls the association in the same SQL query via a join. ```java @Query("SELECT o FROM Order o JOIN FETCH o.customer WHERE o.status = :status") List findByStatus(@Param("status") String status); ``` The catch with pagination is that Hibernate can't apply LIMIT/OFFSET at the SQL level when a JOIN FETCH on a collection expands row count, so it falls back to loading the whole result set into memory and paginating there — dangerous for a large table. @EntityGraph solves this more safely: it fetches associations as a second targeted query (or a join, depending on type) while still letting Spring Data JPA apply real SQL-level pagination. ```java @EntityGraph(attributePaths = "customer") Page findByStatus(String status, Pageable pageable); ``` For paginated lists, @EntityGraph (or a @BatchSize on the association) is almost always the safer choice over JOIN FETCH.

Question 12

A nightly job importing 100,000 product updates via Hibernate throws OutOfMemoryError after processing 20,000 records. Explain how the Hibernate first-level session cache and dirty-checking mechanism retain managed entity references, and how to implement periodic entityManager.flush() and entityManager.clear() batches or use StatelessSession.

Accepted Answer

Hibernate's Session (first-level cache / persistence context) keeps a reference to every managed entity it has ever loaded or persisted during its lifetime, plus dirty-checking snapshots to compare against on flush. In a single long-running transaction processing 100,000 records, none of those managed entities are ever eligible for garbage collection — the session holds them all — so memory grows linearly until the heap gives out.

The fix is to periodically flush pending changes to the database and clear the persistence context so those entities become eligible for GC, in fixed-size batches.

```java
int batchSize = 50;
for (int i = 0; i < products.size(); i++) {
    entityManager.merge(products.get(i));
    if (i % batchSize == 0 && i > 0) {
        entityManager.flush(); // push SQL to DB
        entityManager.clear(); // detach everything, free memory
    }
}
```

For a pure bulk-import job that doesn't need the managed-entity/dirty-checking machinery, Hibernate's StatelessSession is an even better fit — it skips the first-level cache entirely, trading convenience for dramatically lower memory overhead.

Question 13

Under sustained load, an API starts throwing HikariPool-1 - Connection is not available, request timed out after 30000ms. How do you distinguish between slow SQL queries, unclosed transactions, and connection leaks using HikariCP's leakDetectionThreshold and thread dumps?

Accepted Answer

"Connection is not available" just means every connection in the pool is currently checked out and none freed up within the wait timeout — but that symptom has three very different root causes: genuinely slow queries holding connections legitimately, transactions that stay open too long (e.g., calling a slow external API inside a @Transactional method), or actual leaks where code calls getConnection() and never closes it.

leakDetectionThreshold (in milliseconds, e.g. 5000) makes HikariCP log a stack trace for any connection held longer than that threshold while still checked out — if the same code path logs repeatedly, that's a real leak, not just a slow query, because a normal slow query still returns the connection when it finishes. To confirm and pinpoint the cause under load, take a thread dump (jstack or kill -3) during the incident: threads stuck at HikariPool.getConnection() are waiting for the pool, while threads stuck inside JDBC driver calls or downstream HTTP calls while holding a connection point to the actual blocking work. Combining the leak-detection trace with a live thread dump separates "slow query" from "leak" from "long transaction boundary."

Question 14

An inventory service experiences frequent OptimisticLockException (@Version mismatch) during flash sales when multiple users decrement stock simultaneously. How do you design an automated retry mechanism with exponential backoff and randomized jitter using Spring Retry or AOP around the transactional boundary?

Accepted Answer

Optimistic locking via @Version checks, at commit time, that the row's version hasn't changed since you read it — under flash-sale-level contention this happens constantly by design, so the correct response is to retry the whole business operation from a fresh read, not fail the user's request outright.

Spring Retry lets you declare this declaratively around the transactional method.

```java
@Retryable(
    retryFor = OptimisticLockException.class,
    maxAttempts = 5,
    backoff = @Backoff(delay = 100, multiplier = 2, random = true)
)
@Transactional
public void decrementStock(Long productId, int qty) {
    Inventory inv = inventoryRepository.findById(productId).orElseThrow();
    inv.decrement(qty);
}
```

The exponential backoff with jitter (random = true) matters because without it, retried requests re-collide in lockstep, recreating the same contention spike. @Retryable must wrap the outside of the @Transactional boundary so each retry attempt gets its own fresh transaction and a fresh read of the current version.

Question 15

Attempting to eagerly fetch two distinct @OneToMany List collections (e.g., Order.items and Order.promotions) in a single JPQL query causes Hibernate to throw MultipleBagFetchException. Why does Hibernate disallow multiple bag fetches, and how do you resolve it using Set collections or multiple query splits without causing Cartesian product explosions?

Accepted Answer

A Hibernate "bag" is a List-typed collection with no uniqueness constraint and no ordering guarantee — when you eagerly fetch two bags in one query via a SQL join, the join multiplies rows: if an order has 3 items and 2 promotions, the joined result set has 6 rows, and Hibernate has no reliable way to reassemble two independent collections from that Cartesian product. Rather than silently return corrupted data, Hibernate refuses outright.

Two real fixes: (1) change one or both collections from List to Set — Hibernate can correctly de-duplicate a Cartesian product for a Set, at the cost of losing explicit ordering unless you add @OrderColumn; (2) split into two separate queries — fetch items eagerly in one query, then fetch promotions for the same order IDs in a second (or use @EntityGraph fetching one collection at a time), avoiding join-multiplication entirely. In practice, splitting into two targeted queries is usually preferred over converting business-meaningful ordered lists into sets just to satisfy Hibernate's fetch mechanics.

Question 16

An integration test suite containing 300 test classes takes 45 minutes to run in CI. Profiling reveals that excessive use of @MockBean and @DirtiesContext is continuously invalidating the Spring TestContext cache and re-bootstrapping the application. How do you refactor test architecture to maximize context reuse?

Accepted Answer

Spring's TestContextFramework caches a fully-built ApplicationContext keyed by its exact configuration — config classes, active profiles, property sources, and critically the set of @MockBean/@SpyBean definitions — and reuses it across test classes sharing an identical key. @DirtiesContext explicitly evicts the cached context (correct when a test genuinely mutates shared state), but @MockBean implicitly changes the cache key too — every distinct combination of mocked beans is a different key, so if each test class mocks a slightly different set of beans, you effectively get a full rebuild per class.

The fix is to converge test classes onto a small number of shared configurations: centralize common mocks into a shared base test class or reusable @TestConfiguration setups, remove @DirtiesContext where it isn't truly needed, and audit @MockBean used out of habit rather than necessity. The measurable target is the context-cache hit rate Spring logs at DEBUG (ContextCacheUtils) — driving that toward the number of distinct real configurations the suite needs, not the number of test classes, is what turns 45 minutes into a few.

Question 17

Integration tests spinning up separate PostgreSQL and Apache Kafka containers for each test class run out of Docker resources in CI. How do you implement the singleton container pattern and configure container reuse with dynamic property registration (@DynamicPropertySource) across JUnit 5 suites?

Accepted Answer

Each @Container declared per test class starts and tears down its own Docker container — with hundreds of test classes, that's hundreds of container startups, exhausting CI resources. The singleton container pattern starts exactly one container per type for the entire JVM/test run and shares it across every test class. ```java public abstract class AbstractIntegrationTest { static final PostgreSQLContainer POSTGRES = new PostgreSQLContainer<>("postgres:16").withReuse(true); static final KafkaContainer KAFKA = new KafkaContainer(DockerImageName.parse("confluentinc/cp-kafka:7.6.0")); static { POSTGRES.start(); KAFKA.start(); } @DynamicPropertySource static void registerProps(DynamicPropertyRegistry registry) { registry.add("spring.datasource.url", POSTGRES::getJdbcUrl); registry.add("spring.kafka.bootstrap-servers", KAFKA::getBootstrapServers); } } ``` Every integration test class extends this base class instead of declaring its own containers. withReuse(true) combined with testcontainers.reuse.enable=true in ~/.testcontainers.properties goes further and keeps the container alive across separate test runs, useful on CI runners that persist a Docker daemon between jobs.

Question 18

A Spring Boot 3 application compiled into a GraalVM native executable boots in 50ms but crashes on the first incoming request with ClassNotFoundException during third-party JSON deserialization. Explain why ahead-of-time (AOT) compilation requires reachability metadata and how to register reflection hints using @RegisterReflectionForBinding.

Accepted Answer

Ahead-of-time native compilation builds a closed-world binary at compile time — it statically analyzes what classes, methods, and fields your code actually reaches and strips everything else, since there's no JIT or classloader left at runtime. Reflection-based JSON mappers like Jackson bypass that static analysis — native-image has no way to know at build time that ObjectMapper will reflectively touch fields of a POJO it never sees referenced directly, so it strips that metadata, and the class simply isn't there at runtime.

The fix is registering reachability metadata / reflection hints explicitly. Spring Boot 3's AOT engine auto-generates a lot of this for its own beans, but for DTOs used only via reflection, you register it yourself.

```java
@Configuration
@RegisterReflectionForBinding(OrderResponseDto.class)
public class NativeHintsConfig { }
```

This keeps full reflective metadata for OrderResponseDto available at runtime so Jackson can still deserialize it. For third-party libraries you don't control, Spring also supports plugging in externally-published reachability-metadata.json files instead of hand-writing hints per dependency.

Question 19

During Kubernetes rolling deployments, Spring Boot pods terminated by SIGTERM drop in-flight transactions and return 502s to clients. How do you configure server.shutdown=graceful, set executor termination timeouts, and coordinate Kubernetes preStop sleep hooks to ensure zero-downtime rolling updates?

Accepted Answer

When Kubernetes terminates a pod during a rolling update, it sends SIGTERM then waits terminationGracePeriodSeconds before a hard SIGKILL — but a JVM receiving SIGTERM shuts down its embedded server almost immediately by default, dropping mid-flight requests, while Kubernetes may still route new traffic to the pod briefly before removing it from the Service.

Two fixes address the two windows of risk. First, server.shutdown=graceful (Spring Boot 2.3+) stops accepting new connections on SIGTERM but lets in-flight requests finish within spring.lifecycle.timeout-per-shutdown-phase. Second, add a Kubernetes preStop hook that sleeps before the container actually receives SIGTERM.

```yaml
lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 5"]
```

This covers the race where the pod is marked for termination but the Service/endpoint update hasn't propagated cluster-wide yet — the preStop sleep buys time before the app starts refusing connections. Combining graceful in-app shutdown with a preStop delay is the standard pattern for zero-downtime rolling deploys.

Question 20

What is the difference between == and .equals() in Java, and where do people get bitten by it?

Accepted Answer

== compares reference identity for objects (do these two variables point to the exact same object?) and value equality for primitives. .equals() is a method a class can override to define logical equality — by default (from Object) it just falls back to ==, so any class that doesn't override it behaves the same as == for objects.

The classic trap is String and boxed types. String literals are interned in a pool, so "abc" == "abc" happens to be true, but new String("abc") == "abc" is false even though .equals() returns true for both. Similarly, Integer a = 127, b = 127; a == b is true due to Java's cached Integer pool (-128 to 127), but Integer a = 200, b = 200; a == b is false. The safe rule: always use .equals() for object value comparison, reserve == for primitives and deliberate identity checks.

Question 21

Why must you override hashCode() whenever you override equals()?

Accepted Answer

Every hash-based collection (HashMap, HashSet, Hashtable) relies on the contract that two equal objects must produce the same hash code — the reverse isn't required, but breaking the forward direction silently corrupts hash-based lookups.

A HashMap buckets entries by hashCode() and only calls equals() to compare entries within the same bucket. If you override equals() to compare a Person by id but leave the default identity-based hashCode() in place, two Person objects with the same id report .equals() == true but likely land in different buckets, so map.get(personWithSameId) returns null even though a "logically equal" key was inserted.

```java
class Person {
    int id;
    @Override public boolean equals(Object o) {
        return o instanceof Person p && p.id == this.id;
    }
    // BUG: no hashCode() override — Object's identity hash is used instead
}
```

Modern Java makes this easy with records (auto-generates both consistently) or Objects.hash(id) — the rule: same fields drive both, or don't override either.

Question 22

What is the difference between checked and unchecked exceptions in Java?

Accepted Answer

Checked exceptions (subclasses of Exception but not RuntimeException, like IOException or SQLException) must be caught or declared in the method's throws clause — the compiler enforces this. Unchecked exceptions (RuntimeException and its subclasses, like NullPointerException or IllegalArgumentException) need no such declaration.

```java
// checked — caller MUST handle or declare
public void readFile() throws IOException { ... }

// unchecked — caller may or may not catch it
public void divide(int a, int b) {
    if (b == 0) throw new IllegalArgumentException("divisor cannot be zero");
}
```

Most modern Java codebases (including Spring, e.g. DataAccessException) lean toward unchecked exceptions even for recoverable conditions, because checked exceptions force boilerplate try/catch or throws propagation through layers with no meaningful way to handle the failure, and don't compose well with functional interfaces/lambdas.

Question 23

What's the difference between the Java stack and the heap, and why do StackOverflowError and OutOfMemoryError differ?

Accepted Answer

Every thread gets its own stack, holding one frame per method call — local variables, parameters, and the return address; a frame is pushed on method entry and popped on return, automatically reclaimed with no GC involved. The heap is one shared region where every object (anything made with new, plus arrays) lives; local variables on the stack just hold pointers into the heap.

```java
void process() {
    int count = 5;              // primitive lives on this thread's stack frame
    Order order = new Order();  // reference on the stack; the Order object on the heap
}
```

This is why StackOverflowError (too many nested/recursive calls exhausting stack space, sized by -Xss) is a different failure mode from OutOfMemoryError: Java heap space (too many long-lived objects the GC can't reclaim, sized by -Xmx) — two separate memory regions, separate causes.

Question 24

Why is String immutable in Java, and how does the String pool relate to that?

Accepted Answer

String is immutable — once created, its internal character data never changes; every "mutating" operation (concat, substring, replace) returns a brand-new String rather than modifying the original. This is deliberate: strings are used pervasively as HashMap keys and shared across threads, and immutability makes them safe to cache and share without defensive copying or synchronization.

Because they're immutable, the JVM can safely intern identical literals into a shared String pool — String a = "hello"; String b = "hello"; gives two references to the exact same pooled object. new String("hello") deliberately bypasses the pool and allocates a fresh object even though its content is identical (which is why you should use .equals(), not ==, to compare strings). For heavy string-building in a loop, prefer StringBuilder — repeated += concatenation is O(n²) in garbage created, since each concat allocates a new String.

Question 25

When would you choose LinkedList over ArrayList in Java, and why does ArrayList usually win anyway?

Accepted Answer

ArrayList is backed by a resizable array — random access by index is O(1), but inserting or removing from the middle is O(n) because following elements shift. LinkedList is a doubly-linked list — insertion/removal at a known node is O(1), but random access is O(n) since it walks the list from an end. ```java List arr = new ArrayList<>(); // fast get(i), slow middle insert List linked = new LinkedList<>(); // fast insert/remove at ends, slow get(i) ``` In practice, ArrayList wins the vast majority of real workloads — better cache locality (contiguous memory) usually beats LinkedList's theoretical insertion advantage, since pointer-chasing through scattered heap nodes is slow on modern CPUs. LinkedList is mostly worth reaching for when you specifically need Deque semantics (fast add/remove at both ends) rather than for its "faster inserts" reputation.

Question 26

How does ConcurrentHashMap achieve thread safety without locking the whole map like a synchronized HashMap wrapper would?

Accepted Answer

HashMap is not thread-safe — concurrent structural modification from multiple threads can corrupt its internal bucket array. ConcurrentHashMap is designed for safe concurrent reads and writes without external synchronization, and does it without locking the whole map: modern versions (Java 8+) use CAS operations for uncontended writes and fine-grained per-bin locking only when there's an actual collision on that bin, so concurrent writes to different buckets never block each other. ```java Map counts = new ConcurrentHashMap<>(); counts.merge("views", 1, Integer::sum); // atomic read-modify-write, no external lock needed ``` Wrapping a HashMap in Collections.synchronizedMap() is not equivalent — it locks the entire map on every operation. And even ConcurrentHashMap doesn't make compound operations atomic unless you use its atomic methods (computeIfAbsent, merge, putIfAbsent) — a plain if (!map.containsKey(k)) map.put(k, v) is still a race, because the check and the put are two separate operations.

Question 27

What is type erasure in Java generics, and what real limitations does it cause?

Accepted Answer

Java generics exist purely at compile time — the compiler uses type parameters to catch type errors and insert automatic casts, but at runtime the type parameter is erased and replaced with Object (or its bound), done for backward compatibility with pre-generics bytecode. The practical consequence: List and List are the exact same class at runtime — list1.getClass() == list2.getClass() is true — so you can't do instanceof List (compile error), and you can't overload two methods that only differ by generic type parameter, since they collide as duplicate erasure signatures. It also means you can't create a generic array directly (new T[10] doesn't compile) since the JVM needs a concrete runtime type for array creation — which is why you'll often see (T[]) new Object[10] with an unchecked-cast warning used to work around it.

Question 28

What is a functional interface in Java, and how do lambdas relate to it?

Accepted Answer

A functional interface is any interface with exactly one abstract method (default and static methods don't count) — that single-method shape is what lets a lambda expression stand in for an implementation without boilerplate. java.util.function ships the common ones ready-made: Function, Predicate, Supplier, Consumer, BiFunction. ```java @FunctionalInterface interface Validator { boolean isValid(T value); } Validator notEmpty = s -> s != null && !s.isEmpty(); Predicate notEmpty2 = s -> !s.isEmpty(); // or use the built-in Predicate ``` Before Java 8, this needed an anonymous inner class — lambdas are syntactic sugar over that same idea (compiled via invokedynamic), letting you pass behavior as a value. @FunctionalInterface is optional but useful: it makes the compiler enforce the single-abstract-method constraint so a future edit can't silently add a second method and break every lambda implementing it.

Question 29

What's the difference between Stream.map() and Stream.flatMap()?

Accepted Answer

map() transforms each element 1-to-1 — you give it a Function and get back a Stream with exactly as many elements as the input. flatMap() is for when each element maps to zero or more elements (because each input itself produces its own stream/collection) — it takes a Function> and flattens all the inner streams into one flat Stream. ```java List> nested = List.of(List.of("a","b"), List.of("c")); // map alone gives a Stream> — still nested nested.stream().map(List::stream); // flatMap gives a flat Stream: a, b, c List flat = nested.stream() .flatMap(List::stream) .collect(Collectors.toList()); ``` A common real use: given orders where each has a List, orders.stream().flatMap(o -> o.getItems().stream()) gives a single flat stream of every item across every order.

Question 30

When should you use an abstract class versus an interface in Java?

Accepted Answer

An abstract class can hold instance state, constructors, and a mix of abstract and concrete methods, but a class can only extend one abstract class — no multiple class inheritance. An interface traditionally could only declare method signatures, but a class can implement any number of interfaces; since Java 8, interfaces can also carry default methods with a body and static methods, narrowing the gap.

```java
abstract class Vehicle {
    protected int speed; // interfaces can't hold instance fields like this
    abstract void accelerate();
    void brake() { speed = 0; } // concrete shared logic
}
interface Flyable {
    void fly();
    default void announceTakeoff() { System.out.println("Taking off"); }
}
```

Rule of thumb: reach for an abstract class when subclasses share real state or implementation in a genuine "is-a" hierarchy; reach for an interface when you're describing a capability multiple unrelated classes might implement — a class can be many things via implements, but only ever one thing via extends.

Question 31

Explain the SOLID principles with a concrete Java example for each.

Accepted Answer

Single Responsibility: a class should have one reason to change — an OrderService that also formats invoice PDFs and sends emails has three unrelated reasons to change and should be split. Open/Closed: code should be open for extension but closed for modification — instead of a big if/else on payment type, define a PaymentStrategy interface and add new payment types as new classes without editing existing ones.

Liskov Substitution: a subclass must be usable anywhere its parent is expected without breaking correctness — Square extends Rectangle overriding setWidth/setHeight to keep sides equal breaks code that assumes setting width alone doesn't change height. Interface Segregation: don't force a class to implement methods it doesn't need — a fat Worker interface with work() and eat() forces a RobotWorker to implement a meaningless eat(); split into role-specific interfaces. Dependency Inversion: high-level modules should depend on abstractions, not concrete implementations — a NotificationService should depend on a MessageSender interface, not directly on EmailSender, so Spring can inject whichever implementation is configured.

Question 32

What is Dependency Injection / Inversion of Control, and why does Spring use it?

Accepted Answer

Dependency Injection is a pattern where a class declares what it needs via constructor or field parameters, rather than constructing those dependencies itself with new — a container (Spring's ApplicationContext) is responsible for constructing objects and wiring dependencies together at startup. This inverts control: instead of your code deciding what concrete implementation to use, the container decides based on configuration.

```java
// without DI — hard to test/swap
class OrderService {
    private final EmailSender sender = new SmtpEmailSender();
}

// with DI — Spring constructs and injects whichever EmailSender bean is configured
@Service
class OrderService {
    private final EmailSender sender;
    OrderService(EmailSender sender) { this.sender = sender; }
}
```

The payoff: you can substitute a mock EmailSender in tests without touching OrderService's code, swap implementations via configuration, and let Spring manage the whole dependency graph's lifecycle instead of every class hand-rolling its own object graph.

Question 33

What's the practical difference between @Component, @Service, @Repository, and @Controller in Spring?

Accepted Answer

All four are specializations of the same base @Component stereotype — Spring's component scan registers all of them as beans identically, so a class annotated @Service and one annotated @Component behave the same as far as dependency injection is concerned. The distinction is mostly semantic, plus a few targeted behavioral extras on the more specific ones.

@Repository adds automatic exception translation — Spring wraps persistence-technology-specific exceptions into its unified DataAccessException hierarchy. @Controller (and @RestController, which adds @ResponseBody) is recognized by Spring MVC's request-mapping machinery to wire up @RequestMapping methods as HTTP endpoints. @Service adds no extra framework behavior beyond @Component — it's purely a convention marking business/domain logic, which still matters for readability and for AOP pointcuts that might target the service layer specifically.

Question 34

Walk through the Spring bean lifecycle from instantiation to destruction.

Accepted Answer

A singleton Spring bean goes through a fixed sequence: the container instantiates it, performs dependency injection (@Autowired fields/setters populated), then calls any @PostConstruct method (or afterPropertiesSet() via InitializingBean) once all dependencies are set — your hook for initialization logic that needs those dependencies already wired. The bean then lives in the container until context shutdown, when @PreDestroy (or destroy() via DisposableBean) runs for cleanup.

```java
@Component
class CacheWarmer {
    @Autowired private ProductRepository repo;

@PostConstruct
    void warmCache() { repo.findAll().forEach(cache::put); } // deps already injected

@PreDestroy
    void shutdown() { cache.clear(); } // runs on graceful context close
}
```

A common mistake is putting initialization logic that depends on injected fields directly in the constructor — field/setter injection hasn't necessarily run yet at that point, so @PostConstruct is the safe place instead.

Question 35

What's the difference between @PathVariable, @RequestParam, and @RequestBody in Spring MVC?

Accepted Answer

@PathVariable binds a value embedded in the URL path itself — used for identifying a specific resource (/orders/{orderId}). @RequestParam binds a query-string parameter or form field — used for optional filters, pagination, or search criteria. @RequestBody deserializes the entire HTTP request body (typically JSON) into a Java object — used for the payload of a POST/PUT sending a whole structured object.

```java
@GetMapping("/orders/{orderId}")
public Order getOrder(@PathVariable Long orderId,
                       @RequestParam(required = false) String view) { ... }

@PostMapping("/orders")
public Order createOrder(@RequestBody CreateOrderRequest request) { ... }
```

The mental model: path variables identify which resource, query params refine how you want it, and the request body carries the data itself for a create/update.

Question 36

How do you make a POST endpoint idempotent so retried requests don't create duplicate resources?

Accepted Answer

An idempotent operation produces the same end result no matter how many times it's applied — GET, PUT, and DELETE are conventionally idempotent by HTTP spec, but POST is explicitly not: retried after a network timeout (client never got the response but the server actually succeeded), it can create a duplicate order, a real and common failure mode when clients retry on timeout. The standard fix is a client-supplied idempotency key: the client generates a unique key once per logical operation and sends it on every retry; the server checks a store (database table or Redis with TTL) for that key before processing — if seen before, it returns the previously-computed response instead of re-executing the side effect. ```java @PostMapping("/orders") public ResponseEntity createOrder(@RequestHeader("Idempotency-Key") String key, @RequestBody CreateOrderRequest req) { Optional existing = idempotencyStore.findResult(key); if (existing.isPresent()) return ResponseEntity.ok(existing.get()); Order order = orderService.create(req); idempotencyStore.save(key, order); return ResponseEntity.ok(order); } ``` The lookup and creation need to happen atomically (or under a short-lived lock keyed by the idempotency key) to avoid a race where two near-simultaneous retries both miss the cache and both create the order.

Question 37

What problem does the circuit breaker pattern (e.g. Resilience4j) solve, and what are its states?

Accepted Answer

When a downstream service is failing or slow, naively continuing to call it wastes threads/connections waiting on a service that isn't going to respond, and can cascade the failure back through your own service. A circuit breaker tracks the recent failure rate of calls and, once it crosses a threshold, "opens" — it stops calling the downstream service for a configured period and fails fast or returns a fallback instead, giving the struggling service room to recover.

```java
@CircuitBreaker(name = "inventoryService", fallbackMethod = "fallbackStock")
public StockLevel getStock(String productId) {
    return inventoryClient.getStock(productId);
}
private StockLevel fallbackStock(String productId, Throwable t) {
    return StockLevel.unknown();
}
```

The breaker cycles through three states: closed (calls flow normally, failures counted), open (calls fail immediately for a configured wait duration), and half-open (after the wait, a small number of trial calls test whether the downstream service has recovered before deciding to close or re-open). Use it anywhere a degraded response is better for overall system health than blocking on a call likely to fail.

Question 38

When would you choose Kafka over RabbitMQ, or vice versa?

Accepted Answer

RabbitMQ is a traditional message broker built around queues — a producer publishes to an exchange that routes to queues, and once a consumer acknowledges a message it's typically removed; it's push-based and excels at complex routing (topic/fanout/direct exchanges) and per-message task distribution. Kafka is a distributed, append-only log — producers append to partitioned topics, messages are retained regardless of whether any consumer has read them, and consumers pull at their own pace tracking their own offset, so multiple independent consumer groups can each read the same topic independently.

Reach for RabbitMQ for classic task-queue/work-distribution patterns where you want smart routing and a message to disappear once handled. Reach for Kafka for high-throughput event streaming, when multiple downstream systems each need their own independent view of the same event stream, or when you need replay — a new consumer joining months later can still read from the start of the log, whereas a consumed RabbitMQ queue is simply gone.

Question 39

How do Kafka partitions and consumer groups affect message ordering and parallelism?

Accepted Answer

A Kafka topic is split into partitions, and Kafka only guarantees ordering within a single partition — there's no ordering guarantee across different partitions of the same topic. Producers typically choose a partition via a key's hash, so all messages with the same key (e.g. the same orderId) always land on the same partition and are processed in order relative to each other, but messages for different keys can be processed in any relative order across partitions.

Consumer groups are how Kafka scales consumption horizontally: each partition is assigned to exactly one consumer within a group at a time, so a group with as many consumers as partitions gets full parallelism — but more consumers than partitions leaves some idle, since a partition can't be split within one group. Multiple independent consumer groups reading the same topic each get their own full copy of the stream. Practical implication: key messages by the entity ID that needs strict ordering, and never assume more consumers than partitions buys more parallelism.

Question 40

What's the difference between the G1 and ZGC garbage collectors, and when would you pick one over the other?

Accepted Answer

G1 (the default collector since Java 9) divides the heap into many equally-sized regions and prioritizes collecting the ones with the most garbage first, running mostly-concurrent marking but with stop-the-world pauses for evacuation — it targets a configurable pause-time goal and typically achieves tens-of-milliseconds pauses, scaling worse as heap size grows into hundreds of GB.

ZGC is a newer, fully-concurrent collector designed to keep pause times effectively constant (single-digit milliseconds) regardless of heap size, even at multi-terabyte heaps, by doing almost all its work — including relocating live objects — concurrently with the application, using colored pointers and load barriers. The tradeoff is throughput and CPU overhead: ZGC's concurrent work costs more CPU than G1's simpler evacuation, so on a smaller heap where G1's pauses are already acceptable, G1 usually has better raw throughput. Pick G1 as the safe default; reach for ZGC specifically when you have a huge heap and pause-time consistency matters more than maximizing throughput.

Question 41

How can a Java application have a "memory leak" if the JVM has garbage collection?

Accepted Answer

The GC reclaims objects no longer reachable from any GC root — it can't reclaim an object still reachable, even if your program logically never needs it again. A "Java memory leak" is almost always an unintentional reference keeping something reachable far longer than intended, not a literal leak of unmanaged memory.

Classic sources: a static List/Map things get added to but never removed from; listener/callback registrations never unregistered, keeping the registering object alive through the listener list; a ThreadLocal set on a thread from a pooled ExecutorService that's never .remove()d, leaking the value for the life of that pooled thread since pooled threads are reused indefinitely. A subtler one: inner (non-static) classes implicitly hold a reference to their enclosing instance, so a long-lived listener defined inside a short-lived object can keep the whole outer object alive. Diagnosing these means taking a heap dump under sustained growth and using a tool like Eclipse MAT to find the dominator object and its GC root path, rather than guessing.

Question 42

What's the difference between synchronized and ReentrantLock in Java?

Accepted Answer

synchronized is a built-in JVM keyword — the JVM manages acquiring/releasing the intrinsic monitor lock automatically, including on exception. ReentrantLock is a class offering everything synchronized does plus extras: tryLock() with a timeout, lockInterruptibly() (a waiting thread can be interrupted), fairness ordering, and multiple independent Condition objects per lock.

```java
private final ReentrantLock lock = new ReentrantLock();
public void update() {
    lock.lock();
    try { /* critical section */ }
    finally { lock.unlock(); } // MUST be manual
}
```

The tradeoff is that ReentrantLock requires manual, disciplined finally-block unlocking — forgetting it leaves the lock permanently held, a bug synchronized structurally can't have. Default to synchronized for simple mutual exclusion; reach for ReentrantLock when you need timeout, interruptibility, fairness, or multiple wait conditions.

Question 43

Why is ThreadLocal dangerous when used with a thread pool, and how do you use it safely?

Accepted Answer

ThreadLocal gives each thread its own independent copy of a variable — useful for per-request context (a request ID, current user) many methods down the call stack need without threading it through every parameter. Internally, each Thread holds a ThreadLocalMap keyed by the ThreadLocal instance, so the value truly lives on the thread itself. The danger shows up with thread pools: a pooled thread is reused across many tasks rather than created fresh and discarded, so a ThreadLocal value set during one request and never explicitly .remove()d stays attached to that pooled thread and leaks into the next task run on the same thread — a memory leak and potentially a real security bug if a security context bleeds into another user's request. ```java private static final ThreadLocal requestContext = new ThreadLocal<>(); void handleRequest(String userId) { requestContext.set(userId); try { process(); } finally { requestContext.remove(); } // mandatory with pooled threads } ``` The fix is always a finally { threadLocal.remove(); } around any code that sets a ThreadLocal, never relying on the value being naturally overwritten by the next task.

Question 44

Explain database transaction isolation levels (READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE) and what anomaly each one prevents.

Accepted Answer

Isolation levels control how much one transaction can see of another's uncommitted or concurrently-committed changes. READ_UNCOMMITTED allows dirty reads — seeing another transaction's uncommitted changes that might get rolled back. READ_COMMITTED (default in Postgres and most Java/Spring setups) prevents dirty reads but allows non-repeatable reads — re-reading the same row twice can return different values if another transaction committed a change in between.

REPEATABLE_READ (MySQL's default) guarantees the same row read twice returns the same value, but can still allow phantom reads — a repeated range query can return additional rows a concurrent transaction inserted and committed in between. SERIALIZABLE is strictest — transactions behave as if run one at a time, eliminating all three anomalies, at the cost of the most locking/contention. In Spring, set this via @Transactional(isolation = Isolation.READ_COMMITTED); default to the database's default and escalate only for the specific operations where a non-repeatable/phantom read would cause a real bug, since stricter isolation directly costs throughput.

Question 45

When would you choose gRPC over a REST/JSON API for a Java backend?

Accepted Answer

REST over HTTP/1.1 with JSON is text-based, human-readable, universally supported, and built around resource-oriented URLs and HTTP verbs — its cost is JSON serialization overhead and HTTP/1.1's per-request overhead, and its contract is usually only loosely enforced. gRPC runs over HTTP/2 with Protocol Buffers — a compact binary format defined by a strict .proto schema that both client and server compile into strongly-typed generated code, so the contract is enforced at compile time on both ends.

```protobuf
service OrderService {
  rpc GetOrder (OrderRequest) returns (Order);
  rpc StreamOrderUpdates (OrderRequest) returns (stream OrderUpdate);
}
```

gRPC also natively supports streaming over a single long-lived HTTP/2 connection, which REST has no first-class equivalent for. Choose gRPC for internal service-to-service communication where performance and strict typed contracts matter and you control both ends; choose REST/JSON for public-facing APIs or anything consumed by browsers and third parties, since gRPC's binary format is much less friendly to ad-hoc debugging and general web tooling.

Question 46

How does distributed tracing help debug latency issues across microservices, and how is it typically implemented in a Java stack?

Accepted Answer

In a microservices architecture, a single user-facing request can fan out through many internal service calls — looking at any one service's logs in isolation doesn't reveal where the problem actually originated when latency spikes or an error occurs. Distributed tracing solves this by propagating a single trace ID through every hop of a request, generated at the entry point and passed along in headers to every downstream call, with each service adding its own timed "span" tagged with the trace ID and its parent span ID, building a full timeline of the request across every service it touched.

In a Java/Spring stack this is typically done via Micrometer Tracing (formerly Spring Cloud Sleuth) instrumenting HTTP clients, @KafkaListeners, and JDBC calls automatically, exporting spans to a backend like Zipkin or Jaeger. The value shows up in a scenario like: an API gateway reports p99 latency spiking to 3 seconds but no single downstream service's dashboard shows anything unusual in isolation — a trace reveals requests correlating in an unexpected pattern (always hitting the same slow replica, or a specific downstream service that's normally fine but occasionally very slow) that no single service's own metrics would surface alone.

Question 47

What is the Saga pattern, and how does it handle failures across multiple microservices without a distributed transaction?

Accepted Answer

A traditional ACID transaction spanning multiple services isn't possible in a microservices architecture — you can't wrap calls to Order, Inventory, and Payment services (each with its own database) in one distributed two-phase-commit without tightly coupling their availability. The Saga pattern breaks a multi-step operation into a sequence of local transactions, each in its own service, where every step has a matching compensating transaction that undoes it if a later step fails — trading strict atomicity for eventual consistency plus an explicit undo path.

There are two implementations. Choreography: each service publishes an event when its local transaction completes, and the next service reacts — no central coordinator, but the flow is implicit and harder to trace. Orchestration: a central saga orchestrator explicitly calls each service in sequence and, on failure, calls compensations in reverse order:

```
1. OrderService: create order (PENDING)  → compensate: cancel order
2. InventoryService: reserve stock       → compensate: release stock
3. PaymentService: charge card
   → if this fails: run compensations for steps 2 then 1, in reverse
```

Orchestration is easier to reason about at the cost of a central component every saga depends on; choreography avoids that but makes the overall flow harder to trace. Either way, every compensating action needs to be idempotent and safe to run even if the original step partially succeeded.

Question 48

What's the difference between StringBuilder and StringBuffer?

Accepted Answer

Both are mutable, resizable character sequences used to build up strings efficiently, avoiding the O(n²) cost of repeated String concatenation — the API is essentially identical (append, insert, delete, reverse). The only real difference is that StringBuffer's methods are synchronized, making it safe to share across threads, while StringBuilder's are not synchronized at all.

```java
StringBuilder sb = new StringBuilder();
for (String s : items) sb.append(s).append(",");
```

Since the vast majority of string-building happens on a single thread — a local variable inside one method — StringBuilder is faster (no synchronization overhead) and is the default choice almost everywhere; StringBuffer is a legacy holdover from before java.util.concurrent existed and is rarely the right tool today.

Question 49

Explain the JVM classloader hierarchy and delegation model, and describe a real scenario where it causes a confusing ClassNotFoundException.

Accepted Answer

The JVM loads classes through a hierarchy that delegates upward before trying itself: the Bootstrap classloader (native, loads core java.*/javax.* classes), the Platform/Extension classloader, and the Application/System classloader (loads your app's classes from the classpath). The default behavior is parent-first delegation: a classloader asks its parent to try first, and only attempts loading itself if every ancestor fails — this guarantees your app can never accidentally shadow java.lang.String, since Bootstrap always gets first shot at anything in java.*.

This matters practically: a ClassNotFoundException for a class clearly on your classpath often means it was loaded by a different classloader than the one currently looking for it (common in app servers or plugin systems with multiple classloader scopes); a NoClassDefFoundError after a class initialized fine once usually means a static initializer threw on a later attempt, and the JVM caches that failure. Frameworks needing dynamic plugin loading (app servers, OSGi, Spring Boot's layered classloader for nested JARs) break strict parent-first delegation deliberately, implementing child-first or isolated hierarchies so a plugin can bundle its own version of a library different from the parent's classpath — the tradeoff is the added complexity of reasoning about which classloader loaded which class.

Question 50

Why is synchronizing on an autoboxed Integer or Long a subtle concurrency bug?

Accepted Answer

Java caches boxed Integer/Long values in the range -128 to 127 (via valueOf()), so two separately-boxed values with the same small number are frequently the same cached object — but outside that range, autoboxing creates a brand-new object every time, meaning two threads that each independently box the same numeric value are actually synchronizing on two different monitor objects and get zero mutual exclusion between them. ```java class Counter { private final Map counts = new HashMap<>(); void increment(Long accountId) { synchronized (accountId) { // DANGEROUS: two different Long objects, same value counts.merge(accountId, 1, Integer::sum); } } } ``` If accountId comes from two different call sites, they're distinct Long objects once outside the cached range, so this "looks" like per-account locking but provides no real exclusion for the same logical account. The fix is to never lock on an autoboxed value — use a dedicated, per-key lock object explicitly managed (e.g. a ConcurrentHashMap of lock objects, or Guava's Striped), or push the concurrency control into the database (SELECT ... FOR UPDATE) instead of relying on in-process object identity.

Backend (Java) Interview Questions & Answers

Ready to practice these live?