自从2018年起就开始使用Alibaba 的 druid 作为数据库连接池，作为有23.6k star的开源框架一直非常好用👍

今天为了解决相关问题，特地梳理了一下，这里将项目中使用的生产级配置分享给大家

项目采用maven配置，关键配置如下：

    <!-- Inherit defaults from Spring Boot -->
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.3.7.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    
    ...
    
    <!-- Add typical dependencies for a web application -->
    <dependencies>

        ...

        <!--自动配置需要引入的一个嵌入式数据库类型对象-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jdbc</artifactId>
        </dependency>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <scope>runtime</scope>
        </dependency>
        <!-- Alibaba的druid数据库连接池 -->
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>druid-spring-boot-starter</artifactId>
            <version>1.2.5</version>
        </dependency>

        ...

    </dependencies>

    ...

如上所示，配置了最新的druid-spring-boot-starter包1.2.5版本，使用这个版本会产生discard long time none received connection. 问题，如何解决呢？我在之前的一篇博文中有讲到，查看解决方案

druid配置比较多，这里只给大家介绍基础性配置，看项目配置前，我们先了解下官方配置说明

官方配置

静态配置

DruidDataSource配置兼容DBCP，但个别配置的语意有所区别。

其中一些配置，下面给特别解释下

1. Druid中的maxIdle为什么是没用的？
   maxIdle是Druid为了方便DBCP用户迁移而增加的，maxIdle是一个混乱的概念。连接池只应该有maxPoolSize和minPoolSize，druid只保留了maxActive和minIdle，分别相当于maxPoolSize和minPoolSize。

2. 如果DruidDataSource在init的时候失败了，不再使用，是否需要close
   是的，如果DruidDataSource不再使用，必须调用close来释放资源，释放的资源包括关闭Create和Destory线程。

3. 如何设置为让连接池知道数据库已经断开了，并且自动测试连接查询
   加入以下配置：

spring:
  datasource:
    druid: # Druid连接池配置，官方配置参考：https://github.com/alibaba/druid/tree/master/druid-spring-boot-starter
      # 用来检测连接是否有效的sql，要求是一个查询语句，常用select 'x'。
      # 如果validationQuery为null，testOnBorrow、testOnReturn、testWhileIdle都不会起作用。
      validation-query: SELECT 1
      # 建议配置为true，不影响性能，并且保证安全性。
      # 申请连接的时候检测，如果空闲时间大于timeBetweenEvictionRunsMillis，执行validationQuery检测连接是否有效。
      test-while-idle: true
      # 申请连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。
      test-on-borrow: false
      # 归还连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。
      test-on-return: false

连接泄漏监测

当程序存在缺陷时，申请的连接忘记关闭，这时候，就存在连接泄漏了。Druid提供了RemoveAbandanded相关配置，用来关闭长时间不使用的连接。RemoveAbandanded功能不建议在生产环境中使用，仅用于连接泄露检测诊断。例如：

配置

spring:
  datasource:
    druid: # Druid连接池配置，官方配置参考：https://github.com/alibaba/druid/tree/master/druid-spring-boot-starter
# 生产环境中连接的关闭应该靠程序自己保证。
      # 超过时间限制是否回收
      remove-abandoned: true
      # 超时时间；单位为秒。1800秒=30分钟
      remove-abandoned-timeout: 1800
      # 关闭abandoned连接时输出错误日志
      log-abandoned: true

配置removeAbandoned对性能会有一些影响，建议怀疑存在泄漏之后再打开。在上面的配置中，如果连接超过30分钟未关闭，就会被强行回收，并且日志记录连接申请时的调用堆栈。

RemoveAbandanded是连接池的高级功能，理论上这中配置不应该出现在实际的生产环境，因为有时应用程序执行长事务，可能这种情况下，会被连接池误回收，该种配置一般在程序测试阶段，为了定位连接泄漏的具体代码位置，被开启。

内置监控查看泄漏

如果你的应用配置了WebStatFilter: https://github.com/alibaba/druid/wiki/%E9%85%8D%E7%BD%AE_%E9%85%8D%E7%BD%AEWebStatFilter
在内置监控页面weburi-detail.html中，查看JdbcPoolConnectionOpenCount和JdbcPoolConnectionCloseCount属性，如果不相等，就是泄漏了。

当removeAbandoned=true之后，可以在内置监控界面datasource.html中的查看ActiveConnection StackTrace属性的，可以看到未关闭连接的具体堆栈信息，从而方便查出哪些连接泄漏了。

动态配置

下表中的参数在程序启动参数带入，如：java -jar app.jar -Ddruid.mysql.usePingMethod=false

讲了这么多，项目中如何配置呢？

下面就是项目的真实配置，其中${...}为变量，大家替换一下即可

spring:
  datasource:
    druid: # Druid连接池配置，官方配置参考：https://github.com/alibaba/druid/tree/master/druid-spring-boot-starter
      # 监控统计拦截的filters
      filters: stat,wall
#      driver-class-name: com.mysql.jdbc.Driver
      driver-class-name: com.mysql.cj.jdbc.Driver
      # 基本属性
      url: jdbc:mysql://${DB_HOST}:3306/${DB_NAME}?autoReconnect=true&useUnicode=true&characterEncoding=utf8
      username: ${DB_USER}
      password: ${DB_PASSWORD}
      # 配置初始化大小/最小/最大
      initial-size: 5
      # 最小连接池数量
      min-idle: 10
      # 最大连接池数量
      max-active: 20
      # 获取连接时最大等待时间，单位毫秒。
      # 配置了maxWait之后，缺省启用公平锁，并发效率会有所下降，如果需要可以通过配置useUnfairLock属性为true使用非公平锁。
      max-wait: 6000
      # 间隔多久进行一次检测，检测需要关闭的空闲连接
      time-between-eviction-runs-millis: 60000
      # 配置一个连接在连接池中的最小生存时间，单位毫秒。(连接保持空闲而不被驱逐的最小时间)
      min-evictable-idle-time-millis: 300000
      max-evictable-idle-time-millis: 900000
      # 用来检测连接是否有效的sql，要求是一个查询语句，常用select 'x'。
      # 如果validationQuery为null，testOnBorrow、testOnReturn、testWhileIdle都不会起作用。
      validation-query: SELECT 1
      # 建议配置为true，不影响性能，并且保证安全性。
      # 申请连接的时候检测，如果空闲时间大于timeBetweenEvictionRunsMillis，执行validationQuery检测连接是否有效。
      test-while-idle: true
      # 申请连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。
      test-on-borrow: false
      # 归还连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。
      test-on-return: false
      # 连接池中的minIdle数量以内的连接，空闲时间超过minEvictableIdleTimeMillis，则会执行keepAlive操作。
      keep-alive: true
      phy-max-use-count: 1000
# 有时粗心的程序编写者在从连接池中获取连接使用后忘记了连接的关闭，这样连池的连接就会逐渐达到maxActive直至连接池无法提供服务。
# 现代连接池一般提供一种“智能”的检查，但设置了removeAbandoned="true"时，当连接池连接数到达(getNumIdle() < 2) and (getNumActive() > getMaxActive() - 3) [空闲的连接小于2并且活动的连接大于(最大连接-3)] 时便会启动连接回收，那种活动时间超过removeAbandonedTimeout="60"的连接将会被回收，同时如果logAbandoned="true"设置为true,程序在回收连接的同时会打印日志。
# removeAbandoned是连接池的高级功能，理论上这中配置不应该出现在实际的生产环境，因为有时应用程序执行长事务，可能这种情况下，会被连接池误回收，该种配置一般在程序测试阶段，为了定位连接泄漏的具体代码位置，被开启。
# 生产环境中连接的关闭应该靠程序自己保证。
#      # 超过时间限制是否回收
#      remove-abandoned: true
#      # 超时时间；单位为秒。1800秒=30分钟
#      remove-abandoned-timeout: 1800
#      # 关闭abandoned连接时输出错误日志
#      log-abandoned: true
      filter:
        stat:
          # 慢SQL记录
          slow-sql-millis: 2000
          log-slow-sql: true
          merge-sql: true

有关慢sql日志配置上面没有讲，大家可以参照这个，这里打印2000毫秒以上慢sql日志。

OK了，有啥问题下面留言给我哈😀