Java

The symptom is always the same: heap usage climbs a little every day, GC reclaims less and less, and eventually someone sets a cron to restart the service at 3 AM. The heap dump shows nothing obviously wrong — no giant cache, no runaway collection. Just thousands of ordinary objects that should have died with their requests, all reachable through one path: Thread → ThreadLocalMap → Entry. This is the ThreadLocal leak, and it’s the quietest memory leak in Java. ...

“How does HashMap work?” opens half of all Java interviews. Most candidates answer “array of linked lists, O(1) lookup” — and then the follow-ups start, and the room gets quiet. The interviewers aren’t testing whether you’ve memorized the structure. They’re testing whether you know why it’s built the way it is. Here are the questions that expose shallow knowledge, with the answers that don’t. Question 1: Why does HashMap mangle your hashCode? Everyone knows hashCode() feeds the map. Almost nobody asks what HashMap does to it first: ...

You migrated to Spring Boot 4. The app boots. Then a RestClient call starts blowing up on payloads that carry explicit nulls for primitive fields — even though your ObjectMapper config disables FAIL_ON_NULL_FOR_PRIMITIVES (your clients send those nulls; Jackson 2 let them through). You stare at the config bean. It’s right there. It’s also completely ignored — and Jackson 3 flips that feature to fail-by-default, so the new default silently takes over. ...

Two pointers is the highest-ROI technique in coding interviews. The entire playbook is one idea: two indices walk through the data, and at each step a decision rule tells you which one moves. No extra arrays — O(1) extra space in nearly every pattern, usually O(n) time. Interviewers love it because it tests whether you can discard search space, not just whether you can code. Five patterns cover nearly every two-pointer question you’ll meet. Learn the decision rule for each, not just the code. (One honest exception up front: the sliding-window pattern trades O(alphabet) space for its single pass — the cheat sheet says so. Everything else is O(1).) ...

Virtual threads (final since JDK 21) made blocking I/O cheap. But cheap threads didn’t fix the hard part: when you fan out to five subtasks and one fails, who cancels the other four? With ExecutorService + Future, the answer is “you, manually, and you’ll get it wrong.” That failure mode — leaked threads, swallowed errors, unobserved work — is what structured concurrency exists to kill. One warning before the code: this API is still moving. Everything below is verified against JEP 533, the seventh preview, targeting JDK 27 — and most blog examples you’ll find online show the obsolete API. Get the status table right first, then the code. ...