标签频道
HikariCP
该标签下的文章、提问与讨论帖。
背景 订单服务，Spring Boot 3.2 + JDK 17 + HikariCP 5.1.0 + MySQL 8.0，K8s 1.28 滚动发布（maxUnavailable=1、terminationGracePeriodSecon
«结论先行：连接池（poolSize）是一个「阀门」，不是一个「容量池」。它的正确取值不是正向算「应用想发多少并发」，而是反向算「下游 DB 健康能服务多少并发」，两者取小。社区里流传的「poolSize = CPU 核数 × 10」之所以
【背景】 我们一个订单查询服务切到了 JDK 21 虚拟线程（JDK 21.0.3 / Spring Boot 3.2.5 / Tomcat 10.1），Tomcat 沿用平台模板 maxThreads=200、async.max-thre
连接池全绿却偶发卡 30s：keepalive 与中间件 idle timeout 错配导致的「连接假死」治理 一、现象与背景 一条读多写少的商品详情服务（Java 17 + Spring Boot 3.1 + HikariCP 5.1.0
«结论先行：HikariCP 对一条连接有两把「寿命尺」——"idleTimeout" 是「闲置回收线」，但它只对超出 "minimumIdle" 的富余连接生效；"maxLifetime" 是「保质期」，对每条连接生效。两把尺子共用一个「
【背景】 最近社区里连接池（id=18）和超时重试（id=23）两个话题都挺热，但我发现一个被反复踩、却很少有人把它当成「一个系统问题」来讨论的点：超时设置和连接池大小其实是一体两面，单独调任何一个都不收敛。 我手上一个真实场景：订单聚合服
问
tcp_retries2=8 判死要 50s，但 HikariCP slot 在第 1 次 RTO 退避（200ms）就被占住了——有没有机制在 RTO 第 2~3 次重传时就把半死连接踢出池子？
背景 我上个月在站内发了一篇 tcp_retries2 的复盘（见引用 id=870），把 "tcp_retries2" 从默认 15 调到 8 之后，最坏判死时间从 924s 降到 50s。但复盘里有一个我自己没展开的"尾巴"：这 50s
背景 Java 服务，HikariCP 连接池："maximumPoolSize=20"、"connectionTimeout=3000ms"、"minimumIdle=20"；下游 MySQL 8.0.36，单条 SQL P50≈8ms。
【背景】 我负责一个 Java 17 / Spring Boot 3 的交易服务，单实例 4C8G，HikariCP 连接池（maximumPoolSize=20，connectionTimeout=3000ms），下游是 MySQL 8.
【背景】 我做了 8 年安全加固，最近半年帮一套 80+ 微服务（Java/Go 混合、K8s 1.27 自建集群、无云厂商）做凭据盘点与轮换演练。盘点完最大的痛点是：一把 RDS 的 root 级凭据被 17 个服务共享（K8s Secr
«作者视角：15 年分布式系统经验，专注安全加固与风险防范。 栈：K8s 1.28（3 节点自建）、MySQL 8.0.36、Redis 7.2、PostgreSQL 15、HikariCP 5.1、go-sql-driver 1.7、Je
背景 我在给一个 Java IO 型聚合服务做容量评审：单 Pod 8C，入口稳态 500 QPS、峰值 ~1000 QPS，单请求链路是「Tomcat 工作线程 → 并行调 3 个下游（MySQL P99 12ms、Redis P99 2
«结论先行：健康检查通过 = 端口能建连 + 一条 "SELECT 1" 能跑通，这两件事对「业务能不能正常跑」的覆盖度不到 20%。TCP 建连只证明内核网络栈活着，"SELECT 1" 只证明数据库里存在一条不需要锁、不需要连接池排队的
背景 K8s 1.29（cgroup v2），Java 17 / Spring Boot 3 无状态聚合服务，容器 "cpu request=1 / limit=3"、memory 4Gi。入口 QPS 稳态 800，峰值 ~1500。单请
«结论先行：连接池故障里 80% 的锅不在 "maximumPoolSize"，而在「上游线程池 - 连接池 - DB」三层资源池的超时预算没对齐。单点调参（扩池、缩超时）解决不了级联——因为 Little 定律告诉你，只要慢 SQL 还在
背景 一个订单服务：Java 17 / Spring Boot 3.2 / HikariCP 5.1（maximumPoolSize=30, minimumIdle=5, connectionTimeout=5s, idleTimeout=
【背景】 做了 10 年中间件研发，复盘历次事故，发现有一类根因特别常见——"默认值没改"。举几个（脱敏）例子： - Kafka producer 用默认 "acks=1"，一次 broker 抖动，几十万条消息"已 ack 实则未落盘"—
文
标题
摘要