Java 数据库问题：SQLException 与连接池配置

Java 应用程序与数据库交互时，java.sql.SQLException 是最令人头疼的异常之一。这通常并非代码逻辑错误，而是环境配置、网络波动或连接池参数设置不当的结果。本文将通过具体步骤，指导你如何定位并解决常见的数据库连接问题。

1. 排查连接超时问题

当应用抛出 CommunicationsException 或提示 Connection timed out 时，通常意味着应用无法建立到数据库的物理连接。

1. 检查 数据库服务是否正常运行。
   执行 ping 数据库服务器 IP，确认网络链路通畅。
   登录 数据库服务器，确认 端口（如默认 3306）处于监听状态。

2. 检查 JDBC 连接字符串的参数配置。
   如果网络存在延迟或数据库负载较高，默认的连接超时时间可能过短。打开 配置文件（如 application.properties 或 application.yml）。

3. 修改 JDBC URL，增加 或 调整 connectTimeout 和 socketTimeout 参数。
   以下是一个 MySQL JDBC URL 的配置示例：

    # 设置连接超时为 10 秒（毫秒为单位）， socket 读写超时为 30 秒
    spring.datasource.url=jdbc:mysql://192.168.1.100:3306/db_name?connectTimeout=10000&socketTimeout=30000

4. 重启 应用程序，观察 日志中是否仍然出现超时异常。如果问题依旧，需排查防火墙是否拦截了数据库端口。

2. 解决“连接已关闭”异常

应用运行一段时间后，突然抛出 Connection is closed 或 Communications link failure，这通常是因为数据库服务端主动关闭了长时间闲置的连接，而应用端的连接池并不知道该连接已失效。

1. 定位 异常发生的场景。
   这种错误通常出现在“早上第一次操作”或“长时间无人使用后操作”时。这是因为连接超过了数据库的 wait_timeout 设置。

2. 配置 连接池的“有效性检查”机制。
   无论你使用 HikariCP 还是 Druid，都需要开启连接获取前的测试功能。

   如果是 HikariCP（Spring Boot 2.x+ 默认），请配置以下参数：

    spring:
      datasource:
        hikari:
          # 连接池中连接的最大存活时间（建议小于数据库的 wait_timeout）
          max-lifetime: 1800000 # 30 分钟
          # 测试连接是否有效的 SQL 语句
          connection-test-query: SELECT 1
          # 从连接池获取连接时是否测试（推荐 true）
          connection-timeout: 3000
          # 仅当驱动支持 JDBC4 时，可不配置 connection-test-query，但推荐显式配置

   如果是 Druid，请配置以下参数：

    spring:
      datasource:
        druid:
          # 申请连接时执行 validationQuery 检测连接是否有效
          test-on-borrow: true
          # 归还连接时执行 validationQuery 检测连接是否有效
          test-on-return: false
          # 既作为检测连接是否有效的 SQL，又建议配置为简单的查询语句
          validation-query: SELECT 1
          # 避免因检测连接导致性能下降，可配置 testWhileIdle
          test-while-idle: true
          time-between-eviction-runs-millis: 60000

3. 重启 应用，并模拟长时间闲置后请求接口，验证 问题是否解决。

3. 处理连接池耗尽

日志中出现 ConnectionPool exhausted 或 Timeout waiting for idle object，说明当前请求拿不到可用连接。

1. 分析 代码逻辑是否存在连接泄漏。
   最常见的原因是：代码中 获取 了连接，但在 finally 块中未 关闭 连接，或者在 try-with-resources 语法外使用连接。

2. 重构 数据库访问代码，强制使用 try-with-resources 语法。

    // 错误示范：未自动关闭
    Connection conn = dataSource.getConnection();
    Statement stmt = conn.createStatement();
    // ... 执行操作 ...
   
    // 正确示范：自动关闭资源
    try (Connection conn = dataSource.getConnection();
         Statement stmt = conn.createStatement()) {
        // ... 执行操作 ...
    } catch (SQLException e) {
        e.printStackTrace();
    }

3. 调整 连接池的大小参数。
   如果代码无误，但并发量确实很大，需调大连接池大小。

   打开 配置文件，修改 以下核心参数：

   参数名	作用说明	推荐计算方式
   maximum-pool-size	连接池最大连接数	(核心数 * 2) + 有效磁盘数 或直接设为 CPU 核数 + 1 (IO 密集型可适当放大)
   minimum-idle	最小空闲连接数	建议与 maximum-pool-size 保持一致，减少扩容带来的抖动
   connection-timeout	获取连接的超时时间	建议设置为 3000ms - 5000ms，避免长时间阻塞

4. 开启 连接泄漏检测参数。
   HikariCP 提供 leakDetectionThreshold，设置后如果连接超过该时间未关闭，会在日志中打印警告。

    spring:
      datasource:
        hikari:
          # 设置连接泄漏检测阈值为 10 秒（用于开发环境排查，生产环境可适当调大）
          leak-detection-threshold: 10000

4. 故障排查流程图

为了更系统地定位问题，请参考以下排查逻辑。

5. 常用数据库 JDBC URL 参数速查

不同的数据库驱动在处理连接异常时有不同的参数，以下是常用参数列表。

注意：将上述参数拼接到 JDBC URL 的 ? 之后，多个参数之间使用 & 连接。

6. 最终验证步骤

完成上述配置修改后，必须执行以下验证步骤以确保系统稳定。

1. 执行 压力测试（如使用 JMeter）。
   模拟高并发场景，监控 数据库的活跃连接数。确认 活跃连接数接近 maximum-pool-size 但未超出，且未出现大量 Wait 状态。

2. 模拟 数据库重启。
   在应用运行过程中，重启 数据库服务。观察 应用是否能自动恢复连接，而不是持续报错。这依赖于 validation-query 的正确配置。

3. 检查 应用日志。
   搜索 关键词 leak、timeout、failed。确保 没有新增的异常堆栈信息。