Re-uses the platform/virtual-thread transcripts already committed in
virtual-threads-benchmark rather than re-measuring them, and adds a WebFlux
module measured the same way (client-side java.net.http.HttpClient load
generator against a real Netty server). Covers I/O-bound throughput, a
naive-vs-offloaded CPU-bound comparison that turned up a real, counter-
intuitive fact about this sandbox's default thread-pool sizes
(LoopResources.DEFAULT_IO_WORKER_COUNT=4 vs Schedulers.parallel()'s
availableProcessors()=2), and an event-loop-starvation scenario showing
what the naive endpoint actually costs unrelated /io traffic on the same
server. Companion code for the ankurm.com post "Virtual Threads vs WebFlux
vs Platform Threads: Benchmarks and a Decision Framework." Also fixes the
root README's module table, which was missing the virtual-threads-benchmark
row from an earlier commit.
Three replicas of one application against one PostgreSQL database, proving
duplicate @Scheduled execution and then removing it with ShedLock: 24
executions where 8 were due, then 7 for 7 ticks.
Also measured: @SchedulerLock without @EnableSchedulerLock does nothing and
warns about nothing; spring.task.scheduling.pool.size=1 does not starve a
fixedRate job but delays it and fires 35 of 40 executions in a burst; and a
node whose clock is 40 seconds fast takes a live lock unless the provider
uses usingDbTime().
Every @Async behaviour that surprises people, asserted by a test and captured
to docs/output/: the self-invocation trap, what CGLIB cannot override, the
IllegalArgumentException a plain return type throws, the unbounded queue that
makes max-size decoration, spring.task.execution.propagate-context (new in
Boot 4.1.0), the two Executor beans that leave @Async on an unpooled
SimpleAsyncTaskExecutor, and JEP 491 measured on JDK 21 against JDK 25.
Claude
asmhatre