本文共 9944 字，大约阅读时间需要 33 分钟。

前言

“数据连接池”想必是做为程序员必知的词汇。而“连接池”是最近风起的当属“HikariCP”以及阿里的“Druid”。

为什么选择

比较了Druid和HikariCP。

1. Druid侧重于监控。Filter链路的设计及druid-parser【SQL解析器】可以很好的自定义的逻辑
2. HikariCP侧重于效率和简洁。无锁及代码的简洁

我认同一网友的观点：数据连接占链路的效率比重是小的，有时间监控更重要。但我更认同的观点：连接池，让他干连接池的事情，简单一些

源码分析

从一个简单的例子入手

HikariDataSource hikariDataSource = new HikariDataSource();        //driverClassName无需指定，除非系统无法自动识别        hikariDataSource.setDriverClassName("com.mysql.cj.jdbc.Driver");        //database address        hikariDataSource.setJdbcUrl("jdbc:mysql://localhost/test?logger=Slf4JLogger");        //useName 用户名        hikariDataSource.setUsername("sa");        //password        hikariDataSource.setPassword("sa");               Connection conn = hikariDataSource.getConnection();        Statement stat = conn.createStatement();        ResultSet rs = stat.executeQuery("select * from users");        //5.遍历结果集获取查询对象        while (rs.next()) {            String name = rs.getString("username");            log.info(name);        }

初始化

getConnection是获取连接的主要方法

public Connection getConnection() throws SQLException   {      //如果连接池已初始化，则直接从池中获取      if (fastPathPool != null) {         return fastPathPool.getConnection();      }      // 第二种配置方式会在第一次 getConnectionI() 时初始化pool      HikariPool result = pool;      if (result == null) {         synchronized (this) {            result = pool;            if (result == null) {                  pool = result = new HikariPool(this);                           }         }      }      return result.getConnection();   }

其实这里的两个HikariPool的不同取值代表了不同的配置方式：

1. 当通过有参构造new HikariDataSource(HikariConfig configuration)来创建HikariDataSource时，fastPathPool 和 pool 是非空且相同的；
2. 当通过无参构造new HikariDataSource()来创建HikariDataSource并手动配置时，fastPathPool 为空，pool 不为空（在第一次 getConnectionI() 时初始化）

针对以上两种配置方式，其实使用一个 pool 就可以完成，那为什么会有两个? 被 volatile 修饰，为了实现数据一致性会出现不必要的开销

HikariPool 的几个属性说明如下：

获取连接

获取连接的核心类是connectionBag，下面简单介绍下几个字段的作用：

获取-borrow的方法：

public T borrow(long timeout, final TimeUnit timeUnit) throws InterruptedException   {      // 1. 首先从threadList获取对象             // 获取绑定在当前线程的List

在以上方法中，唯一可能出现线程切换到就是handoffQueue.poll(timeout, NANOSECONDS)，除此之外，我们没有看到任何的 synchronized 和 lock。之所以可以做到这样主要由于以下几点：

1. 元素状态的引入，以及使用CAS方法修改状态。在ConcurrentBag中，使用使用中、未使用、删除和保留等表示元素的状态，而不是使用不同的集合来维护不同状态的元素。元素状态这一概念的引入非常关键，为后面的几点提供了基础。 ConcurrentBag的方法中多处调用 CAS 方法来判断和修改元素状态，这一过程不需要加锁。
2. threadList 的使用。当前线程归还的元素会被绑定到ThreadLocal，该线程再次获取元素时，在该元素未被偷走的前提下可直接获取到，不需要去 sharedList 遍历获取；
3. 采用CopyOnWriteArrayList来存放元素。在CopyOnWriteArrayList中，读和写使用的是不同的数组，避免了两者的锁竞争，至于多个线程写入，则会加 ReentrantLock 锁。
4. sharedList 的读写控制。borrow 和 requite 对 sharedList 来说都是不加锁的，缺点就是会牺牲一致性。用户线程无法进行增加元素的操作，只有 addConnectionExecutor 可以，而 addConnectionExecutor 只会开启一个线程执行任务，所以 add 操作不会存在锁竞争。至于 remove 是唯一会造成锁竞争的方法，这一点我认为也可以参照 addConnectionExecutor 来处理，在加入任务队列前把 PoolEntry 的状态标记为删除中。

其实，我们会发现，ConcurrentBag在减少锁冲突的问题上，除了设计改进，还使用了比较多的 JDK 特性。

归还-requite的方法

public void requite(final T bagEntry)   {      //先将状态置为 STATE_NOT_IN_USE      bagEntry.setState(STATE_NOT_IN_USE);     // 判断是否存在等待线程，若存在，则直接转手资源      for (int i = 0; waiters.get() > 0; i++) {         if (bagEntry.getState() != STATE_NOT_IN_USE || handoffQueue.offer(bagEntry)) {            return;         }         // 如果迭代255次，那就说说明虽然很多的线程访问，但是都是在sharedList 获取阶段         // 那就挂起10毫秒          else if ((i & 0xff) == 0xff) {            parkNanos(MICROSECONDS.toNanos(10));         }         else {            yield();         }      }        // 否则，进行资源本地化      final List

添加连接-add

//borrow触发 public void addBagItem(final int waiting) {            final boolean shouldAdd = waiting - addConnectionQueue.size() >= 0; // Yes, >= is intentional.      if (shouldAdd) {         //提交创建任务         addConnectionExecutor.submit(POOL_ENTRY_CREATOR);      } }//创建任务private final class PoolEntryCreator implements Callable
   
       {            public Boolean call() throws Exception      {         while (poolState == POOL_NORMAL && shouldCreateAnotherConnection()) {            //创建连接入如包中            final PoolEntry poolEntry = createPoolEntry();            if (poolEntry != null) {               connectionBag.add(poolEntry);               return Boolean.TRUE;            }            // failed to get connection from db, sleep and retry         }         // Pool is suspended or shutdown or at max size         return Boolean.FALSE;      }      private boolean shouldCreateAnotherConnection() {         // only create connections if we need another idle connection or have threads still waiting         // for a new connection, otherwise bail         return getTotalConnections() < config.getMaximumPoolSize() &&            (connectionBag.getWaitingThreadCount() > 0 || getIdleConnections() < config.getMinimumIdle());      }   }//加入包裹中public void add(final T bagEntry)   {            sharedList.add(bagEntry);     //旋转直到有线程取走它或没有任何线程等待      while (waiters.get() > 0 && bagEntry.getState() == STATE_NOT_IN_USE && !handoffQueue.offer(bagEntry)) {         yield();      }   }
   

清除连接-remove

初始化的时候, houseKeeperTask 设置为 initialDelay = 100L, 每隔30S(默认) 运行一次closeConnection 或者 填充 connection

                
                 
     
      org.codehaus.mojo
                 
     
      exec-maven-plugin
                 
     
      1.5.0
                 
                    
                        
       
        compile
                         
                         
                            
        
         java
                          
                      
                  
                 
                    
      
       com.zaxxer.hikari.util.JavassistProxyFactory
                  
              
    

HikariCP 的源码轻巧且简单。可借鉴"Druid"监控做法，慢慢的完善。但不要破坏了单一原则

主要参考

《》

《》

《》

《》

《》

转载地址：https://blog.csdn.net/y3over/article/details/52439288 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！