容器化部署时不能直接按宿主机CPU核数设连接池大小，因availableProcessors()常返回宿主机总核数，导致maximumPoolSize被高估；应优先读取cgroups v1/v2接口获取真实CPU配额，结合数据库max_connections反推合理上限，并通过压测与监控闭环验证。
容器化部署时不能直接按宿主机 CPU 核数设连接池大小，因为 Runtime.getRuntime().availableProcessors() 在 Docker/K8s 中常返回宿主机总核数，导致 maximumPoolSize 被高估，连接争抢加剧甚至触发数据库连接拒绝。
看容器实际可分配 CPU 资源
优先读取 cgroups v1/v2 接口获取真实 CPU 配额，而非依赖 JVM 默认探测：
- Linux 容器中检查
/sys/fs/cgroup/cpu.max（cgroups v2）或/sys/fs/cgroup/cpu/cpu.cfs_quota_us与cpu.cfs_period_us（v1），计算有效核数 =quota / period，向下取整 - Kubernetes 场景下，若设置了
resources.limits.cpu: "2"，则上限为 2 核；若设为"2000m"，同样按 2 核处理 - Java 应用启动时可通过系统属性显式覆盖：
-Djava.util.concurrent.ForkJoinPool.common.parallelism=2 -XX:ActiveProcessorCount=2
结合数据库连接能力反推上限
连接池最大值不是由应用单方面决定的，必须匹配数据库侧的并发连接承受力：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- MySQL 默认
max_connections=151，生产环境通常设为 1000~3000；PostgreSQL 常设max_connections=200~500 - 一个服务实例的
maximumPoolSize建议 ≤ 数据库单实例总连接数 ÷ 同集群中该服务副本数 × 0.8（留缓冲） - 例如：MySQL 总连接上限 2000，K8s 部署 10 个 Pod，则单 Pod 的
maximumPoolSize不宜超过2000 ÷ 10 × 0.8 = 160
用压测+监控闭环验证
静态估算只是起点，真实水位需靠线上可观测性反馈：
立即学习“Java免费学习笔记（深入）”；
- 接入 HikariCP 暴露的 JMX 或 Micrometer 指标，重点关注
HikariPool-1.ActiveConnections、HikariPool-1.IdleConnections、HikariPool-1.PoolUsage - 压测时观察 P95 连接获取耗时是否突增（> 50ms）、是否有大量
connection-timeout日志，说明池子已成瓶颈 - 若空闲连接长期 > 80% 且活跃连接峰值 maximumPoolSize 过大，浪费资源并增加 DB 压力
适配弹性扩缩容场景
在 K8s HPA 自动伸缩下，连接池不能固定配置，需运行时响应变化：
- 通过 ConfigMap/Consul/Nacos 动态下发
maximumPoolSize和minimumIdle，应用监听变更后调用HikariDataSource.setMaximumPoolSize()热更新（HikariCP 支持） - 避免“一扩就满”：新 Pod 启动时，
minimumIdle应设为 0 或极小值（如 1），待流量导入后再逐步预热 - 缩容前主动 drain：监听 K8s termination signal，调用
HikariDataSource.evictConnections()清理空闲连接，减少对 DB 的瞬时冲击
