1. 项目概述：为什么一个简单的 DataSource 示例，能成为 Java 后端开发者的“照妖镜”

你有没有在面试时被问过：“说说你用过的 DataSource 实现？HikariCP 和 Druid 的连接池参数怎么调？”或者在上线前一小时，突然发现服务启动报错 Could not open JDBC Connection ，日志里只有一行 Caused by: java.sql.SQLException: Access denied for user... ，而数据库账号密码明明没改过——最后发现是 spring.datasource.url 配置里少了个 ?useSSL=false ；又或者在压测时，QPS 上不去，线程全卡在 getConnection() 上，监控显示连接池活跃数始终是 0，排查半天才发现 maxPoolSize=1 是某位同事手抖写错了。这些不是段子，是我过去十年带团队、做 Code Review、处理线上事故时，反复撞上的真实场景。 DataSource 看似只是 JDBC 规范里一个接口定义，但它实际是 Java 应用与数据库之间那道最脆弱、也最关键的“呼吸阀” 。它不处理 SQL，不解析结果集，却决定了整个应用的吞吐、稳定性和故障恢复能力。今天这篇内容，就从最基础的 JDBC DataSource Example 入手，不讲抽象概念，不堆 API 列表，而是带你亲手搭一个最小可运行的 DataSource 实例，再一层层剥开它背后的真实世界：为什么 DriverManager.getConnection() 在生产环境必须被弃用？为什么 BasicDataSource （DBCP）在 Spring Boot 2.0 后默认消失？HikariCP 的 connectionTimeout 和 validationTimeout 到底谁先触发？当 cnanot determin target datasource 这种报错出现时，问题真的在数据源配置上吗？我会用一个本地 H2 数据库 + 纯 Java SE 环境的完整示例，把每一步的字节码、线程栈、连接状态都摊开给你看。无论你是刚学完 JDBC 基础、正准备 Java 面试的应届生，还是已经用 Spring Boot 写了三年 CRUD、但对底层连接池机制仍停留在“配个 YAML 就完事”阶段的中级开发者，这篇文章都会让你重新理解：那个被 IDE 自动生成、被框架自动注入、被你无数次 Ctrl+C/V 的 DataSource ，究竟是如何在每一毫秒里，默默扛住成千上万次数据库请求的。

2. 核心设计思路拆解：为什么不用 DriverManager？为什么必须用连接池？

2.1 从 DriverManager 到 DataSource：一次代价昂贵的进化

很多初学者写 JDBC，第一反应就是 Class.forName("com.mysql.cj.jdbc.Driver"); 然后 DriverManager.getConnection(url, user, pwd) 。这在单次测试、小脚本里完全没问题，但放到真实业务中，它会立刻暴露出三个致命缺陷：

  • 连接创建成本极高 ：每次 getConnection() 都要经历 TCP 三次握手、MySQL 认证协议交互（发送握手包、接收挑战、计算响应）、初始化会话变量（如 autocommit , character_set_client ）。我实测过，在局域网环境下，一个 MySQL 8.0 连接的平均建立耗时是 8~15ms。如果一个 HTTP 请求需要查 3 张表，那就是 45ms 白白耗在连接上，远超 SQL 执行本身。而 DataSource 的核心价值，就是把“连接创建”这个重操作，变成“连接复用”这个轻操作。

  • 无法控制资源生命周期 ： DriverManager 创建的 Connection 是裸对象，你必须手动 close() ，一旦忘记（比如在 catch 块里没写 finally ），连接就永远留在数据库端，直到超时断开。而 DataSource 提供的 Connection 是代理对象，它的 close() 方法不会真正关闭物理连接，而是将连接归还给连接池，由池管理器统一回收、校验、复用。这是资源安全的基石。

  • 零并发控制能力 ： DriverManager 对并发毫无感知。100 个线程同时调用 getConnection() ，就会产生 100 个独立连接，瞬间打爆数据库的 max_connections 限制（MySQL 默认 151）。而 DataSource 实现（如 HikariCP）内置了线程安全的连接队列、等待超时、连接泄漏检测等机制，它像一个智能交通灯，让线程有序排队、限时等待、超时放弃，而不是一窝蜂冲向数据库。

提示： DriverManager 并未被废弃，它仍是 JDBC 规范的底层入口。但所有成熟的 DataSource 实现（包括 HikariCP、Druid）内部，最终都通过 DriverManager 获取初始连接。区别在于， DataSource 把这个过程封装、优化、监控，而 DriverManager 只是原始工具。

2.2 连接池不是“越多越好”，而是“刚刚好”

新手常犯的错误是：看到连接池有 minIdle 、 maxPoolSize 、 initializationFailTimeout 等一堆参数，就以为调大 maxPoolSize 就能提升性能。这是典型误区。连接池的本质是 内存与数据库资源的平衡器 。调得过大，后果很直接：

  • 应用端 OOM ：每个 Connection 对象在 JVM 里占用几百 KB 内存（包含 Socket 缓冲区、Statement 缓存、元数据缓存）。 maxPoolSize=1000 ，光连接对象就吃掉 200MB+ 堆内存。
  • 数据库端雪崩 ：数据库的连接是昂贵的 OS 资源（每个连接对应一个线程/进程、文件描述符、内存页）。MySQL 单实例 max_connections=500 是常见上限，你一个应用就占 300，其他服务怎么办？
  • CPU 上下文切换激增 ：当大量线程在连接池上等待时，JVM 线程调度器要频繁切换上下文，CPU 时间花在调度上，而非执行业务逻辑。

所以， 合理的 maxPoolSize 必须基于你的应用 QPS、平均 SQL 耗时、数据库能力三者计算 。公式很简单： maxPoolSize ≈ (QPS × 平均SQL耗时) / (1 - 目标CPU利用率) 。例如，QPS=100，平均 SQL 耗时 20ms，目标 CPU 利用率 70%，则 maxPoolSize ≈ (100 × 0.02) / (1 - 0.7) = 6.67 ，向上取整为 8。这就是为什么 HikariCP 默认 maxPoolSize=10 —— 它是一个对大多数中小应用足够安全的起点，而非最优解。

2.3 为什么 HikariCP 成为事实标准？看它如何“偷懒”

HikariCP 的核心哲学是： 用最少的代码，做最确定的事 。它没有 Druid 那样炫酷的 Web 监控页面，也没有 DBCP 那样复杂的配置项，但它在关键路径上做了极致优化：

  • ConcurrentBag 替代 BlockingQueue ：传统连接池用 LinkedBlockingQueue 存储空闲连接， borrow 时 poll() ， return 时 offer() ，都是锁操作。HikariCP 的 ConcurrentBag 使用 ThreadLocal + CopyOnWriteArrayList + SynchronousQueue 三级结构。线程优先从自己的 ThreadLocal 拿连接（无锁），失败再查全局列表，最后才走阻塞队列。实测在高并发下， getConnection() 的 P99 延迟比 DBCP 低 40%。

  • 无反射，全编译期绑定 ：Druid 大量使用反射获取 Connection 属性，HikariCP 全部用 sun.misc.Unsafe 或直接字段访问。这不仅快，更避免了 JDK 版本升级导致的反射失败（比如 JDK 17 的强封装）。

  • “懒校验”策略 ：HikariCP 不在连接归还时立即校验（ isValid() ），而是在下次 borrow 时，用 connectionTimeout 减去已等待时间，动态决定是否校验。这避免了大量无效校验，把开销压到最低。

注意：网上流传的“HikariCP 性能吊打 Druid”是片面的。Druid 的优势在监控、SQL 防火墙、慢 SQL 拦截等企业级功能。如果你只需要高性能连接池，HikariCP 是首选；如果你需要审计和治理，Druid 更合适。选型不是比参数，而是比场景。

3. 实操环节：从零搭建一个可调试、可监控的 JDBC DataSource 示例

3.1 环境准备：用 H2 数据库实现“零依赖”验证

为了彻底剥离 Spring、Maven 等框架干扰，我们用纯 Java SE + H2 内存数据库来构建最小示例。H2 的优势在于：它是一个 JAR 包，无需安装服务， jdbc:h2:mem:testdb 就能启动一个内存库，重启即清空，完美适配快速验证。

<!-- pom.xml -->
<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <version>2.2.224</version>
</dependency>
<dependency>
    <groupId>com.zaxxer</groupId>
    <artifactId>HikariCP</artifactId>
    <version>5.0.1</version>
</dependency>

关键点：H2 的 JDBC URL 格式是 jdbc:h2:[file:|mem:|tcp:]<databaseName> 。 mem:testdb 表示创建名为 testdb 的内存数据库， DB_CLOSE_DELAY=-1 参数确保 JVM 退出时数据库不自动关闭，方便我们观察连接池状态。

3.2 核心代码：手写 DataSource 初始化与连接获取

下面这段代码，就是 JDBC DataSource Example 的灵魂。它不依赖任何框架，每一行你都能在生产环境里找到对应影子：

import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;

import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;

public class HikariExample {
    private static DataSource dataSource;

    // 1. 初始化 DataSource（应用启动时执行一次）
    public static void initDataSource() {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl("jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE");
        config.setUsername("sa");
        config.setPassword("");
        config.setDriverClassName("org.h2.Driver");

        // 2. 关键连接池参数（生产环境必须显式设置）
        config.setMaximumPoolSize(5);           // 最大连接数，根据上文公式计算
        config.setMinimumIdle(2);              // 最小空闲连接数，保证随时有连接可用
        config.setConnectionTimeout(30000);    // 获取连接最大等待时间：30秒
        config.setIdleTimeout(600000);         // 连接空闲10分钟自动回收
        config.setMaxLifetime(1800000);        // 连接最长存活30分钟（防数据库连接老化）

        // 3. 连接有效性校验（防止拿到失效连接）
        config.setConnectionTestQuery("SELECT 1"); // H2 的校验SQL
        config.setValidationTimeout(3000);     // 校验超时3秒，避免拖慢borrow

        // 4. 启用连接泄漏检测（救命功能！）
        config.setLeakDetectionThreshold(60000); // 60秒未归还，打印堆栈

        dataSource = new HikariDataSource(config);
    }

    // 5. 业务方法：模拟一次数据库查询
    public static void queryUser() throws Exception {
        try (Connection conn = dataSource.getConnection()) { // 自动归还
            String sql = "SELECT * FROM users WHERE id = ?";
            try (PreparedStatement ps = conn.prepareStatement(sql)) {
                ps.setInt(1, 1);
                try (ResultSet rs = ps.executeQuery()) {
                    if (rs.next()) {
                        System.out.println("Found user: " + rs.getString("name"));
                    }
                }
            }
        }
    }

    public static void main(String[] args) throws Exception {
        initDataSource(); // 启动时初始化

        // 创建测试表
        try (Connection conn = dataSource.getConnection()) {
            conn.createStatement().execute("CREATE TABLE users(id INT PRIMARY KEY, name VARCHAR(50))");
            conn.createStatement().execute("INSERT INTO users VALUES(1, 'Alice')");
        }

        // 执行查询
        queryUser();
    }
}

这段代码的价值，远不止于“能跑”。它揭示了 DataSource 的真实工作流：

  • initDataSource() 是连接池的“心脏起搏器” ：它读取配置，创建 HikariDataSource 实例，内部会预热 minimumIdle 个连接，并启动后台健康检查线程。
  • dataSource.getConnection() 是“连接分发中心” ：它不是创建新连接，而是从 ConcurrentBag 中借出一个空闲连接。如果空闲连接不足，且当前连接数 < maxPoolSize ，则创建新连接；否则线程进入等待队列。
  • try-with-resources 是“连接回收保险丝” ： Connection 实现了 AutoCloseable ， close() 调用后，HikariCP 会将连接标记为“空闲”，放回池中，而非关闭物理连接。

3.3 深度调试：用 JVM 工具看清连接池的“呼吸”

光跑通不够，我们要看到连接池内部发生了什么。JDK 自带的 jstack 和 jconsole 就是最佳探针。

步骤一：添加 JVM 参数启用 JMX 

java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 \
     -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false \
     -jar your-app.jar

步骤二：用 jconsole 连接并观察 启动 jconsole ，连接本地进程，切换到 MBeans 标签页，展开 com.zaxxer.hikari → HikariPool-1 → Pool 。你会看到实时刷新的指标：

  • ActiveConnections ：当前被业务线程持有的连接数（即正在执行 SQL 的连接）
  • IdleConnections ：空闲在池中的连接数
  • TotalConnections ：池中总连接数（= Active + Idle）
  • ThreadsAwaitingConnection ：正在等待连接的线程数（>0 就说明连接池瓶颈了）

步骤三：制造“连接泄漏”并捕获堆栈 把 queryUser() 方法里的 try-with-resources 改成手动 close() ，并在 finally 块里加个 Thread.sleep(100000) 模拟业务卡死：

Connection conn = null;
try {
    conn = dataSource.getConnection();
    // ... 执行SQL
} finally {
    if (conn != null) conn.close(); // 这里 close() 会被 HikariCP 拦截
    Thread.sleep(100000); // 卡住100秒
}

运行后，60 秒（ leakDetectionThreshold ）一到，控制台会打印类似这样的堆栈：

WARNING: Connection leak detection triggered for connection org.h2.jdbc.JdbcConnection@1a2b3c4d, stack trace follows
java.lang.Exception: Apparent connection leak detected
    at HikariExample.queryUser(HikariExample.java:45)
    at HikariExample.main(HikariExample.java:65)

这行日志，就是你在生产环境定位连接泄漏的黄金线索。它精准指向了哪一行代码拿了连接没还，比看 GC 日志、线程 dump 高效十倍。

3.4 生产级增强：添加监控埋点与优雅关闭

上面的示例是“玩具级”，生产环境必须加上两件事： 监控上报 和 JVM 关闭钩子 。

监控埋点（对接 Prometheus） ： HikariCP 提供了 HikariDataSource.getHikariPoolMXBean() 接口，可以获取所有指标。我们用 Micrometer 封装：

import io.micrometer.core.instrument.Metrics;
import io.micrometer.core.instrument.binder.jvm.JvmMemoryMetrics;
import io.micrometer.core.instrument.binder.system.ProcessorMetrics;

public class DataSourceMetrics {
    public static void bindToHikari(HikariDataSource ds) {
        var poolBean = ds.getHikariPoolMXBean();
        // 绑定连接池指标
        Metrics.gauge("hikari.connections.active", poolBean, p -> p.getActiveConnections());
        Metrics.gauge("hikari.connections.idle", poolBean, p -> p.getIdleConnections());
        Metrics.gauge("hikari.connections.total", poolBean, p -> p.getTotalConnections());
        Metrics.gauge("hikari.threads.awaiting", poolBean, p -> p.getThreadsAwaitingConnection());
    }
}

优雅关闭（防止 JVM 退出时连接丢失） ： 在 main() 结束前，必须调用 dataSource.close() ，否则连接池后台线程不会退出，JVM 无法正常终止：

public static void main(String[] args) throws Exception {
    initDataSource();
    // ... 业务逻辑
    Runtime.getRuntime().addShutdownHook(new Thread(() -> {
        System.out.println("Shutting down HikariCP...");
        if (dataSource instanceof HikariDataSource) {
            ((HikariDataSource) dataSource).close();
        }
    }));
}

实操心得：我在一个金融项目里吃过亏。当时没加 shutdownHook ，K8s 发送 SIGTERM 后，应用进程僵死，K8s 等待 30 秒超时后强制 SIGKILL ，导致正在归还的连接被粗暴中断，数据库端留下大量 Sleep 状态连接。后来加上 shutdownHook ，配合 preStop 生命周期钩子，下线时间从 30 秒降到 2 秒。

4. 常见问题与排查技巧实录：那些年踩过的坑，都成了经验

4.1 “Could not open JDBC Connection”：90% 的原因不在数据库

这个报错是 Java 开发者最熟悉的“老朋友”，但它的根因五花八门。我整理了一个速查表，按发生频率排序：

现象 根本原因 排查命令/方法 解决方案
启动时报错，日志有 Access denied 数据库账号密码错误，或账号无权限 mysql -u user -p -h host 手动登录测试 检查 spring.datasource.username/password ，确认账号有 SELECT/INSERT 权限
运行中偶发报错，日志有 Connection refused 数据库服务宕机，或网络中断 telnet db-host 3306 或 nc -zv db-host 3306 检查 DB 服务状态、防火墙、K8s Service 是否正常
报错含 No suitable driver JDBC Driver JAR 未加载，或类名拼错 jps -l 查进程， jstack <pid> | grep Driver 确认 pom.xml 有驱动依赖， setDriverClassName() 参数正确（MySQL 8.0 是 com.mysql.cj.jdbc.Driver ）
报错含 SocketTimeoutException 网络延迟高，或数据库负载过载 ping db-host 、 curl -I http://db-monitor/metrics 调大 connectionTimeout ，检查 DB CPU/IO，增加 DB 实例
报错含 java.lang.OutOfMemoryError: unable to create new native thread 连接池 maxPoolSize 过大，耗尽 OS 线程数 ulimit -u 查用户线程上限， ps -eLf | grep java | wc -l 降低 maxPoolSize ，检查是否有线程泄漏

注意： No suitable driver 错误在 JDK 6+ 已基本消失，因为 DriverManager 支持 ServiceLoader 自动注册。但如果用了 hibernate-core 5.2+，它会强制要求 driver-class-name ，否则报此错。这是 Hibernate 的兼容性策略，不是 JDBC 问题。

4.2 “cnanot determin target datasource”：Spring 多数据源的迷雾

这个报错（实际是 Cannot determine embedded database driver class for database type NONE 的缩写变体）几乎只出现在 Spring Boot 多数据源场景。根本原因是： Spring 无法从 application.yml 的配置中，推断出你要用哪个数据库类型 。

典型错误配置：

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/db1
    username: root
    password: 123456
  # 忘记指定 driver-class-name！

Spring Boot 的 DataSourceAutoConfiguration 会尝试根据 url 前缀（ jdbc:mysql: ）推断驱动，但这个逻辑在复杂 URL（如带 loadbalance 参数）或自定义驱动时会失败。

终极解决方案（三步） ：

  1. 强制指定驱动类 ： 
    spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
  2. 禁用自动配置（多数据源必备） ： 
    @SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})
public class Application { ... }
  3. 手写 @Configuration 显式声明 Bean ： 
    @Bean
@ConfigurationProperties("spring.datasource.primary")
public DataSource primaryDataSource() {
    return DataSourceBuilder.create().build();
}

实操心得：我在一个电商项目里，主库用 MySQL，订单库用 PostgreSQL，搜索库用 Elasticsearch。当时图省事，只配了 spring.datasource.url ，结果启动报 cnanot determin target datasource 。花了 3 小时查 Spring Boot 源码，才明白 DataSourceProperties 类里有个 determineDriverClassName() 方法，它对 jdbc:postgresql: 的识别是硬编码的。从此以后，我的所有多数据源配置，第一行必写 driver-class-name 。

4.3 Flink 的 JDBC 连接器异常：流式场景的特殊陷阱

Flink 的 JDBCOutputFormat 或 JDBCConnectionOptions 报错，往往和批处理不同。最常见的两个坑：

  • java.lang.ClassNotFoundException: com.mysql.cj.jdbc.Driver ：Flink 作业运行在 TaskManager JVM 中， mysql-connector-java JAR 必须显式添加到 lib/ 目录，或通过 --classpath 指定。不能只放在 IDE 的 pom.xml 里。
  • Failed to acquire connection from pool ：Flink 的 Sink 是并行的，每个 subtask 都会创建自己的 DataSource 。如果 maxPoolSize=5 ，而并行度是 4，则最多可能创建 20 个连接，远超数据库承受能力。 解决方案是：在 JDBCConnectionOptions 中，将 maxPoolSize 设为 1 ，并确保 connectionPoolSize （Flink 参数）与之匹配 。

4.4 MySQL 8.0.44 驱动的兼容性雷区

mysql-connector-java-8.0.44 是目前最稳定的版本，但它引入了几个必须注意的变化：

  • useSSL=true 默认强制开启 ：如果你的 MySQL 服务没配 SSL，连接会直接失败。必须在 URL 里显式加 ?useSSL=false&serverTimezone=UTC 。
  • allowPublicKeyRetrieval=true ：当 MySQL 用 caching_sha2_password 插件认证时（8.0 默认），客户端需要此参数才能获取公钥。URL 示例： jdbc:mysql://localhost:3306/test?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true 。
  • zeroDateTimeBehavior=CONVERT_TO_NULL 废弃 ：改用 serverTimezone=UTC 替代，否则启动报 Unknown system variable 。

提示：不要盲目追求最新驱动。我见过一个项目，从 8.0.28 升级到 8.0.33 后，所有 TIMESTAMP 字段读出来都是 null ，查了两天才发现是驱动的一个 Bug，官方在 8.0.34 修复。生产环境升级驱动，务必先在测试环境跑全量 SQL 回归。

5. 进阶思考：DataSource 的边界在哪里？它何时不再是答案？

5.1 当连接池成为瓶颈：分库分表与读写分离的必然性

即使 HikariCP 调优到极致，单个 MySQL 实例的 max_connections 仍是硬上限。当你的 maxPoolSize 接近数据库 max_connections 的 80%（比如 DB 是 500，应用池是 400），你就该考虑架构演进了。此时 DataSource 的角色，从“连接管理者”升级为“路由决策者”。

  • ShardingSphere-JDBC ：它提供了一个 ShardingDataSource ，实现了 javax.sql.DataSource 接口。你代码里 dataSource.getConnection() 拿到的，不再是单一 DB 的连接，而是经过分片路由后的连接。它内部维护了多个底层 HikariDataSource ，根据 SQL 中的 sharding_key （如 user_id ）计算路由到哪个库表。
  • MyCat / ShardingSphere-Proxy ：它们是独立的中间件，应用端仍用普通 DataSource 连接 MyCat，由 MyCat 完成分库分表。这种方式对应用透明，但增加了一层网络跳转。

关键洞察： DataSource 接口的抽象能力极强。无论是 HikariCP 的连接池、ShardingSphere 的分片路由，还是 Druid 的 SQL 防火墙，它们都通过实现同一个接口，无缝集成到 Spring 的 JdbcTemplate 、MyBatis 的 SqlSessionFactory 中。这就是面向接口编程的力量。

5.2 云原生时代：Serverless 与连接池的冲突

在 AWS Lambda、阿里云函数计算等 Serverless 场景下， DataSource 遇到了新挑战：函数实例是短生命周期的，冷启动时初始化连接池要 1~2 秒，而函数超时通常只有 15 秒。如果每次请求都新建 HikariDataSource ，性能灾难。

解决方案是“连接池外置” ：

  • RDS Proxy（AWS） ：它是一个托管的数据库代理，应用连接 RDS Proxy，由 Proxy 管理与 RDS 的长连接池。函数只需建短连接到 Proxy，Proxy 负责复用后端连接。
  • 连接池静态化 ：在函数 handler 外部（类静态块）初始化 DataSource ，利用函数实例的“热启动”特性复用。但要注意，Lambda 的实例可能被复用数小时， maxLifetime 必须设短（如 10 分钟），防连接老化。

5.3 最后一个真相：DataSource 不是银弹，DAO 层才是真正的战场

我见过太多团队，把所有精力花在调优 maxPoolSize 、 connectionTimeout 上，却忽视了 DAO 层的 SQL 质量。一个 N+1 查询问题，会让连接池里 10 个连接全卡在慢 SQL 上；一个没加索引的 WHERE 条件，会让单个连接耗时从 5ms 涨到 500ms，进而拖垮整个池。

所以，比 DataSource 更重要的，是你的 DAO 设计 ：

  • 永远用 PreparedStatement ，杜绝字符串拼接 SQL ：防 SQL 注入，更重要的是，让数据库能缓存执行计划。
  • 查询只取必要字段 ： SELECT * 在连接池紧张时，会放大网络传输和内存消耗。
  • 批量操作用 addBatch() ：100 条 INSERT，用 addBatch() 比 100 次 executeUpdate() 快 10 倍以上，因为它复用同一个连接和预编译语句。

我个人在实际操作中的体会是：一个健康的 Java 应用， DataSource 的监控指标（Active/Idle）应该像心电图一样平稳波动，峰值不超过 maxPoolSize 的 70%。如果它经常打满、线程大量等待，别急着调大 maxPoolSize ，先打开 slow_sql_log ，看看是不是 DAO 层的 SQL 在拖后腿。连接池是高速公路，DAO 是跑在路上的车——路修得再宽，车要是抛锚了，照样堵死。

Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

我review了一份Vibe Coding写的前端代码——能跑，但5个地方迟早要命

avatar AI编程社区
cover

#AI 时代的“八股文“新解：数据结构与算法在大模型应用中的实战价值

avatar AI编程社区

2026年AI协同底座深度评测｜团队多外部Agent规模化协同落地全方案

企业也可选择自建中间件或第三方iPaaS平台串联外部Agent，这类方案仅能完成基础数据互通，无法原生读取飞书内部协作数据，需要额外对接多套系统接口，开发与维护成本持续增加，且缺少统一的权限、成本管控后台，多人团队长期使用会出现数据合规、日志追溯等配套问题。搭配Codex、Gemini CLI完成数据抓取、多模态素材解析，通过aily串联研报、方案、内容生产流程，自动关联企业内部知识库，产出物统一

avatar AI编程社区