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