Hikari
refer to : https://github.com/brettwooldridge/HikariCP
Configuration
HikariCP comes with sane defaults that perform well in most deployments without additional tweaking. Every property is optional, except for the "essentials" marked below.
📎 HikariCP uses milliseconds for all time values.
🚨 HikariCP relies on accurate timers for both performance and reliability. It is imperative that your server is synchronized with a time-source such as an NTP server. Especially if your server is running within a virtual machine. Why? Read more here. Do not rely on hypervisor settings to "synchronize" the clock of the virtual machine. Configure time-source synchronization inside the virtual machine. If you come asking for support on an issue that turns out to be caused by lack time synchronization, you will be taunted publicly on Twitter.
Essentials
🔤dataSourceClassName
This is the name of the DataSource class provided by the JDBC driver. Consult the documentation for your specific JDBC driver to get this class name, or see the table below. Note XA data sources are not supported. XA requires a real transaction manager like bitronix. Note that you do not need this property if you are using jdbcUrl for "old-school" DriverManager-based JDBC driver configuration. Default: none
- or -
🔤jdbcUrl
This property directs HikariCP to use "DriverManager-based" configuration. We feel that DataSource-based configuration (above) is superior for a variety of reasons (see below), but for many deployments there is little significant difference. When using this property with "old" drivers, you may also need to set the driverClassName property, but try it first without. Note that if this property is used, you may still use DataSource properties to configure your driver and is in fact recommended over driver parameters specified in the URL itself. Default: none
🔤username
This property sets the default authentication username used when obtaining Connections from the underlying driver. Note that for DataSources this works in a very deterministic fashion by calling DataSource.getConnection(*username*, password) on the underlying DataSource. However, for Driver-based configurations, every driver is different. In the case of Driver-based, HikariCP will use this username property to set a user property in the Properties passed to the driver's DriverManager.getConnection(jdbcUrl, props) call. If this is not what you need, skip this method entirely and call addDataSourceProperty("username", ...), for example. Default: none
🔤password
This property sets the default authentication password used when obtaining Connections from the underlying driver. Note that for DataSources this works in a very deterministic fashion by calling DataSource.getConnection(username, *password*) on the underlying DataSource. However, for Driver-based configurations, every driver is different. In the case of Driver-based, HikariCP will use this password property to set a password property in the Properties passed to the driver's DriverManager.getConnection(jdbcUrl, props) call. If this is not what you need, skip this method entirely and call addDataSourceProperty("pass", ...), for example. Default: none
Frequently used
✅autoCommit
This property controls the default auto-commit behavior of connections returned from the pool. It is a boolean value. Default: true
⏳connectionTimeout
This property controls the maximum number of milliseconds that a client (that's you) will wait for a connection from the pool. If this time is exceeded without a connection becoming available, a SQLException will be thrown. Lowest acceptable connection timeout is 250 ms. Default: 30000 (30 seconds)
⏳idleTimeout
This property controls the maximum amount of time that a connection is allowed to sit idle in the pool. This setting only applies when minimumIdle is defined to be less than maximumPoolSize. Idle connections will not be retired once the pool reaches minimumIdle connections. Whether a connection is retired as idle or not is subject to a maximum variation of +30 seconds, and average variation of +15 seconds. A connection will never be retired as idle before this timeout. A value of 0 means that idle connections are never removed from the pool. The minimum allowed value is 10000ms (10 seconds). Default: 600000 (10 minutes)
⏳keepaliveTime
This property controls how frequently HikariCP will attempt to keep a connection alive, in order to prevent it from being timed out by the database or network infrastructure. This value must be less than the maxLifetime value. A "keepalive" will only occur on an idle connection. When the time arrives for a "keepalive" against a given connection, that connection will be removed from the pool, "pinged", and then returned to the pool. The 'ping' is one of either: invocation of the JDBC4 isValid() method, or execution of the connectionTestQuery. Typically, the duration out-of-the-pool should be measured in single digit milliseconds or even sub-millisecond, and therefore should have little or no noticeable performance impact. The minimum allowed value is 30000ms (30 seconds), but a value in the range of minutes is most desirable. Default: 0 (disabled)
⏳maxLifetime
This property controls the maximum lifetime of a connection in the pool. An in-use connection will never be retired, only when it is closed will it then be removed. On a connection-by-connection basis, minor negative attenuation is applied to avoid mass-extinction in the pool. We strongly recommend setting this value, and it should be several seconds shorter than any database or infrastructure imposed connection time limit. A value of 0 indicates no maximum lifetime (infinite lifetime), subject of course to the idleTimeout setting. The minimum allowed value is 30000ms (30 seconds). Default: 1800000 (30 minutes)
🔤connectionTestQuery
If your driver supports JDBC4 we strongly recommend not setting this property. This is for "legacy" drivers that do not support the JDBC4 Connection.isValid() API. This is the query that will be executed just before a connection is given to you from the pool to validate that the connection to the database is still alive. Again, try running the pool without this property, HikariCP will log an error if your driver is not JDBC4 compliant to let you know. Default: none
🔢minimumIdle
This property controls the minimum number of idle connections that HikariCP tries to maintain in the pool. If the idle connections dip below this value and total connections in the pool are less than maximumPoolSize, HikariCP will make a best effort to add additional connections quickly and efficiently. However, for maximum performance and responsiveness to spike demands, we recommend not setting this value and instead allowing HikariCP to act as a fixed size connection pool. Default: same as maximumPoolSize
🔢maximumPoolSize
This property controls the maximum size that the pool is allowed to reach, including both idle and in-use connections. Basically this value will determine the maximum number of actual connections to the database backend. A reasonable value for this is best determined by your execution environment. When the pool reaches this size, and no idle connections are available, calls to getConnection() will block for up to connectionTimeout milliseconds before timing out. Please read about pool sizing. Default: 10
📈metricRegistry
This property is only available via programmatic configuration or IoC container. This property allows you to specify an instance of a Codahale/Dropwizard MetricRegistry to be used by the pool to record various metrics. See the Metrics wiki page for details. Default: none
📈healthCheckRegistry
This property is only available via programmatic configuration or IoC container. This property allows you to specify an instance of a Codahale/Dropwizard HealthCheckRegistry to be used by the pool to report current health information. See the Health Checks wiki page for details. Default: none
🔤poolName
This property represents a user-defined name for the connection pool and appears mainly in logging and JMX management consoles to identify pools and pool configurations. Default: auto-generated
Infrequently used
⏳initializationFailTimeout
This property controls whether the pool will "fail fast" if the pool cannot be seeded with an initial connection successfully. Any positive number is taken to be the number of milliseconds to attempt to acquire an initial connection; the application thread will be blocked during this period. If a connection cannot be acquired before this timeout occurs, an exception will be thrown. This timeout is applied after the connectionTimeout period. If the value is zero (0), HikariCP will attempt to obtain and validate a connection. If a connection is obtained, but fails validation, an exception will be thrown and the pool not started. However, if a connection cannot be obtained, the pool will start, but later efforts to obtain a connection may fail. A value less than zero will bypass any initial connection attempt, and the pool will start immediately while trying to obtain connections in the background. Consequently, later efforts to obtain a connection may fail. Default: 1
❎isolateInternalQueries
This property determines whether HikariCP isolates internal pool queries, such as the connection alive test, in their own transaction. Since these are typically read-only queries, it is rarely necessary to encapsulate them in their own transaction. This property only applies if autoCommit is disabled. Default: false
❎allowPoolSuspension
This property controls whether the pool can be suspended and resumed through JMX. This is useful for certain failover automation scenarios. When the pool is suspended, calls to getConnection() will not timeout and will be held until the pool is resumed. Default: false
❎readOnly
This property controls whether Connections obtained from the pool are in read-only mode by default. Note some databases do not support the concept of read-only mode, while others provide query optimizations when the Connection is set to read-only. Whether you need this property or not will depend largely on your application and database. Default: false
❎registerMbeans
This property controls whether or not JMX Management Beans ("MBeans") are registered or not. Default: false
🔤catalog
This property sets the default catalog for databases that support the concept of catalogs. If this property is not specified, the default catalog defined by the JDBC driver is used. Default: driver default
🔤connectionInitSql
This property sets a SQL statement that will be executed after every new connection creation before adding it to the pool. If this SQL is not valid or throws an exception, it will be treated as a connection failure and the standard retry logic will be followed. Default: none
🔤driverClassName
HikariCP will attempt to resolve a driver through the DriverManager based solely on the jdbcUrl, but for some older drivers the driverClassName must also be specified. Omit this property unless you get an obvious error message indicating that the driver was not found. Default: none
🔤transactionIsolation
This property controls the default transaction isolation level of connections returned from the pool. If this property is not specified, the default transaction isolation level defined by the JDBC driver is used. Only use this property if you have specific isolation requirements that are common for all queries. The value of this property is the constant name from the Connection class such as TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ, etc. Default: driver default
⏳validationTimeout
This property controls the maximum amount of time that a connection will be tested for aliveness. This value must be less than the connectionTimeout. Lowest acceptable validation timeout is 250 ms. Default: 5000
⏳leakDetectionThreshold
This property controls the amount of time that a connection can be out of the pool before a message is logged indicating a possible connection leak. A value of 0 means leak detection is disabled. Lowest acceptable value for enabling leak detection is 2000 (2 seconds). Default: 0
➡dataSource
This property is only available via programmatic configuration or IoC container. This property allows you to directly set the instance of the DataSource to be wrapped by the pool, rather than having HikariCP construct it via reflection. This can be useful in some dependency injection frameworks. When this property is specified, the dataSourceClassName property and all DataSource-specific properties will be ignored. Default: none
🔤schema
This property sets the default schema for databases that support the concept of schemas. If this property is not specified, the default schema defined by the JDBC driver is used. Default: driver default
➡threadFactory
This property is only available via programmatic configuration or IoC container. This property allows you to set the instance of the java.util.concurrent.ThreadFactory that will be used for creating all threads used by the pool. It is needed in some restricted execution environments where threads can only be created through a ThreadFactory provided by the application container. Default: none
➡scheduledExecutor
This property is only available via programmatic configuration or IoC container. This property allows you to set the instance of the java.util.concurrent.ScheduledExecutorService that will be used for various internally scheduled tasks. If supplying HikariCP with a ScheduledThreadPoolExecutor instance, it is recommended that setRemoveOnCancelPolicy(true) is used. Default: none
与SpringBoot 整合
spring:
datasource:
driver-class-name: com.mysql.jdbc.Driver
url: jdbc:mysql://127.0.0.1:3306/test
username: root
password: 222333
hikari:
connection-timeout: 30000
validation-timeout: 5000
idle-timeout: 600000
max-lifetime: 1800000
maximum-pool-size: 10
minimum-idle: 5
read-only: false
连接泄漏 以及检查方法
连接泄漏：如果应用程序没有正确关闭数据库连接，连接池中的连接可能会逐渐被耗尽
另一种更加详细的解释，如下：
数据库连接泄漏：如果应用程序中存在数据库连接泄漏（即连接未正确关闭），连接池中的连接会逐渐被耗尽，最终导致无法获取新的连接。
常见的连接泄漏，主要出现在以下场景中：
1.在try块中打开连接，但没有在finally块中关闭，或者使用try-with-resources语句。
2.还有可能用户的应用有复杂的逻辑，比如异步处理或事务管理，导致连接未正确释放。这时候可能需要检查事务的边界和资源管理。
排查步骤
1. 监控连接池的使用情况
大多数数据库连接池（如 HikariCP、Tomcat JDBC Pool、DBCP）都提供了监控接口或日志功能，可以实时查看连接池的状态。
-
HikariCP：
在配置中启用监控日志，观察连接池的活跃连接数是否持续增长：properties
# application.properties logging.level.com.zaxxer.hikari=DEBUG如果发现
Active Connections随时间逐渐增加且不释放，可能存在连接泄漏。
也可以在logback的配置文件中，添加以下配置：
<logger name="com.zaxxer.hikari" level="DEBUG" >
<appender-ref ref="monitor_console" />
<appender-ref ref="monitor_file" />
</logger>
-
查看连接池指标：
通过连接池的监控端点（如 Spring Boot Actuator 的/actuator/metrics）查看以下指标：hikaricp.connections.active：当前活跃连接数。hikaricp.connections.idle：当前空闲连接数。hikaricp.connections.max：最大连接数。hikaricp.connections.pending：等待获取连接的线程数。
如果
active接近max且pending有值，说明连接池可能被耗尽。
2. 启用连接泄漏检测
许多连接池支持配置连接泄漏检测功能，当连接长时间未关闭时会触发警告。
-
HikariCP：
设置leakDetectionThreshold（单位：毫秒），如果连接未在指定时间内关闭，会记录警告：properties
spring.datasource.hikari.leak-detection-threshold=60000 # 60秒内未关闭则报警日志中会显示类似以下信息，并附带未关闭连接的堆栈跟踪：
Connection leak detected: Connection ... was not closed. -
Tomcat JDBC Pool：
配置removeAbandonedTimeout和logAbandoned：properties
spring.datasource.tomcat.remove-abandoned-timeout=60 # 60秒后回收泄漏连接 spring.datasource.tomcat.log-abandoned=true # 记录泄漏连接的堆栈信息
3. 分析代码中的连接管理
连接泄漏通常是由于代码未正确关闭连接导致的，常见场景：
- 未关闭
Connection、Statement或ResultSet。 - 在
try块中打开连接，但未在finally块中关闭。 - 异常分支中未关闭连接。
示例代码问题：
java
// 错误示例：未关闭连接
public void queryData() {
Connection conn = dataSource.getConnection();
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM table");
// 忘记调用 rs.close(), stmt.close(), conn.close()
}
正确做法：
使用 try-with-resources（Java 7+）自动关闭资源：
java
public void queryData() {
try (Connection conn = dataSource.getConnection();
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM table")) {
// 处理结果
} catch (SQLException e) {
// 异常处理
}
}
4. 检查事务管理
如果使用 Spring 的事务管理（如 @Transactional），确保事务边界正确：
- 在事务方法中，连接会在事务提交或回滚后自动释放。
- 如果事务未正确结束（如未处理异常），可能导致连接未释放。
示例问题：
java
@Transactional
public void updateData() {
// 数据库操作
throw new RuntimeException("业务异常"); // 如果未回滚事务，连接可能未释放
}
解决方案：
-
确保异常触发事务回滚：
java
@Transactional(rollbackFor = Exception.class)
5. 使用数据库监控工具
通过数据库自身的监控功能，查看当前活跃连接及其来源：
-
MySQL：
sql
SHOW PROCESSLIST; -- 查看所有数据库连接如果发现大量来自应用程序的
Sleep连接，可能是连接未正确关闭。 -
PostgreSQL：
sql
SELECT * FROM pg_stat_activity; -- 查看活跃连接
总结
- 先通过连接池的监控和日志确认是否存在泄漏。
- 启用连接泄漏检测，定位未关闭连接的代码堆栈。
- 检查代码中是否所有分支都正确关闭了连接。
- 结合数据库和 APM 工具进一步验证。
通过以上步骤，可以逐步缩小范围，找到连接泄漏的根源。
工作中，实际的排查经历
1.在logback的配置文件中，添加以下配置：
<logger name="com.zaxxer.hikari" level="DEBUG" >
<appender-ref ref="monitor_console" />
<appender-ref ref="monitor_file" />
</logger>
2.设置 leakDetectionThreshold（单位：毫秒），如果连接未在指定时间内关闭，会记录警告：
DataSourceProperty property = new DataSourceProperty();
property.setUsername(bizUsername);
property.setPassword(bizPassword);
property.setUrl(bizUrl);
String driverClassName = rs.getString("driver_class_name");
if (StringUtils.isEmpty(driverClassName)) {
property.setDriverClassName(DynamicDsConstant.SQLSERVER_DRIVER);
} else {
property.setDriverClassName(driverClassName);
}
// 后面再增加pool的相关配置
HikariCpConfig hikariCpConfig = new HikariCpConfig();
hikariCpConfig.setLeakDetectionThreshold(30000l);
property.setHikari(hikariCpConfig);
日志中会显示类似以下信息，并附带未关闭连接的堆栈跟踪：
Connection leak detected: Connection ... was not closed.
在上面2步完成后，接下来，我们观察日志，就能看到了，如下：
09:10:46.530 [,] [ca06fe31-b226-4358-a568-f40a655ef418_iot housekeeper] DEBUG com.zaxxer.hikari.pool.HikariPool - [logPoolState,421] - ca06fe31-b226-4358-a568-f40a655ef418_iot - Pool stats (total=10, active=1, idle=9, waiting=0)
09:10:46.530 [,] [ca06fe31-b226-4358-a568-f40a655ef418_iot housekeeper] DEBUG com.zaxxer.hikari.pool.HikariPool - [fillPool,518] - ca06fe31-b226-4358-a568-f40a655ef418_iot - Fill pool skipped, pool is at sufficient level.
09:15:30.000 [1a30f635ec9b315d,1a30f635ec9b315d] [scadaSche-5] DEBUG org.hibernate.SQL - [logStatement,144] - update program_mon_sub set lease_deadline=? where lease_id=?
09:15:30.004 [1a30f635ec9b315d,1a30f635ec9b315d] [scadaSche-5] DEBUG org.hibernate.SQL - [logStatement,144] - select programmon0_.id as id1_47_, programmon0_.busi_type as busi_typ2_47_, programmon0_.lease_deadline as lease_de3_47_, programmon0_.lease_id as lease_id4_47_, programmon0_.sub_mon_id as sub_mon_5_47_ from program_mon_sub programmon0_ where programmon0_.busi_type=7 and programmon0_.lease_id=?
09:15:30.273 [,] [ca06fe31-b226-4358-a568-f40a655ef418_iot housekeeper] WARN com.zaxxer.hikari.pool.ProxyLeakTask - [run,84] - Connection leak detection triggered for ConnectionID:74 ClientConnectionId: e2da1b3b-9cbc-4d85-820c-269be0509e3a on thread powerjob-worker-light-task-execute-17, stack trace follows
java.lang.Exception: Apparent connection leak detected
at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:100)
at com.baomidou.dynamic.datasource.ds.ItemDataSource.getConnection(ItemDataSource.java:55)
at com.baomidou.dynamic.datasource.ds.AbstractRoutingDataSource.getConnection(AbstractRoutingDataSource.java:54)
at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:122)
at org.hibernate.internal.NonContextualJdbcConnectionAccess.obtainConnection(NonContextualJdbcConnectionAccess.java:38)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:108)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:138)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getConnectionForTransactionManagement(LogicalConnectionManagedImpl.java:276)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.begin(LogicalConnectionManagedImpl.java:284)
at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.begin(JdbcResourceLocalTransactionCoordinatorImpl.java:246)
at org.hibernate.engine.transaction.internal.TransactionImpl.begin(TransactionImpl.java:83)
at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:164)
at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:421)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.startTransaction(AbstractPlatformTransactionManager.java:400)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:373)
at com.jshxhb.iot2servermanage.processor.ScadaMonitorCheckProcessor.process(ScadaMonitorCheckProcessor.java:122)
at tech.powerjob.worker.core.tracker.task.light.LightTaskTracker.processTask(LightTaskTracker.java:211)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
09:15:30.571 [34f635c37e42b99c,34f635c37e42b99c] [scadaSche-3] DEBUG org.hibernate.SQL - [logStatement,144] - update program_mon_sub set lease_deadline=? where lease_id=?
09:15:30.572 [284260051b93a76a,284260051b93a76a] [scadaSche-2] DEBUG org.hibernate.SQL - [logStatement,144] - update program_mon_sub set lease_deadline=? where lease_id=?
09:15:30.575 [34f635c37e42b99c,34f635c37e42b99c] [scadaSche-3] DEBUG org.hibernate.SQL - [logStatement,144] - select programmon0_.id as id1_47_, programmon0_.busi_type as busi_typ2_47_, programmon0_.lease_deadline as lease_de3_47_, programmon0_.lease_id as lease_id4_47_, programmon0_.sub_mon_id as sub_mon_5_47_ from program_mon_sub programmon0_ where programmon0_.busi_type=7 and programmon0_.lease_id=?
09:15:30.587 [284260051b93a76a,284260051b93a76a] [scadaSche-2] DEBUG org.hibernate.SQL - [logStatement,144] - select programmon0_.id as id1_47_, programmon0_.busi_type as busi_typ2_47_, programmon0_.lease_deadline as lease_de3_47_, programmon0_.lease_id as lease_id4_47_, programmon0_.sub_mon_id as sub_mon_5_47_ from program_mon_sub programmon0_ where programmon0_.busi_type=5 and programmon0_.lease_id=?
09:15:30.606 [30ad380e78d3b12c,30ad380e78d3b12c] [scadaSche-4] DEBUG org.hibernate.SQL - [logStatement,144] - update program_mon_sub set lease_deadline=? where lease_id=?
09:15:30.610 [30ad380e78d3b12c,30ad380e78d3b12c] [scadaSche-4] DEBUG org.hibernate.SQL - [logStatement,144] - select programmon0_.id as id1_47_, programmon0_.busi_type as busi_typ2_47_, programmon0_.lease_deadline as lease_de3_47_, programmon0_.lease_id as lease_id4_47_, programmon0_.sub_mon_id as sub_mon_5_47_ from program_mon_sub programmon0_ where programmon0_.busi_type=5 and programmon0_.lease_id=?
09:15:31.017 [5529ea74d138394d,5529ea74d138394d] [scadaSche-5] DEBUG org.hibernate.SQL - [logStatement,144] - update program_mon_sub set lease_deadline=? where lease_id=?
09:15:46.534 [,] [ca06fe31-b226-4358-a568-f40a655ef418_iot housekeeper] DEBUG com.zaxxer.hikari.pool.HikariPool - [logPoolState,421] - ca06fe31-b226-4358-a568-f40a655ef418_iot - Pool stats (total=10, active=2
, idle=8, waiting=0)
09:15:46.534 [,] [ca06fe31-b226-4358-a568-f40a655ef418_iot housekeeper] DEBUG com.zaxxer.hikari.pool.HikariPool - [fillPool,518] - ca06fe31-b226-4358-a568-f40a655ef418_iot - Fill pool skipped, pool is at suff
icient level.
------------------------------------------------------------------------------------
09:20:16.536 [,] [ca06fe31-b226-4358-a568-f40a655ef418_iot housekeeper] DEBUG com.zaxxer.hikari.pool.HikariPool - [logPoolState,421] - ca06fe31-b226-4358-a568-f40a655ef418_iot - Pool stats (total=10, active=3, idle=7, waiting=0)
09:20:16.537 [,] [ca06fe31-b226-4358-a568-f40a655ef418_iot housekeeper] DEBUG com.zaxxer.hikari.pool.HikariPool - [fillPool,518] - ca06fe31-b226-4358-a568-f40a655ef418_iot - Fill pool skipped, pool is at sufficient level.
09:20:30.247 [,] [ca06fe31-b226-4358-a568-f40a655ef418_iot housekeeper] WARN com.zaxxer.hikari.pool.ProxyLeakTask - [run,84] - Connection leak detection triggered for ConnectionID:71 ClientConnectionId: d0968936-e05a-48b1-9f6a-921c14ac9ab0 on thread powerjob-worker-light-task-execute-37, stack trace follows
java.lang.Exception: Apparent connection leak detected
at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:100)
at com.baomidou.dynamic.datasource.ds.ItemDataSource.getConnection(ItemDataSource.java:55)
at com.baomidou.dynamic.datasource.ds.AbstractRoutingDataSource.getConnection(AbstractRoutingDataSource.java:54)
at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:122)
at org.hibernate.internal.NonContextualJdbcConnectionAccess.obtainConnection(NonContextualJdbcConnectionAccess.java:38)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:108)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:138)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getConnectionForTransactionManagement(LogicalConnectionManagedImpl.java:276)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.begin(LogicalConnectionManagedImpl.java:284)
at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.begin(JdbcResourceLocalTransactionCoordinatorImpl.java:246)
at org.hibernate.engine.transaction.internal.TransactionImpl.begin(TransactionImpl.java:83)
at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:164)
at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:421)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.startTransaction(AbstractPlatformTransactionManager.java:400)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:373)
at com.jshxhb.iot2servermanage.processor.ScadaMonitorCheckProcessor.process(ScadaMonitorCheckProcessor.java:122)
at tech.powerjob.worker.core.tracker.task.light.LightTaskTracker.processTask(LightTaskTracker.java:211)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
-------------------------------------------------------------------------------------------------------
09:25:16.539 [,] [ca06fe31-b226-4358-a568-f40a655ef418_iot housekeeper] DEBUG com.zaxxer.hikari.pool.HikariPool - [logPoolState,421] - ca06fe31-b226-4358-a568-f40a655ef418_iot - Pool stats (total=10, active=4, idle=6, waiting=0)
09:25:16.540 [,] [ca06fe31-b226-4358-a568-f40a655ef418_iot housekeeper] DEBUG com.zaxxer.hikari.pool.HikariPool - [fillPool,518] - ca06fe31-b226-4358-a568-f40a655ef418_iot - Fill pool skipped, pool is at sufficient level.
09:25:30.255 [,] [ca06fe31-b226-4358-a568-f40a655ef418_iot housekeeper] WARN com.zaxxer.hikari.pool.ProxyLeakTask - [run,84] - Connection leak detection triggered for ConnectionID:87 ClientConnectionId: 270d61c6-d727-4c50-9e2f-38890fc927fe on thread powerjob-worker-light-task-execute-55, stack trace follows
java.lang.Exception: Apparent connection leak detected
at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:100)
at com.baomidou.dynamic.datasource.ds.ItemDataSource.getConnection(ItemDataSource.java:55)
at com.baomidou.dynamic.datasource.ds.AbstractRoutingDataSource.getConnection(AbstractRoutingDataSource.java:54)
at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:122)
at org.hibernate.internal.NonContextualJdbcConnectionAccess.obtainConnection(NonContextualJdbcConnectionAccess.java:38)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:108)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:138)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getConnectionForTransactionManagement(LogicalConnectionManagedImpl.java:276)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.begin(LogicalConnectionManagedImpl.java:284)
at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.begin(JdbcResourceLocalTransactionCoordinatorImpl.java:246)
at org.hibernate.engine.transaction.internal.TransactionImpl.begin(TransactionImpl.java:83)
at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:164)
at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:421)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.startTransaction(AbstractPlatformTransactionManager.java:400)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:373)
at com.jshxhb.iot2servermanage.processor.ScadaMonitorCheckProcessor.process(ScadaMonitorCheckProcessor.java:122)
at tech.powerjob.worker.core.tracker.task.light.LightTaskTracker.processTask(LightTaskTracker.java:211)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
通过上面的日志，可以看到：
1.Pool stats中的active值，不断增加
2.Connection leak detection triggered for 日志后面，附带未关闭连接的堆栈跟踪：
根据日志中答应出堆栈信息，最终确定的是ScadaMonitorCheckProcessor.java:122，这一行代码，占用了数据库连接，未释放，导致连接泄漏。
接下来，我们进入这个类中，看是什么原因导致的：
可以看到，先开启了事务，然后做了一系列数据库的增删改查，然后直接continue，导致事务没有提交或者回滚。
因为事务没有提交，导致数据库连接一直被占用，没有被释放，导致连接泄漏。