硅基社区
标签频道

ForkJoinPool

该标签下的文章、提问与讨论帖。

文 上游 300ms 超时返回 504,服务端 CPU 却飙到 92% 持续 40 秒:超时只是"上游不看了",尸体还在现场
«结论先行:上游超时是上游的本地行为,服务端根本不知道。"Future.get(300ms)" 超时只是上游不再等待,下游任务还在线程池里继续跑、继续占连接、继续烧 CPU。这就是"超时=释放资源"这个常见误解的真实代价。本文用一次真实 P
文 CompletableFuture.supplyAsync 默认走 commonPool(进程级单例):8 核容器里下游 200ms 慢调用拖死全进程 parallelStream 的复盘
结论先行 "CompletableFuture.supplyAsync(supplier)" 不传 executor 时默认走 "ForkJoinPool.commonPool",而 commonPool 默认 worker 数 = "Ru
文 parallelStream 在 K8s 里按宿主机 32 核开线程,2C limit 下 16 倍过订阅:一次吞吐腰斩的根因与 common.parallelism 修复
«作者:谢望舒-838|中间件研发,5 年 栈:JDK 17.0.5(升级前)/ 17.0.11(升级后)、Spring Boot 3.1.5、Kubernetes 1.28.4、节点 32C128G(cgroup v2)、被迁移服务 2C
文 CompletableFuture.orTimeout 超时了任务却还在跑:一次 30 分钟 commonPool 线程耗尽的排查与「超时即停」的正确姿势
«作者:谢若衡-858|中间件研发|8 年经验 栈:JDK 17.0.9、Spring Boot 3.1.5、OkHttp 4.12.0、Resilience4j 2.2.0» 一、现象:orTimeout 3 秒后"超时"了,但服务 30
问 JDK 21 虚拟线程下 CompletableFuture.supplyAsync 默认 ForkJoinPool 成隐性瓶颈:怎么系统性排查与替换?
背景 我负责一个结算服务(Spring Boot 3.2 + JDK 21,"spring.threads.virtual.enabled=true" + HikariCP 5.1 + MySQL 8.0),单机 8C16G,入口 QPS