Hi，运维，你懂Java吗--No.8：数据库连接池

龙叔运维

已于 2023-08-06 23:57:15 修改

阅读量234

点赞数

分类专栏：【系列】HI 运维你懂Java吗文章标签：运维 java jvm Hikari 数据库连接池 Druid

于 2023-07-30 23:42:07 首次发布

本文链接：https://blog.csdn.net/github_30641423/article/details/132013464

版权

【系列】HI 运维你懂Java吗专栏收录该内容

9 篇文章 2 订阅

订阅专栏

作为运维，你不一定要会写Java代码，但是一定要懂Java在生产跑起来之后的各种机制。

本文为《Hi，运维，你懂Java吗》系列文章第八篇，敬请关注后续系列文章

欢迎关注龙叔运维（公众号）持续分享运维经验

前言

本篇对java的数据库的连接池进行讲解。

主要站在运维角度讲解主流数据库连接池的配置参数，以及常见报错场景

1、为什么使用数据库连接池？

如果不使用数据库连接池，那么应用每次访问数据库都需要进行连接的创建，频繁的进行TCP握手、挥手。造成大量消耗，降低系统性能和并发能力。

数据库连接池管理维护一定数量的数据库连接，在应用需要连接数据库的时候进行分配，极大的降低了消耗，并能更好的管理对数据库的连接。

2、什么是数据库连接池？

下图简单介绍了数据库连接池在应用中起到的作用，以及一些常见的配置指标

3、数据库连接池有哪些？

目前的数据库连接池有Hikari，druid，dbcp，tomcat-jdbc，c3p0，BoneCP，Proxool，下面分别简单介绍下

整体来说，更为推荐Hikari 和 druid

Hikari性能最强

druid扩展性、监控性最强

3.1、c3p0

历史悠久，代码及其复杂，不利于维护。并且存在deadlock的潜在风险，不建议使用

3.2、BoneCP

现在已经不更新了，转到了HiKariCP上。不建议使用。

3.3、Proxool

评测说在并发较高的情况下会出错，且现在维护力度已经很小，不建议使用。

3.4、dbcp

tomcat内置的连接池，单独使用dbcp需要3个包：common-dbcp.jar,common-pool.jar,common-collections.jar
单线程，并发量低，性能不好，适用于小型系统

3.5、tomcat-jdbc

由于dbcp的性能不太好，apache又新开发了一款数据库连接池-tomcat jdbc pool，有的地方也称之为JDBC Connection Pool。

3.6、Hikari

        SpringBoot默认使用Hikari（springboot2.0之后）
        SpringBoot项目如果我们通过启动器starter使用JPA或者Mybatis，是默认会使用Hikari数据库连接池的，不需要引入依赖，已经在SpringBoot中包含了。
        号称最快的数据库连接池，强于性能。

3.7、druid

Druid能够提供强大的监控和扩展功能，强项在于监控

4、数据库连接池配置

关于各个数据库连接池的核心配置项，我这里对目前最为常用的三个数据库连接池（Druid，Hikari，DBCP）

配置分类	参数	参数描述	Druid			Hikari			DBCP
			Druid能够提供强大的监控和扩展功能，强项在于监控			SpringBoot默认使用Hikari（springboot2.0之后） SpringBoot项目如果我们通过启动器starter使用JPA或者Mybatis，是默认会使用Hikari数据库连接池的，不需要引入依赖，已经在SpringBoot中包含了。号称最快的数据库连接池，强于性能。			tomcat内置的连接池，单独使用dbcp需要3个包：common-dbcp.jar,common-pool.jar,common-collections.jar 单线程，并发量低，性能不好，适用于小型系统
			参数	描述	默认值	参数	描述	默认值	参数	描述	默认值
基础重要	获取连接超时时间		maxWait		无限	connectionTimeout		30000ms	maxWait		无限
	最小连接数		minIdle		8	minimumIdle	官方推荐不设置此值，默认同最大连接数相同	10	minIdle		0
	最大连接数		maxActive		8	maximumPoolSize	池中最大连接数，包括闲置和使用中的连接	10	maxActive		8
	初始化连接数		initialSize		0				initialSize		0
	连接最长生命周期					maxLifetime	一个连接的生命时长（毫秒），超时而且没被使用则被释放（retired）如果不等于0且小于30秒则会被重置回30分钟	1800000ms
	连接最大空闲时间					idleTimeout	连接允许在池中闲置的最长时间如果idleTimeout+1秒>maxLifetime 且 maxLifetime>0，则会被重置为0（代表永远不会退出）；如果idleTimeout!=0且小于10秒，则会被重置为10秒	600000ms
	最大空闲连接数								maxIdle	最大空闲连接:连接池中容许保持空闲状态的最大连接数量,超过的空闲连接将被释放,如果设置为负数表示不限制	8
	最小空闲连接数								minIdle	最小空闲连接:连接池中容许保持空闲状态的最小连接数量,低于这个数量将创建新的连接,如果设置为0则不创建	0
其他						readOnly	从池中获取的连接是否默认处于只读模式	false	defaultReadOnly	从池中获取的连接是否默认处于只读模式
						autoCommit	此属性控制从池返回的连接的默认自动提交行为设置为false后，事务不会自动提交，导致对数据库的插入修改操作无效，但是查询和删除可以。	true	defaultAutoCommit	此属性控制从池返回的连接的默认自动提交行为
						poolName	连接池的用户定义名称，主要出现在日志记录和JMX管理控制台中以识别池和池配置	HikariPool-1

连接有效性检查	有效性检查sql		validationQuery	连接有效性检查执行sql 如果为null，则下面参数不生效 testOnBorrow testOnReturn testWhileIdle	null	connection-test-query	数据库连接测试语句	null	validationQuery	连接有效性检查执行sql 如果为null，则下面参数不生效 testOnBorrow testOnReturn testWhileIdle	null
			testOnBorrow	申请连接时执行validationQuery检测连接是否有效	TRUE	keepaliveTime	每隔 keepaliveTime 检查连接的有效性，如果db连接不可用，则直接关闭	0（关闭）	testOnBorrow	申请连接时执行validationQuery检测连接是否有效	true
			testOnReturn	归还连接时执行validationQuery检测连接是否有效	FALSE				testOnReturn	归还连接时执行validationQuery检测连接是否有效	false
			testWhileIdle	申请连接的时候检测，如果空闲时间大于timeBetweenEvictionRunsMillis，执行validationQuery检测连接是否有效。	FALSE				testWhileIdle	申请连接的时候检测，如果空闲时间大于timeBetweenEvictionRunsMillis，执行validationQuery检测连接是否有效。	false
			timeBetweenEvictionRunsMillis	1) Destroy线程会检测连接的间removeAbandoned隔时间，如果连接空闲时间大于等于minEvictableIdleTimeMillis则关闭物理连接。2) testWhileIdle的判断依据	60000				timeBetweenEvictionRunsMillis	在空闲连接回收器线程运行期间休眠的时间值,以毫秒为单位. 如果设置为非正数,则不运行空闲连接回收器线程	-1
			minEvictableIdleTimeMillis	连接保持空闲而不被驱逐的最小时间	300000				minEvictableIdleTimeMillis	连接保持空闲而不被驱逐的最小时间
异常调试			removeAbandoned	用来关闭长时间不使用的连接。RemoveAbandanded功能不建议在生产环境中使用，仅用于连接泄露检测诊断	FALSE				removeAbandoned	用来关闭长时间不使用的连接。RemoveAbandanded功能不建议在生产环境中使用，仅用于连接泄露检测诊断	FALSE
			removeAbandonedTimeout	打开RemoveAbandanded功能，超过这个时间则会关闭连接，单位秒					removeAbandonedTimeout	打开RemoveAbandanded功能，超过这个时间则会关闭连接，单位秒
			logAbandoned	关闭abanded连接时输出错误日志					logAbandoned	关闭abanded连接时输出错误日志

5、常见数据库连接池报错

5.1、获取数据库连接超时

原因分析：

1、瞬间并发突增导致连接被占满

2、出现了慢SQL。或者连接泄漏

5.1.1、Druid

报错：com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 60000, active 20, maxActive 20, creating 0

报错解读分析：

当前连接池活动连接数为20，最大连接数限制为20，所以没有空闲连接能进行分配，新的请求进来，等了60秒（最大等待时间）之后，抛出了异常

异常处理解决：

1、调大最大连接数：

maxActive = 30

2、打开连接回收机制：

                removeAbandoned = true 【开启超时回收】
                removeAbandonedTimeout = 180 【超过180秒则进行回收】
                logAbandoned = true 【回收的时候打印相关日志】

如下就是连接超过removeAbandonedTimeout设置的时间，断开连接之后打印的日志，会打印出对应线程的堆栈先，就可以看出是哪个地方有长时间不释放的数据库连接。

5.1.2、Hikari

报错：Unable to acquire JDBC Connection Connection is not available, request timed out after 30000ms.

报错解读分析：

等待分配数据库连接30秒之后超时报错

异常处理解决：

1、调大最大连接数：

maximum-pool-size: 20

当然最重要的还是优化代码

5.2、获取到无效连接

5.2.1、Druid

报错：The last packet successfully received from the server was 1,855,774 milliseconds ago. The last packet sent successfully to the server was 1,855,775 milliseconds ago.

报错解读分析：

获取到的数据库连接已经无效，并列出了最后一次成功接收和发送数据的时间间隔

异常处理解决：

1、设置连接有效性检查，但会对性能造成影响

                        validationQuery=select 1
                        testWhileIdle=true
                        testOnBorrow=true
                        testOnReturn=true

2、调整数据库超时配置

核查应用到数据库整条链路上的超时时间（中间可能经过负载均衡以及数据库中间件mycat等），整个数据库调用链路超时设置，应该从前到后，超时时间越来越大

如MYSQL端的wait_timeout

5.2.2、Hikari

报错：The last packet successfully received from the server was 212,079 milliseconds ago. The last packet sent successfully to the server was 3,004 milliseconds ago.). Possibly consider using a shorter maxLifetime value.|

报错：Failed to validate connection com.mysql.cj.jdbc.ConnectionImpl@72b70c61 (No operations allowed after connection closed.). Possibly consider using a shorter maxLifetime value