标签频道
虚拟线程
该标签下的文章、提问与讨论帖。
【背景】 在 JDK21 引入虚拟线程（Virtual Threads）后，Tomcat 的 maxThreads 配置似乎变得形同虚设，因为虚拟线程可以轻松创建成千上万的线程。然而，这种看似无限的并发能力是否真的能带来性能的全面提升？ 【
【背景】 我们一个订单查询服务切到了 JDK 21 虚拟线程（JDK 21.0.3 / Spring Boot 3.2.5 / Tomcat 10.1），Tomcat 沿用平台模板 maxThreads=200、async.max-thre
【背景】 做了 15 年后端，从 Servlet 3.0 的 @Async 一路写到 Spring WebFlux、Project Reactor，最近又看到 Java 21 虚拟线程把「异步」重新定义了一遍。我手上现在同时维护两套服务：
结论先行 CPU 不饱和（55%~65%）+ 下游 P99 < 80ms + ZGC pause < 2ms + HikariCP pending ≈ 0，但本服务 P99 从 120ms 间歇性飙到 900ms——大概率是 carrier
背景 我维护一条三层调用链：网关（超时 200ms）→ 聚合服务 B（OkHttp 调 C 超时 150ms）→ 数据服务 C（Spring Boot + HikariCP maximumPoolSize=20，连接 MySQL 8.0.3
【背景】 我们一个订单查询服务切到了 JDK 21 虚拟线程（JDK 21.0.3 / Spring Boot 3.2.5 / Tomcat 10.1），Tomcat 沿用平台模板 maxThreads=200、async.max-thre
背景 我负责一个聚合服务（Spring Boot 3 + JDK 21 虚拟线程 + OkHttp5 连接池 maxRequests=200/maxRequestsPerHost=50，单机 8C16G，前置 4 实例），核心接口一次请求并
【背景】 做了 8 年性能优化，从 JDK 8 一路跟到 JDK 21，线程池这块我踩过的坑够写一本书。但最近半年发现一个很尴尬的现象：团队里关于「线程池到底开多大」的共识，基本是靠老员工口口相传，没有任何数据支撑。 举几个我真实经历过的场
【背景】 JDK 21 把虚拟线程推成 LTS 默认能力，Spring Boot 3.2 之后 "spring.threads.virtual.enabled=true" 一行就能把 Tomcat 线程池换成虚拟线程。我这边一个订单聚合服务
【背景】 我负责一个交易聚合服务：Spring Boot 3.2 + JDK 21.0.5（"spring.threads.virtual.enabled=true"）+ HikariCP 5.1 + MySQL 8.0 + Redis，单
背景：最近带团队做服务改造，一个对外接口 QPS 800+，里面要串行调 4 个下游 RPC、一次 DB、一次 Redis，P50 还行但 P99 经常抖到 300ms+。我翻了下现有代码，发现「并发模型」这块其实是一笔糊涂账：有的地方用
【背景】 我负责一个对外查询聚合服务：Spring Boot 3.2 + JDK 21.0.3（"spring.threads.virtual.enabled=true"）+ HikariCP 5.1 + MySQL 8.0，单机 8C16
背景 我负责一个结算服务（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 约
已经到底了
文
标题
摘要