多租户程序里每个租户连自己的 DB,连接池如果不加约束会无界增长。再看的方案，

• LinkedHashMap 实现 LRU,key=tenantId:dsName
• 上限 个池,超了淘汰最久未访问的
• 双锁分离:池命中走 synchronized 内的 map.get。池未命中走"锁外建池 → 再加锁决策"避免阻塞其他租户
• 关闭/淘汰用 closeQuietly 在锁外执行,因为 HikariCP close 会走网络 IO

最坏情况的观点是，池 × 连接 = 连接。不过，需要 PgBouncer 或调大 PG max_connections。

一、为什么不能"每个租户一个 DataSource Bean"

痛点：启动慢、内存常驻、运维难度高、OOM 风险。

最朴素的多租户做法:Spring 容器里给每个租户注册一个 @Bean DataSource。

1. 启动慢：- 每个 HikariCP 池初始化要建 个连接 × N 租户 = 启动等几分钟。
2. 常驻内存：- 租户即使一年不来一次连接池也常驻 + 维持心跳。
3. 运维静态：- 新租户入驻必须重启应用才能注册 Bean，违反 SaaS 多租户主要诉求。
4. OOM 风险：- 租户 × 每池几 MB 元数据 → 直接吃掉一台机器的堆。

至于正确姿势。按需创建 + LRU 淘汰

租户来了再建池，长期不来就关掉，既节省资源又提高可 性。

二、数据结构选型：为什么是

容器对比表格

Caffeine.maximumSize
异步淘汰，不能精确控制关池时机。

。原因如下：

• 零依赖：PGA 已使用 Caffeine 做两级缓存，但那是缓存对象，而不是资源生命周期管理，这里无需再引入 Caffeine 等库。
• Tolert 时机可控：Caffeine 的异步淘汰可能导致实际 pool 未及时销毁，而 LinkedHashMap 在你调用 evict 时可以立即从 map 中移除并关闭对应 HikariPool。
• : get 时会将节点移动到链尾。使得 iterator.next 即为最久未访问元素，逻辑直观且易于验证正确性。

代价 & 并发处理说明

• 非线程安全:- 所有操作都包裹在 synchronized 块内，以保证 map 的一致性和 LRU 顺序正确性。但由于只有单次 get/put 操作，它对整体吞吐率影响极小，可接受。

  
  private final Map pool =
  new LinkedHashMap<>;// accessOrder=true
  

三、并发设计：双锁分离 + 锁外建立

单锁实现

public synchronized DataSource getOrCreate {
HikariDataSource ds = pool.get;if return ds;ds = build，// ← 在锁内建池
pool.put;return ds，}

这种写法会把整个建立过程放在 synchronized 内。引起"慢租户卡住所有其他租户",成为灾难级故障。

双锁分离方案 
public DataSource getOrCreate {
String key = buildKey;老实说，// 快方法：命中缓存
synchronized {
HikariDataSource existing = pool.get;if ) {
return existing;}
}
// 慢方法：无锁建立
HikariDataSource built = build;// 第二次加锁：防止重复建立
synchronized {
HikariDataSource winner = pool.get;if ) {
log.debug;closeQuietly;// 锁外 close
return winner;说起来，}
pool.put;不过，enforceCapacity;return built;
}
}



第一段加锁：只做一次 map.get，纳秒级别。

第二段无锁建立：HikariCP 初始化和网络 IO 全部放在锁外执行，不会阻塞其他租户请求。不过，这正是 “网络 IO 永远不要在 synchronized 内跑”的经验！从**痛点**来看，若把网络 IO 放进 lock 内。一个慢速或跨地域的 tenant 能让整个程序挂起数秒甚至更久！按理说，**解决**这方面。所有耗时 I/O 都必须置于 lock 外处理。
**第二段加锁：
检查是否已有同一键的数据源，如果已经存在则丢弃刚创建的新实例。并回收资源，从而避免了 “同一个 key 建了两份 DataSource 导致泄漏 ” 的 bug。至于**痛点**，若没有此检查，在极端并发下可能出现两个相同 tenant 同时创建两个不同 Pool 并覆盖彼此。使其中一个永远无法被回收，引起堆泄漏和连接浪费。从**解决**来看，第二次加锁实现去重。即使产生了偶发 “建完即删”的浪费，也远低于资源泄漏风险。
*close* 通常也在 **lock 外** 执行——除非是刚刚创建但未使用的临时 Pool。此时 close 很快，不会产生长时间等待。但对于真正需要被淘汰或失效的旧 Pool，为避免阻塞正在使用中的连接，需要先把它们从 map 中移除。再解耦 lock 外执行 close，以确保不会因等待 long-running query 而让所有其它 Tenant 被卡住。

五、LRU 淘汰 &amp，amp;amp，&amp，&&，&&，&&，&&bsp，
java
private void enforceCapacity {
while > maxPools) {
Iterator it =
pool.entrySet.iterator;if ) break，怎么说呢，
 Map.EntryE oldest = it.next;it.remove，log.info("DataSource 池超过上限 {}。LRU 淘汰 key={}",maxPools,oldest.getKey);closeQuietly,oldest.getKey);
}
}


bypass network I/O in loop—closing is done outside critical section for old pools except when necessary.

六、上限设置来自何处？
yaml
connector:
datasource-pool:
max-pools: # 池数上限
per-tenant-max-connections: # 每池连接数
该上限不是随意设定，而是基于目标 DB 的 `max_connections` 值反推得到：


PG 默认 max_connections= 调整到足够大以支持应用层多套 Pool 并发请求；其实，

计算公式

真实 DB 连接数 ≈ max_pools × per-tenant-max-connections × 应用实例数
如果 DB 限制不足。则 `max-pools` 必须降至更低值，否则将导致 OOM 或数据库拒绝服务。如果采用 PgBouncer。则可以显著降低 `max-pools` 对 DB 性能的影响，但这属于另一篇讨论范围。


七、配套事件失效机制



场景
本 JVM
跨 JVM




Admin 改配置 / 删除 Tenant / 换密码
Spring ApplicationEvent
Redis Pub/Sub




为什么要使用 AFTER_COMMIT？


防止事务回滚后错误地提前关闭或失效资源；

保证「DB 真改成功」→「本地资源失效」语义一致。


跨实例失效必须靠 Redis Pub/Sub

Spring Event 单机有效，多实例部署下只能通过广播机制传播变更。


八、容量规划 —

建议按公式预估 worst-case:


真实 DB 连接数 ≈ max_pools × per‑tenant‑max‑connections × 实例数


监控指标这方面，


enforceCapacity 次数 → 表示 LRU 淘汰频率；

单 tenant getOrCreate 平均耗时 → 建立频率 / 缓存命中率；

HikariCP pendingThreads → 表示每个 tenant 是否需要更多连接。


这些指标已通过 ConnectorMetrics 暴露给 Promeus。


九、经验


网络 I/O 永远不要在 synchronized 内跑 —— 即使是一次建立或关闭 Pool，也要放到 lock 外执行。

LRU 容器选型看是否能精确控制淘汰时机 —— 对资源生命周期管理而言，“想关就关”的精确性很关键。

事务边界外的失效要用 AFTER_COMMIT —— 防止事务回滚导致状态不一致。

本进程一致性与跨进程最终一致性是两套机制 —— Spring Event + Redis Pub/Sub 两者互补，共同保证全局状态同步。

双锁分离+两阶段 evict+AFTER_COMMIT+LRU 上限不是 over-engineer，而是真正应对多租户场景所必需的技术手段。



写在最终
多租户 DataSource 池是个No silver bullet engineering problem.\
选择 PgBouncer 把问题迁移到数据库层面是一种思路。也可以自己在应用层管理生命周期，以承担这篇文章所描述复杂度。

: enterprise‑connector