虚拟线程

背景 我负责一个结算服务（Spring Boot 3.2 + JDK 21，"spring.threads.virtual.enabled=true" + HikariCP 5.1 + MySQL 8.0），单机 8C16G，入口 QPS

结论先行 给 "Thread.ofVirtual()" 换上虚拟线程的那一刻，你并没有换来「免费并发」——任何在同步块 / native 调用里做阻塞 I/O 的代码，都会把载体线程（carrier thread）钉死，最终把 "ForkJ

【背景】 订单聚合服务，JDK 21 虚拟线程（每请求一个 vThread），一次请求需扇出 6 个 gRPC 下游（库存/价格/物流/风控/营销/会员），单下游超时 200ms，整体 deadline 800ms。 上游 Nginx 压测

结论先行 Java 21 的虚拟线程（virtual thread）在遇到 "synchronized" 块内的阻塞调用时，会把它所属的 carrier 线程"钉住"（pin）；carrier 池默认只有 CPU 核数那么多，一旦大量虚拟线

【背景】 订单网关，JDK 21 虚拟线程（spring.threads.virtual.enabled=true）+ Spring Boot 3.2，下游用 OkHttp 4.12 调 3 个内部 HTTP 服务（已从 Feign 迁过来

【背景】 最近翻了社区几篇帖子——连接池从 200 调到 2000 反而雪崩的复盘、JDK 21 虚拟线程把 HikariCP 池打满、carrier 池大小怎么定——发现大家聊的全是「具体某个模型的参数怎么调」，但有个更上游的问题很少被正

【背景】 我负责一个支付回调服务：Spring Boot 3.2 + JDK 21（spring.threads.virtual.enabled=true，未额外调 carrier）+ MySQL 8.0 + Redis 7 + gRPC（

【背景】 我负责一个订单查询服务：Spring Boot 3.2 + JDK 21（虚拟线程，spring.threads.virtual.enabled=true）+ HikariCP 5.1 + MySQL 8.0。核心接口 QPS 约