Semaphore控制的是“获取连接”操作的并发线程数，而非连接池物理连接数，需与连接池最大连接数匹配，且必须在finally中release许可以防泄露。
用 Semaphore 控制数据库连接池的并发访问量，核心是把“获取连接”操作变成受信号量许可限制的临界行为——不是靠连接池自身限流（如 HikariCP 的 maximumPoolSize），而是额外加一层**业务级并发闸门**，适用于需要精细控制某类操作并发数的场景（比如避免突发查询压垮下游 DB 或第三方接口）。
为什么不用连接池自带的大小限制？
连接池的 maximumPoolSize 管理的是物理连接数量，而 Semaphore 控制的是**同时发起连接请求的线程数**。两者作用层次不同：
- 连接池满时，新请求会阻塞或失败（取决于配置），但阻塞本身仍占用线程资源；
-
Semaphore可在更早阶段拒绝或限流请求（例如直接返回降级响应），避免线程堆积、减少上下文切换开销。
典型使用方式：包装 getConnection()
不直接调用数据源的 getConnection()，而是封装一层带信号量守门的代理方法：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
private final Semaphore connectionPermit = new Semaphore(10); // 最多10个并发获取连接请求
private final DataSource dataSource;
public Connection acquireConnection() throws SQLException {
try {
// 尝试获取许可，最多等待2秒，超时则抛异常或走降级
if (!connectionPermit.tryAcquire(2, TimeUnit.SECONDS)) {
throw new SQLException("Too many concurrent connection requests");
}
return dataSource.getConnection();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new SQLException("Interrupted while waiting for connection permit", e);
}
}
public void releaseConnection(Connection conn) {
try {
if (conn != null && !conn.isClosed()) {
conn.close(); // 归还给连接池
}
} catch (SQLException ignored) {
} finally {
connectionPermit.release(); // 务必释放许可，无论成功失败
}
}
关键细节和注意事项
-
许可数 ≠ 连接数：设
Semaphore(10)表示最多 10 个线程能同时执行getConnection()，但每个线程拿到的连接可能来自池中任意空闲连接，甚至复用； -
必须配对 release：在
finally块中调用semaphore.release()，否则许可泄露，后续所有请求都会被阻塞； -
不要和连接池的 max size 冲突：若连接池只配了 5 个连接，但 Semaphore 放行 20 个线程，会导致大量线程卡在
getConnection()阻塞，失去限流意义；建议 Semaphore 许可数 ≤ 连接池最大连接数； -
考虑公平性：如需严格 FIFO，构造时传
true：new Semaphore(10, true)，但会带来额外性能开销，一般非必要不开启。
结合实际场景的增强思路
单纯用 Semaphore 是静态阈值，生产中常配合动态调节或监控：
立即学习“Java免费学习笔记（深入）”；
- 用
AtomicInteger统计当前活跃请求数，暴露为 Prometheus 指标； - 通过 Actuator 端点或配置中心动态调整
Semaphore的许可数（需重新初始化或设计可刷新的 wrapper）； - 对特定高危 SQL（如报表导出）单独配一个专用
Semaphore，和其他业务隔离。
不复杂但容易忽略：Semaphore 控制的是“申请连接”这个动作的并发，不是连接本身的使用时长。真正要防慢查询拖垮系统，还得配合 query timeout、连接超时、连接泄漏检测等机制一起用。
