A beginner-first guide to java.util.regex: Pattern and Matcher, named groups, flags, lookarounds and replaceAll with a lambda, then the failure mode. Measured on JDK 25: which patterns still blow up exponentially, what the JDK already defuses, and fixes that work (rewriting, possessive quantifiers, atomic groups, a CharSequence timeout, input limits).
How Java exceptions really work, measured on JDK 25: cause chaining, checked vs unchecked, try-with-resources suppressed exceptions, JMH numbers for stack-trace capture (with and without writableStackTrace), and why HotSpot sometimes removes the trace for you.
40 Java concurrency interview questions, from race conditions to ScopedValue's exact child-thread inheritance rules. The four trickiest get fresh, verified code and real captured output; the rest link to this site's own deep dives that already proved their claims.
shutdown() vs shutdownNow(), the graceful two-phase pattern, and the JDK 19 AutoCloseable shortcut that runs it for you - plus real numbers for newVirtualThreadPerTaskExecutor() and the exception submit() silently swallows if nothing ever calls Future.get().
CountDownLatch, CyclicBarrier, and Phaser implement the same three-round pipeline three ways - reuse semantics, dynamic registration, and a timeout that permanently breaks one of them but not the others. Semaphore solves a genuinely different problem.
JEP 491 fixed synchronized-block pinning, not native-frame pinning. A real JNI reproduction, the jdk.VirtualThreadPinned JFR event's exact fields, reading pinned vs unmounted threads from a jcmd dump, the measured throughput cost, and a bounded-executor fix.
AtomicLong, LongAdder, and hand-written VarHandle CAS loops benchmarked against synchronized and ReentrantLock, plus a real, deterministically-forced ABA race against a Treiber stack and the AtomicStampedReference fix.
Three ways to guard the same counter, benchmarked with JMH on JDK 25: what the fair ReentrantLock's FIFO handoff actually costs under contention, why StampedLock's optimistic read wins a 9:1 read-heavy workload by over 20x, a real deadlock resolved live by tryLock's timeout, and a JDK21-vs-JDK25 side-by-side proving JEP 491 stopped synchronized from pinning virtual threads.
Why the classic double-checked-locking singleton breaks without volatile, what the Java Memory Model's happens-before rules actually guarantee, and a real jcstress campaign (5+ billion samples) that reproduces the unsynchronized publish, the volatile fix, and the final-field safe-publication guarantee side by side.
Moving a Spring application from Spring Kafka 3 to 4 looks like a version bump. It is three changes at once: the Kafka client itself jumps to 4.x, Spring Boot 4 stops configuring Kafka unless you use a new starter, and the JSON serializer you probably use is built on a Jackson that Boot 4 no longer puts on your classpath. This article migrates one small app and shows what each of those does when it goes wrong. You need to know what a Kafka topic, a producer and a consumer are. Everything else is explained as it appears. Versions tested. Before: Spring Boot 3.5.16, Spring Kafka 3.3.16, kafka-clients 3.9.2, JDK 21. After: Spring Boot 4.1.1, Spring Kafka 4.1.1 (latest GA), kafka-clients 4.2.1, JDK 25.0.4.1. Spring Kafka 4.2.0-M1 and M2 are milestones and were not tested. Date: 28 September 2026. Companion code: spring-messaging-demo/kafka4-migration.