亲宝软件园·资讯

展开

Hikari 数据库连接池内部源码实现的小细节

brucelwl 人气:0

Hikari 默认几个超时配置

连接创建超时时间 30s 

private static final long CONNECTION_TIMEOUT = SECONDS.toMillis(30);

连接存活验证时间5s,这个时间就是验证时socketTimeout,验证之后恢复为0,

但是真正做数据查询时默认为0,表示永不超时

private static final long VALIDATION_TIMEOUT = SECONDS.toMillis(5);

连接空闲时间10分钟

private static final long IDLE_TIMEOUT = MINUTES.toMillis(10);

连接最大存活时间30分钟

private static final long MAX_LIFETIME = MINUTES.toMillis(30);

Hikari 连接池中默认连接数量为10

默认最小连接数等于最大相同未为10

private static final int DEFAULT_POOL_SIZE = 10;

Hikari通过CopyOnWriteArrayList保存所有的连接

com.zaxxer.hikari.util.ConcurrentBag#sharedList

线程无法获取连接时通过SynchronousQueue实现公平阻塞等待

当池的连接被用尽,Hikari通过SynchronousQueue实现让线程阻塞等待,并且采用的是公平锁。

源码见com.zaxxer.hikari.util.ConcurrentBag#handoffQueue以及com.zaxxer.hikari.util.ConcurrentBag#ConcurrentBag构造方法

Hikari内部有三个单线程的 线程池 对象

何谓软驱逐

池中连接的创建,关闭,除了初始化时只同步创建1条,其它都是异步的。

一个connection本质上就是一个socket连接

一个连接池中,有多少个connection连接则对应多少个 socket 对象与服务端的连接。

Hikari中会使用ThreadLocal来将连接绑定到线程

Hikari为了提高从池中获取连接的性能,通过ThreadLocal来避免资源竞争,一个connection可以对应多个Thread,一个Thread可以绑定多个connection,源码见ConcurrentBag类中的成员变量private final ThreadLocal<List<Object>> threadList;

为什么ThreadLocal里面的泛型是List< Object >?

因为一个connection可以在不同时期被多个线程使用,当另一个线程绑定的connection正在被别的线程使用时,就需要选择其它没有被使用的connection,新选择的connection同样需要绑定到这条线程,所以使用的是List来保存。

源码见:com.zaxxer.hikari.util.ConcurrentBag#borrow

什么时候向ThreadLocal里面保存connection?

当调用连接池中connection释放资源的时候回收,这里的connection实际上是Hikari实现的一个代理类(ProxyConnection),封装了JDBC 连接。

源码见:com.zaxxer.hikari.pool.ProxyConnection#close

Hikari如何做到连接的回收

通过ProxyConnection代理类来实现。

源码见:com.zaxxer.hikari.pool.ProxyConnection#close

Hikari通过CAS乐观锁来控制连接当前状态

Hikari通过PoolEntry来封装Connection,并通过private volatile int state来记录Connection当前状态,主要有如下几个枚举值,并通过CAS乐观锁来维护这些状态,提高多线程之间获取连接的性能.

public interface IConcurrentBagEntry{
  int STATE_NOT_IN_USE = 0;
  int STATE_IN_USE = 1;
  int STATE_REMOVED = -1;
  int STATE_RESERVED = -2;

  boolean compareAndSet(int expectState, int newState);
  void setState(int newState);
  int getState();
}

获取连接,对验证连接可用性的优化

每次从池中获取连接后,先判断连接最后访问时间和当前时间差,如果小于500ms,则直接认为连接是可用的,避免向服务器发送验证的sql语句,提高连接池性能。

源码见:com.zaxxer.hikari.pool.HikariPool#getConnection(long hardTimeout)

 if (poolEntry.isMarkedEvicted() || (elapsedMillis(poolEntry.lastAccessed, now) > aliveBypassWindowMs && !isConnectionAlive(poolEntry.connection))) {
    closeConnection(poolEntry, poolEntry.isMarkedEvicted() ? EVICTED_CONNECTION_MESSAGE : DEAD_CONNECTION_MESSAGE);
    timeout = hardTimeout - elapsedMillis(startTime);
 }

否则需要验证连接可用性:

如果配置了connection-test-query则使用配置sql验证,否则使用数据库驱动程序实现的java.sql.Connection#isValid(int timeout)方法验证。

源码见:com.zaxxer.hikari.pool.PoolBase#isConnectionAlive

如果连接不可用,会输出警告日志

如果验证连接可用性过程,连接因为数据库wait_timeout超时被服务端关闭,或者网络异常,则会出现如下警告日志,

Failed to validate connection com.mysql.cj.jdbc.ConnectionImpl@2e2ce118 (No operations allowed after connection closed.). Possibly consider using a shorter maxLifetime value.

解决方案参考我的另一篇博客:Failed to validate connection com.mysql.cj.jdbc.ConnectionImpl问题排查

总结

以上为个人经验,希望能给大家一个参考,也希望大家多多支持。

加载全部内容

相关教程
猜你喜欢
用户评论