高并发服务优化篇：浅谈数据库连接池

被N多大号转载的一篇CSDN博客，引起了我的注意，说的是数据库连接池使用threadlocal的原因，文中结论如下图所示。

来自CSDN的一篇文章，被很多号转载过

姑且不谈threadlocal的作用和工作原理，单说数据库连接池这个知识点，猛地一看挺有理；仔细一看，怎么感觉不太对啊，同学，这是什么虎狼之词。

$ 实践是检验真理的唯一标准

个人理解，连接池提供的获取连接的能力，需要对"任务"唯一，即，只有当某一线程完成了本次数据操作，将连接放回到连接池之后，其他线程才能够再次获取并使用。原因我们后面细说，先来亲自测试一下。

连接池选一个druid，设置连接池中只有一个connection，方便验证多线程应对同一个connection的场景。

首先，将datasource共享资源传入线程，采用datasource.getConnection()方式获取连接 :

注：Runnable中故意不执行connection.close

结果如上图：只有一个线程可以正常执行，由于没有被关闭，其他线程都获取连接失败了。说明，数据库连接池的作用方式是某个线程任务"独占"的。

$ 退一步来讲

假设如同开头文章中描述的，用了一个功能不完备的连接池，让多个线程拿到了同一个connection，那么，用threadlocal真的可以起到互不影响的作用么？

//验证思路参考自：https://blog.csdn.net/sunbo94/article/details/79409298
//Connection设置 autoCommit=false
private static final ThreadLocal<Connection> connectionThreadLocal=new ThreadLocal<>();

private static class InnerRunner implements Runnable{
   @Override
   public void run() {
       //其他代码省略...
       String insertSql="insert into user(id,name) value("+RunnerIndex+","+RunnerIndex+")";
       statement=connectionThreadLocal.get().createStatement();
       statement.executeUpdate(insertSql);
       System.out.println(RunnerIndex+" is running");
       //让特定的线程执行回滚，用来验证事务之间的影响
       if (RunnerIndex==3){