1. 属性
参数名 默认值 允许最小值 允许最大值 connectionTimeout 30000 ms (30 s) 250 ms - idleTimeout 600000 ms (10 min) 10000 ms (10s) - keepaliveTime 不检测 30000 ms (30s) - maxLifetime 1800000 (30 min) 30000ms (30 s) 0 (无限) minimumIdle 10 个链接 - maximumPoolSize 10 个链接 >=minimumIdle validationTimeout 5000 ms (5s) 250 ms - leakDetectionThreshold 不检测 2000 ms (2s) -
1.1. connectionTimeout
此属性控制请求等待来自hikari池的连接的最大毫秒数。如果超过此时间还是没有任何连接可用,
则会引发SQLException。
如: 我们有一个请求从前端请求进来,这时他需要存入数据到数据库,首先他需要到链接池中获取一个链接,如果此时链接中的所有链接都在被其他线程使用,那么当前线程将只有被迫等待。但是它也不是无限制的等待,当它等待到我们设置的时间时程序就会报改错。
1.2. idleTimeout
此属性仅适用于当前线程池的实际连接数大于minimumIdle设置的值时,多出minimumIdle的线程如果长期空闲,那么将按照这个时间被回收(关闭),也就是空闲多久后被回收。
如:我们设置minimumIdle = 10,maximumPoolSize = 30,当10:10 am系统进入了很多的请求,hikari链接池中的连接数增长至27,后没有请求了,那么多余出来的17个线程,hikari不会立马关闭,因为它担心我们的系统短时间内还有很多连续请求,它释放了多余的链接,当再有大量请求来时,它很难短时间内再建立起这么多的连接,所以给了我们这样一个参数让我们去配置,以让我们的系统链接更加平稳。如我们设置为10 min,那么系统空闲出来的17个线程,就将会在它一直空闲长达10min钟后关闭。如果这17个线程在这10min钟内还有再被使用过,那么就以它最后一次被使用完的时间再推后十分钟。当然该链接也不是可以无限次的被续命,最终还是要受maxLifetime的限制。
官方网站上还有这样一句描述
"Whether a connection is retired as idle or not is subject to a maximum variation of +30 seconds, and average variation of +15 seconds."
这句话的意思是:
一个连接是否因为空闲而被回收(或关闭),可能会受到最多30秒的最大时间偏差影响,以及平均15秒的时间偏差影响。
这意味着,即使你设置了一个具体的 idleTimeout 值(例如60秒),实际的回收时间可能不是严格的60秒。它可能会在这个值的基础上增加或减少一些时间。具体来说,它可能会最多延迟30秒才回收连接,平均来看,可能会延迟15秒。
这样的设计可能是为了处理系统时钟的不精确性、处理过程中的延迟或其他可能导致回收时间不完全准确的因素。
1.3. keepaliveTime
此属性控制HikariCP尝试保持连接活的频率,“keepalive”只会发生在空闲连接上。意思是定期测试一下空闲链接是否因为各种原因死掉,保证链接可用。通常通过 JDBC4 isValid()方法或connectionTestQuery设置的sql语句测试(默认SELECT 1)。
keepaliveTime主要用于保活连接的机制。在网络通信中,有时候连接可能会因为长时间没有数据传输而处于空闲状态。为了保持连接的活性,系统会在keepaliveTime指定的时间间隔内发送保活探测包。这些探测包用于检查连接的另一端是否仍然在线,并可以接收数据。如果在指定时间内没有收到响应,系统可能会认为连接已经断开,并采取相应的处理措施。keepaliveTime的设置有助于防止因长时间空闲而导致的连接断开,从而保持连接的稳定性和持续性。
1.4. maxLifetime
此属性控制链接在链接池中的最大存活时间,超出这个时间链接就会被关闭并重建,它不是一次关闭所有的核心链接数,而是逐步关闭和新建。
1.5. minimumIdle
连接池的最小链接数,也就是hikari在正常情况下,不论我们的服务有没有请求使用DB,都需要常备的连接数量。
1.6. maximumPoolSize
连接池的最大连接数。当hikari连接池中的连接数量达到这个值后,不论服务多繁忙,都让其排队等待,不再建立新的连接。
1.7. validationTimeout
validationTimeout主要用于连接验证的超时时间。当系统需要检查一个连接是否仍然有效时,它会尝试发送一个验证请求。如果在validationTimeout指定的时间内没有收到响应或验证失败,系统会认为该连接已经失效,并可能采取相应的措施,如重新建立连接或报错。这个参数有助于确保连接的可靠性和稳定性,避免使用已经失效的连接导致的问题。
validationTimeout和keepaliveTime容易混淆,但是他们不同,的主要区别在于它们的用途和机制。validationTimeout用于验证连接的有效性,而keepaliveTime用于保持连接的活性。在实际应用中,根据具体需求和场景,可以合理设置这两个参数来确保网络连接的可靠性和稳定性。
1.8. leakDetectionThreshold
这个参数表示连接在被占用多少毫秒后被认为是泄露的。
如一个请求获取了链接,但是超过你设置的时间都还没用完,我们就会认定它为超时。一般它指挥记录泄露错误日志,但是不会终止程序。用于程序员检查日志排查问题。
2. 监测
2.1. 使用Datasource bean监测
只要我们注入一下DataSource 的bean就可以那大连接对象,并转换为 HikariDataSource 就可以方便拿到其中的属性值。
@Service public class HikariServiceImpl implements HikariService { @Autowired private DataSource dataSource; public HikariModel getHikariSetting(){ HikariModel hikariModel = new HikariModel(); HikariDataSource hikariDataSource = (HikariDataSource) dataSource; hikariModel.setAutoCommit (hikariDataSource.isAutoCommit()); hikariModel.setIdleTimeout (hikariDataSource.getIdleTimeout()); hikariModel.setKeepaliveTime (hikariDataSource.getKeepaliveTime()); hikariModel.setMaxLifetime (hikariDataSource.getMaxLifetime()); hikariModel.setConnectionTestQuery (hikariDataSource.getConnectionTestQuery()); hikariModel.setMinimumIdle (hikariDataSource.getMinimumIdle()); hikariModel.setMaximumPoolSize (hikariDataSource.getMaximumPoolSize()); hikariModel.setPoolName (hikariDataSource.getPoolName()); hikariModel.setConnectionTimeout (hikariDataSource.getConnectionTimeout()); hikariModel.setInitializationFailTimeout (hikariDataSource.getInitializationFailTimeout()); hikariModel.setIsolateInternalQueries (hikariDataSource.isIsolateInternalQueries()); hikariModel.setAllowPoolSuspension (hikariDataSource.isAllowPoolSuspension()); hikariModel.setReadOnly (hikariDataSource.isReadOnly()); hikariModel.setRegisterMbeans (hikariDataSource.isRegisterMbeans()); hikariModel.setValidationTimeout (hikariDataSource.getValidationTimeout()); hikariModel.setLeakDetectionThreshold (hikariDataSource.getLeakDetectionThreshold()); return hikariModel; } }
@Data public class HikariModel { private boolean autoCommit; private long idleTimeout; private long keepaliveTime; private long maxLifetime; private String connectionTestQuery; private int minimumIdle; private int maximumPoolSize; private String poolName; private Long connectionTimeout; private long initializationFailTimeout; private boolean isolateInternalQueries; private boolean allowPoolSuspension; private boolean readOnly; private boolean registerMbeans; private long validationTimeout; private long leakDetectionThreshold; }
2.2. 使用DB语句在DB中查看链接细节
须有权限执行sql语句
SELECT ds.*, dr.*, dc.* FROM Sys.dm_exec_requests dr WITH(nolock) RIGHT OUTER JOIN Sys.dm_exec_sessions ds WITH(nolock) ON dr.session_id = ds.session_id RIGHT OUTER JOIN Sys.dm_exec_connections dc WITH(nolock) ON ds.session_id = dc.session_id WHERE --ds.session_id > 50 and login_name='mingwang' and client_interface_name = 'Microsoft JDBC Driver 4.0'
2.3 通过设置YML 的log日志为debug监测hikari详细日志
logging: level: com.zaxxer.hikari: debug
2024-03-31 17:01:11.213 DEBUG 19920 --- [ool housekeeper] com.zaxxer.hikari.pool.HikariPool : allenHikariDBPool - keepalive: connection ConnectionID:2 ClientConnectionId: fe0dab8c-0191-41ef-90db-3f7866694488 is alive 2024-03-31 17:01:12.506 DEBUG 19920 --- [ool housekeeper] com.zaxxer.hikari.pool.HikariPool : allenHikariDBPool - keepalive: connection ConnectionID:1 ClientConnectionId: 8d73c429-975e-4ff2-a3f3-9eaf2d7afc8f is alive 2024-03-31 17:01:12.818 DEBUG 19920 --- [ool housekeeper] com.zaxxer.hikari.pool.HikariPool : allenHikariDBPool - Pool stats (total=2, active=0, idle=2, waiting=0) 2024-03-31 17:01:12.818 DEBUG 19920 --- [ool housekeeper] com.zaxxer.hikari.pool.HikariPool : allenHikariDBPool - Fill pool skipped, pool is at sufficient level. 2024-03-31 17:01:39.563 DEBUG 19920 --- [ool housekeeper] com.zaxxer.hikari.pool.HikariPool : allenHikariDBPool - keepalive: connection ConnectionID:2 ClientConnectionId: fe0dab8c-0191-41ef-90db-3f7866694488 is alive 2024-03-31 17:01:42.312 DEBUG 19920 --- [ool housekeeper] com.zaxxer.hikari.pool.HikariPool : allenHikariDBPool - keepalive: connection ConnectionID:1 ClientConnectionId: 8d73c429-975e-4ff2-a3f3-9eaf2d7afc8f is alive