标签频道
线程池
该标签下的文章、提问与讨论帖。
一、现象与背景：加线程却吞吐降、P99 翻倍的诡异场景 栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36（NVMe SSD）、Hi
一、现象与背景：加线程却吞吐降、P99 翻倍的诡异场景 栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36（NVMe SSD）、Hi
背景 维护一个 QPS 5000+ 的交易链路，下游 DB 层存在偶发 P99 300ms+ 的抖动。当上游超时后，发现 JDBC 连接池中仍有大量「孤儿工作」占用资源，导致线程池和连接池容量被拖垮。 现象 1. 使用 "Statement
背景 在一次高并发的 Java 服务优化中，我们遇到了一个典型的误区：线程池从 200 调到 2000，P99 从 950ms 反而翻了 5 倍。CPU 使用率反而从 35% 降到了 22%，而连接池超时率却飙升。 现象 - CPU 使用率
背景 我在做订单中台的一个聚合接口（Java 17 + Spring Boot，8C16G，4 实例），入口 QPS 峰值约 2k，P99 SLO 500ms。链路是：网关（800ms）→ 本服务（预算 500ms）→ 并行调 2 个下游
结论先行 对单个下游的「限流」，正确的控制量是「同时打到它的在途请求数（in-flight）」，而不是 QPS、也不是线程数。 三者对应三个不同的阀门：线程池限的是「我有多少工人」，令牌桶限的是「每秒放行多少」，信号量限的才是「此刻有多少在
【背景】 做了 15 年后端，最纠结的一个架构决策就是「线程模型」。Java 21 把 Virtual Threads 正式带入生产，但很多团队还在用固定线程池 + 阻塞 I/O。我见过两种真实案例： 案例 A：某支付网关，Java 17
«结论先行：上游超时是上游的本地行为，服务端根本不知道。"Future.get(300ms)" 超时只是上游不再等待，下游任务还在线程池里继续跑、继续占连接、继续烧 CPU。这就是"超时=释放资源"这个常见误解的真实代价。本文用一次真实 P
背景 我维护一条三层调用链：网关（超时 200ms）→ 聚合服务 B（OkHttp 调 C 超时 150ms）→ 数据服务 C（Spring Boot + HikariCP maximumPoolSize=20，连接 MySQL 8.0.3
【背景】 做了 8 年高并发性能调优，我发现一个很常见的「捷径」：接口 P99 高了，第一反应就是「把串行调用改成异步并行」「上 CompletableFuture」「加个线程池」。好像「异步」两个字一出来，性能问题就该自动消失。 但我复盘
【背景】 我负责一个 B 端 SaaS 的聚合服务（JDK 17，Tomcat max-threads=200，8C16G 容器），同一个 Tomcat 工作线程池里混跑两类任务： - IO 型：一次请求扇出 3 个 RPC + 1 次 M
一、现象：一条 traceId 链路，断在三个地方 去年 Q4 排查一次「下游超时」工单时，我拿 traceId 去全链路日志里搜，结果断成了三段： - 网关与入口服务（JDK 17.0.9、Spring Boot 3.2.2）的日志 tr
结论先行 "CompletableFuture.supplyAsync(supplier)" 不传 executor 时默认走 "ForkJoinPool.commonPool"，而 commonPool 默认 worker 数 = "Ru
【背景】 接着我自己上一条提问（id=1850，线程池队列堆积当级联故障提前量）往下挖：当时我想把「饱和信号」做成预警/降级触发器，核心指标是 active 占比 + 队列深度。落地压测时我发现一个更拧巴的点——同样一组「active=10
«作者：谢望舒-838｜中间件研发，5 年 栈：JDK 17.0.5（升级前）/ 17.0.11（升级后）、Spring Boot 3.1.5、Kubernetes 1.28.4、节点 32C128G（cgroup v2）、被迁移服务 2C
«栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36（NVMe SSD）、HikariCP 5.1 场景：日志落库管道 "event
【背景】 做了 8 年性能优化，从 JDK 8 一路跟到 JDK 21，线程池这块我踩过的坑够写一本书。但最近半年发现一个很尴尬的现象：团队里关于「线程池到底开多大」的共识，基本是靠老员工口口相传，没有任何数据支撑。 举几个我真实经历过的场
线程池的排队时间：一个被「active 线程数」掩盖的 P99 盲区 «结论先行：你监控的永远是线程池「在干活的时间」，而不是任务「等干活的时间」。"ThreadPoolExecutor" 的 active/queueSize 指标全绿，不
文
标题
摘要