连接池 Druid （三） - 获取连接 getConnection

Druid连接池只存储在connections数组中，所以获取连接的逻辑应该比HikariPool简单一些：直接从connectoins获取即可。

#### DruidDataSource.getConnection
直接上代码：
```
 @Override
    public DruidPooledConnection getConnection() throws SQLException {
        return getConnection(maxWait);
    }
```

调用了getConnection(maxWait)，maxWait是参数设定的获取连接的最长等待时间，超过该时长还没有获取到连接的话，抛异常。

看getConnection(maxWait)代码：
```
   public DruidPooledConnection getConnection(long maxWaitMillis) throws SQLException {
        init();

        if (filters.size() > 0) {
            FilterChainImpl filterChain = new FilterChainImpl(this);
            return filterChain.dataSource_connect(this, maxWaitMillis);
        } else {
            return getConnectionDirect(maxWaitMillis);
        }
    }

```
先调用init，init方法会判断连接池是否已经完成了初始化，如果没有完成初始化则首先进行初始化，初始化的代码我们上一篇文章已经分析过了。

之后判断是否有filters，filters的内容我们先放放，暂时不管，直接看没有filters的情况下，调用getConnectionDirect方法。

#### getConnectionDirect
方法比较长，我们还是老办法，分段分析：
```
   public DruidPooledConnection getConnectionDirect(long maxWaitMillis) throws SQLException {
        int notFullTimeoutRetryCnt = 0;
        for (;;) {
            // handle notFullTimeoutRetry
            DruidPooledConnection poolableConnection;
            try {
                poolableConnection = getConnectionInternal(maxWaitMillis);
            } catch (GetConnectionTimeoutException ex) {
                if (notFullTimeoutRetryCnt <= this.notFullTimeoutRetryCount && !isFull()) {
                    notFullTimeoutRetryCnt++;
                    if (LOG.isWarnEnabled()) {
                        LOG.warn("get connection timeout retry : " + notFullTimeoutRetryCnt);
                    }
                    continue;
                }
                throw ex;
            }
```
上来之后首先无限for循环，目的是从连接池获取到连接之后，根据参数设定可能会做必要的检查，如果检查不通过（比如连接不可用、连接已关闭等等）的话循环重新获取。

然后调用getConnectionInternal获取连接，getConnectionInternal方法应该是我们今天文章的主角，我们稍微放一放，为了文章的可读性，先分析完getConnectionDirect方法。

我们假设通过调用getConnectionInternal方法获取到一个连接（注意获取到的连接对象是DruidPooledConnection，不是Connection对象，这个也不难想象，连接池获取到的连接一定是数据库物理连接的代理对象（或者叫封装对象，封装了数据库物理连接Connection对象的对象，这个原理我们在分析HikariPool的时候已经说过了。这个DruidPooledConnection对象我们也暂时放一放，后面分析）。

调用getConnectionInternal方法如果返回超时异常，判断：如果当前连接池没满，而且获取连接超时重试次数小于参数notFullTimeoutRetryCount设定的次数的话，则continue，重新获取连接。否则，抛出超时异常。

接下来：
```
             if (testOnBorrow) {
                boolean validate = testConnectionInternal(poolableConnection.holder, poolableConnection.conn);
                if (!validate) {
                    if (LOG.isDebugEnabled()) {
                        LOG.debug("skip not validate connection.");
                    }

                    discardConnection(poolableConnection.holder);
                    continue;
                }
            } else {
                if (poolableConnection.conn.isClosed()) {
                    discardConnection(poolableConnection.holder); // 传入null，避免重复关闭
                    continue;
                }          
```
testOnBorrow参数的目的是：获取连接后是否要做连接可用性测试，如果设定为true的话，调用testConnectionInternal测试连接的可用性，testConnectionInternal方法上一篇文章分析连接回收的时候、处理keepAlive的过程中就碰到过，就是执行配置好的sql语句测试连接可用性，如果测试不通过的话则调用discardConnection关闭连接，continue重新获取连接。

否则，如果testOnBorrow参数没有打开的话，检查当前连接如果已经关闭，则调用discardConnection关闭连接（没太明白连接既然已经是关闭状态，为啥还需要调用？），continue重新获取连接。

***不建议打开testOnBorrow参数，因为连接池都会有连接回收机制，比如上一篇文章讲过的Druid的DestroyConnectionThread & DestroyTask，回收参数配置正常的话，回收机制基本可以确保连接的可用性。打开testOnBorrow参数会导致每次获取连接之后都测试连接的可用性，严重影响系统性能。***

接下来：
```
          if (testWhileIdle) {
                    final DruidConnectionHolder holder = poolableConnection.holder;
                    long currentTimeMillis             = System.currentTimeMillis();
                    long lastActiveTimeMillis          = holder.lastActiveTimeMillis;
                    long lastExecTimeMillis            = holder.lastExecTimeMillis;
                    long lastKeepTimeMillis            = holder.lastKeepTimeMillis;

                    if (checkExecuteTime
                            && lastExecTimeMillis != lastActiveTimeMillis) {
                        lastActiveTimeMillis = lastExecTimeMillis;
                    }

                    if (lastKeepTimeMillis > lastActiveTimeMillis) {
                        lastActiveTimeMillis = lastKeepTimeMillis;
                    }

                    long idleMillis                    = currentTimeMillis - lastActiveTimeMillis;

                    long timeBetweenEvictionRunsMillis = this.timeBetweenEvictionRunsMillis;

                    if (timeBetweenEvictionRunsMillis <= 0) {
                        timeBetweenEvictionRunsMillis = DEFAULT_TIME_BETWEEN_EVICTION_RUNS_MILLIS;
                    }

                    if (idleMillis >= timeBetweenEvictionRunsMillis
                            || idleMillis < 0 // unexcepted branch
                            ) {
                        boolean validate = testConnectionInternal(poolableConnection.holder, poolableConnection.conn);
                        if (!validate) {
                            if (LOG.isDebugEnabled()) {
                                LOG.debug("skip not validate connection.");
                            }

                            discardConnection(poolableConnection.holder);
                             continue;
                        }
                    }
                }
            }          
```
这段代码的逻辑是：参数testWhileIdle设置为true的话，检查当前链接的空闲时长如果大于timeBetweenEvictionRunsMillis（默认60秒）的话，则调用testConnectionInternal测试连接可用性，连接不可用则关闭连接，continue重新获取连接。

然后：
```
      if (removeAbandoned) {
                StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();
                poolableConnection.connectStackTrace = stackTrace;
                poolableConnection.setConnectedTimeNano();
                poolableConnection.traceEnable = true;

                activeConnectionLock.lock();
                try {
                    activeConnections.put(poolableConnection, PRESENT);
                } finally {
                    activeConnectionLock.unlock();
                }
            }
```
出现了一个removeAbandoned参数，这个参数的意思是移除被遗弃的连接对象，如果打开的话就把当前连接放到activeConnections中，篇幅有限，这部分内容就不展开了，后面我们会专门写一篇文章介绍removeAbandoned参数。

剩下的一小部分代码，很简单，根据参数设置连接的autoCommit，之后返回连接poolableConnection。
```
            if (!this.defaultAutoCommit) {
                poolableConnection.setAutoCommit(false);
            }

            return poolableConnection;
        }
    }
```

getConnectionDirect方法源码分析完成了，下面我们要看一下getConnectionInternal方法，这是真正从连接池中获取连接的方法。

#### getConnectionInternal
直接看代码：
```
   private DruidPooledConnection getConnectionInternal(long maxWait) throws SQLException {
        if (closed) {
            connectErrorCountUpdater.incrementAndGet(this);
            throw new DataSourceClosedException("dataSource already closed at " + new Date(closeTimeMillis));
        }

        if (!enable) {
            connectErrorCountUpdater.incrementAndGet(this);

            if (disableException != null) {
                throw disableException;
            }

            throw new DataSourceDisableException();
        }
        final long nanos = TimeUnit.MILLISECONDS.toNanos(maxWait);
        final int maxWaitThreadCount = this.maxWaitThreadCount;

        DruidConnectionHolder holder;
```
检查连接池状态如果已经disable或cloesed的话，抛异常。

接下来：
```
       for (boolean createDirect = false;;) {
            if (createDirect) {
                createStartNanosUpdater.set(this, System.nanoTime());
                if (creatingCountUpdater.compareAndSet(this, 0, 1)) {
                    PhysicalConnectionInfo pyConnInfo = DruidDataSource.this.createPhysicalConnection();
                    holder = new DruidConnectionHolder(this, pyConnInfo);
                    holder.lastActiveTimeMillis = System.currentTimeMillis();

                    creatingCountUpdater.decrementAndGet(this);
                    directCreateCountUpdater.incrementAndGet(this);

                    if (LOG.isDebugEnabled()) {
                        LOG.debug("conn-direct_create ");
                    }

                    boolean discard = false;
                    lock.lock();
                    try {
                        if (activeCount < maxActive) {
                            activeCount++;
                            holder.active = true;
                            if (activeCount > activePeak) {
                                activePeak = activeCount;
                                activePeakTime = System.currentTimeMillis();
                            }
                            break;
                        } else {
                            discard = true;
                        }
                    } finally {
                        lock.unlock();
                    }

                    if (discard) {
                        JdbcUtils.close(pyConnInfo.getPhysicalConnection());
                    }
                }
            }
```
初始化createDirect变量为false之后启动无限循环，意思是不断循环直到获取到连接、或超时等其他异常情况发生。

紧接着的这段代码是createDirect=true的情况下执行的，createDirect是在下面循环体中检查如果：createScheduler不为空、连接池空、活动连接数小于设定的最大活动连接数maxActive、并且createScheduler的队列中排队等待创建连接的线程大于0的情况下，设置createDirect为true的，以上这些条件如果成立的话，大概率表明createScheduler中的创建线程出问题了、所以createScheduler大概率指望不上了，所以要直接创建连接了。

直接创建的代码也很容易理解，调用createPhysicalConnection创建物理连接，创建DruidConnectionHolder封装该物理连接，创建之后获取锁资源，检查activeCount < maxActive则表明创建连接成功、结束for循环，否则，activeCount >= maxActive则说明违反了原则（直接创建连接的过程中createScheduler可能复活了、又创建出来连接放入连接池中了），所以，关闭锁资源之后，将刚创建出来的连接关闭。

然后：
```
try {
                lock.lockInterruptibly();
            } catch (InterruptedException e) {
                connectErrorCountUpdater.incrementAndGet(this);
                throw new SQLException("interrupt", e);
            }

            try {
                if (maxWaitThreadCount > 0
                        && notEmptyWaitThreadCount >= maxWaitThreadCount) {
                    connectErrorCountUpdater.incrementAndGet(this);
                    throw new SQLException("maxWaitThreadCount " + maxWaitThreadCount + ", current wait Thread count "
                            + lock.getQueueLength());
                }

                if (onFatalError
                        && onFatalErrorMaxActive > 0
                        && activeCount >= onFatalErrorMaxActive) {
                    connectErrorCountUpdater.incrementAndGet(this);

                    StringBuilder errorMsg = new StringBuilder();
                    errorMsg.append("onFatalError, activeCount ")
                            .append(activeCount)
                            .append(", onFatalErrorMaxActive ")
                            .append(onFatalErrorMaxActive);

                    if (lastFatalErrorTimeMillis > 0) {
                        errorMsg.append(", time '")
                                .append(StringUtils.formatDateTime19(
                                        lastFatalErrorTimeMillis, TimeZone.getDefault()))
                                .append("'");
                    }

                    if (lastFatalErrorSql != null) {
                        errorMsg.append(", sql \n")
                                .append(lastFatalErrorSql);
                    }

                    throw new SQLException(
                            errorMsg.toString(), lastFatalError);
                }

                connectCount++;

                if (createScheduler != null
                        && poolingCount == 0
                        && activeCount < maxActive
                        && creatingCountUpdater.get(this) == 0
                        && createScheduler instanceof ScheduledThreadPoolExecutor) {
                    ScheduledThreadPoolExecutor executor = (ScheduledThreadPoolExecutor) createScheduler;
                    if (executor.getQueue().size() > 0) {
                        createDirect = true;
                        continue;
                    }
                }
```
获取锁资源，检查等待获取连接的线程数如果大于参数设置的最大等待线程数，抛异常。

检查并处理异常。

累加connectCount。

之后是上面提到过的对createDirect的处理。

接下来到了最为关键的部分，一般情况下createDirect为false，不会直接创建连接，逻辑会走到下面这部分代码中，从连接池中获取连接：
```
               if (maxWait > 0) {
                    holder = pollLast(nanos);
                } else {
                    holder = takeLast();
                }

                if (holder != null) {
                    if (holder.discard) {
                        continue;
                    }

                    activeCount++;
                    holder.active = true;
                    if (activeCount > activePeak) {
                        activePeak = activeCount;
                        activePeakTime = System.currentTimeMillis();
                    }
                }
            } catch (InterruptedException e) {
                connectErrorCountUpdater.incrementAndGet(this);
                throw new SQLException(e.getMessage(), e);
            } catch (SQLException e) {
                connectErrorCountUpdater.incrementAndGet(this);
                throw e;
            } finally {
                lock.unlock();
            }     
```
如果参数设置了maxWait，则调用pollLast限时获取，否则调用takeLast获取连接，这两个方法稍后分析。

之后检查获取到的连接已经被discard的话，continue重新获取连接。

释放锁资源。

从连接池中获取到了连接，结束for循环。

如果takeLast或poolLast返回的DruidConnectionHolder为null的话（调用poolLast超时），处理错误信息，抛GetConnectionTimeoutException超时异常（这部分代码没有贴出，省略了......感兴趣的童鞋自己打开源码看一下）。

否则，用DruidConnectionHolder封装创建DruidPooledConnection后返回。

#### takeLast & pollLast(nanos)
这两个方法的逻辑其实差不多，主要区别一个是限时，一个不限时，两个方法都是在锁状态下执行。

具体调用哪一个方法取决于参数maxWait，默认值为-1，默认情况下会调用takeLast，获取连接的时候不限时。

***建议设置maxWait，否则在特殊情况下如果创建连接失败、会导致应用层线程挂起，获取不到任何返回的情况出现。如果设置了maxWait，getConnection方法会调用pollLast(nanos)，获取不到连接后，应用层会得到连接超时的反馈。***

先看takeLast方法：
```
takeLast() throws InterruptedException, SQLException {
        try {
            while (poolingCount == 0) {
                emptySignal(); // send signal to CreateThread create connection

                if (failFast && isFailContinuous()) {
                    throw new DataSourceNotAvailableException(createError);
                }

                notEmptyWaitThreadCount++;
                if (notEmptyWaitThreadCount > notEmptyWaitThreadPeak) {
                    notEmptyWaitThreadPeak = notEmptyWaitThreadCount;
                }
                try {
                    notEmpty.await(); // signal by recycle or creator
                } finally {
                    notEmptyWaitThreadCount--;
                }
                notEmptyWaitCount++;

                if (!enable) {
                    connectErrorCountUpdater.incrementAndGet(this);
                    if (disableException != null) {
                        throw disableException;
                    }

                    throw new DataSourceDisableException();
                }
            }
        } catch (InterruptedException ie) {
            notEmpty.signal(); // propagate to non-interrupted thread
            notEmptySignalCount++;
            throw ie;
        }

        decrementPoolingCount();
        DruidConnectionHolder last = connections[poolingCount];
        connections[poolingCount] = null;

        return last;
    }
```
如果连接池为空(poolingCount == 0)的话，无限循环。

调用emptySignal()，通知创建连接线程，有人在等待获取连接，抓紧时间创建连接。

然后调用notEmpty.await()，等待创建连接线程在完成创建、或者有连接归还到连接池中后唤醒通知。

如果发生异常，调用一下notEmpty.signal()通知其他获取连接的线程，没准自己没能获取成功、其他线程能获取成功。

下面的代码，线程池一定不空了。

线程池的线程数量减1（decrementPoolingCount），然后获取connections的最后一个元素返回。

pollLast方法的代码逻辑和takeLast的类似，只不过线程池空的话，当前线程会限时挂起等待，超时仍然不能获取到连接的话，直接返回null。

***Druid连接池获取连接代码分析完毕！***

#### 小结
Druid连接池的连接获取过程的源码分析完毕，后面还有连接归还过程，下一篇文章继续分析。

Thanks a lot!

上一篇 [连接池 Druid （二） - 连接回收 DestroyConnectionThread & DestroyTask](https://segmentfault.com/a/1190000043722829)