数据库连接池的作用数据库连接池的作用原始的数据库连接步骤存在的问题：每一次web请求都要建立一次数据库连接。建立连接

数据库连接池的作用

原始的数据库连接步骤

Public void FindAllUsers(){
  //1、装载sqlserver驱动对象
  DriverManager.registerDriver(new SQLServerDriver());             
  //2、通过JDBC建立数据库连接
  Connection con = DriverManager.getConnection(
      "jdbc:sqlserver://192.168.2.6:3306", "sa", "123");            
  //3、创建状态
  Statement state =con.createStatement();           
  //4、查询数据库并返回结果
  ResultSet result =state.executeQuery("select * from users");           
  //5、输出查询结果
  while(result.next()) {
     System.out.println(result.getString("email"));
  }            
  //6、断开数据库连接
  result.close();
  state.close();
  con.close();
}

存在的问题：每一次web请求都要建立一次数据库连接。建立连接是一个费时的活动，每次都得花费0.05s～1s的时间，而且系统还要分配内存资源。其次，对于每一次数据库连接，使用完后都得断开。否则，如果程序出现异常而未能关闭，将会导致数据库系统中的内存泄漏，最终将不得不重启数据库。还有，这种开发不能控制被创建的连接对象数，系统资源会被毫无顾及的分配出去，如连接过多，也可能导致内存泄漏，服务器崩溃。

可以看出，“数据库连接”是一种稀缺的资源，为了保障网站的正常使用，应该对其进行妥善管理。其实我们查询完数据库后，如果不关闭连接，而是暂时存放起来，当别人使用时，把这个连接给他们使用。就避免了一次建立数据库连接和断开的操作时间消耗。

为了解决资源的频繁分配﹑释放所造成的问题。为解决上述问题，可以采用数据库连接池技术。数据库连接池的基本思想就是为数据库连接建立一个“缓冲池”。预先在缓冲池中放入一定数量的连接，当需要建立数据库连接时，只需从“缓冲池”中取出一个，使用完毕之后再放回去。我们可以通过设定连接池最大连接数来防止系统无尽的与数据库连接。更为重要的是我们可以通过连接池的管理机制监视数据库的连接的数量﹑使用情况，为系统开发﹑测试及性能调整提供依据。

自己实现一个简单的数据库连接池

public class MyDataSource implements DataSource {
      //链表 --- 实现栈结构
      privateLinkedList<Connection> dataSources = new LinkedList<Connection>();

      //初始化连接数量
      publicMyDataSource() {
         //一次性创建10个连接
         for(int i = 0; i < 10; i++) {
            try {
               //1、装载sqlserver驱动对象
               DriverManager.registerDriver(new SQLServerDriver());
               //2、通过JDBC建立数据库连接
               Connection con =DriverManager.getConnection(
                  "jdbc:sqlserver://192.168.2.6:1433;DatabaseName=customer", "sa", "123");
               //3、将连接加入连接池中
               dataSources.add(con);
            } catch (Exception e) {
               e.printStackTrace();
            }
         }
      }

      @Override
      publicConnection getConnection() throws SQLException {
         //取出连接池中一个连接
         finalConnection conn = dataSources.removeFirst(); // 删除第一个连接返回
         returnconn;
      }

      //将连接放回连接池
      public void releaseConnection(Connection conn) {
         dataSources.add(conn);
      }
}

Public void FindAllUsers() {
  //1、使用连接池建立数据库连接
  MyDataSource dataSource = new MyDataSource();
  Connection conn =dataSource.getConnection();        
  //2、创建状态
  Statement state =con.createStatement();           
  //3、查询数据库并返回结果
  ResultSet result =state.executeQuery("select * from users");           
  //4、输出查询结果
  while(result.next()) {
     System.out.println(result.getString("email"));
  }            
  //5、断开数据库连接
  result.close();
  state.close();
  //6、归还数据库连接给连接池
  dataSource.releaseConnection(conn);
}

以上就是数据库连接池的原理，它大大提供了数据库连接的利用率，减小了内存吞吐的开销。我们在开发过程中，就不需要再关心数据库连接的问题，自然有数据库连接池帮助我们处理。

连接池的分配与释放

连接池的分配与释放，对系统的性能有很大的影响。合理的分配与释放，可以提高连接的复用度，从而降低建立新连接的开销，同时还可以加快用户的访问速度。

对于连接的管理可使用空闲池。即把已经创建但尚未分配出去的连接按创建时间存放到一个空闲池中。每当用户请求一个连接时，系统首先检查空闲池内有没有空闲连接。如果有就把建立时间最长（通过容器的顺序存放实现）的那个连接分配给他（实际是先做连接是否有效的判断，如果可用就分配给用户，如不可用就把这个连接从空闲池删掉，重新检测空闲池是否还有连接）；如果没有则检查当前所开连接池是否达到连接池所允许的最大连接数（maxconn）如果没有达到，就新建一个连接，如果已经达到，就等待一定的时间（timeout）。如果在等待的时间内有连接被释放出来就可以把这个连接分配给等待的用户，如果等待时间超过预定时间timeout 则返回空值（null）。系统对已经分配出去正在使用的连接只做计数，当使用完后再返还给空闲池。对于空闲连接的状态，可开辟专门的线程定时检测，这样会花费一定的系统开销，但可以保证较快的响应速度。也可采取不开辟专门线程，只是在分配前检测的方法。

连接池的配置与维护

连接池中到底应该放置多少连接，才能使系统的性能最佳？系统可采取设置最小连接数（minconn）和最大连接数（maxconn）来控制连接池中的连接。最小连接数是系统启动时连接池所创建的连接数。如果创建过多，则系统启动就慢，但创建后系统的响应速度会很快；如果创建过少，则系统启动的很快，响应起来却慢。这样，可以在开发时，设置较小的最小连接数，开发起来会快，而在系统实际使用时设置较大的，因为这样对访问客户来说速度会快些。最大连接数是连接池中允许连接的最大数目，具体设置多少，要看系统的访问量，可通过反复测试，找到最佳点。

如何确保连接池中的最小连接数呢？有动态和静态两种策略。动态即每隔一定时间就对连接池进行检测，如果发现连接数量小于最小连接数，则补充相应数量的新连接以保证连接池的正常运转。静态是发现空闲连接不够时再去检查。

连接池设置多少连接数合适？

即使是单核CPU的计算机也能“同时”运行数百个线程。但我们都知道这只不过是操作系统用时间分片玩的一个小把戏。一颗CPU核心同一时刻只能执行一个线程，然后操作系统切换上下文，核心开始执行另一个线程的代码，以此类推。给定一颗CPU核心，其顺序执行A 和B 永远比通过时间分片“同时”执行A 和B 要快，这是一条计算机科学的基本法则。一旦线程的数量超过了CPU核心的数量，再增加线程数系统就只会更慢，而不是更快。

上面的说法只能说是接近真相，但还并没有这么简单，有一些其他的因素需要加入。当我们寻找数据库的性能瓶颈时，总是可以将其归为三类：CPU、磁盘、网络。把_内存_加进来也没有错，但比起_磁盘_和_网络_，内存的带宽要高出好几个数量级，所以就先不加了。

如果我们无视_磁盘_和_网络_，那么结论就非常简单。在一个8核的服务器上，设定连接/线程数为8能够提供最优的性能，再增加连接数就会因上下文切换的损耗导致性能下降。数据库通常把数据存储在磁盘上，磁盘又通常是由一些旋转着的金属碟片和一个装在步进马达上的读写头组成的。读/写头同一时刻只能出现在一个地方，然后它必须“寻址”到另外一个位置来执行另一次读写操作。所以就有了寻址的耗时，此外还有旋回耗时，读写头需要等待碟片上的目标数据“旋转到位”才能进行操作。使用缓存当然是能够提升性能的，但上述原理仍然成立。

在这一时间段（即"I/O等待"）内，线程是在“阻塞”着等待磁盘，此时操作系统可以将那个空闲的CPU核心用于服务其他线程。所以，由于线程总是在I/O上阻塞，我们可以让线程/连接数比CPU核心多一些，这样能够在同样的时间内完成更多的工作。（需要等待读写头旋转到数据所在的位置，此时线程阻塞着等待磁盘，CPU空闲）

那么应该多多少呢？这要取决于_磁盘_。较新型的SSD不需要寻址，也没有旋转的碟片。可别想当然地认为“SSD速度更快，所以我们应该增加线程数”，恰恰相反，无需寻址和没有旋回耗时意味着更少的阻塞，所以更少的线程[更接近于CPU核心数]会发挥出更高的性能。只有当阻塞创造了更多的执行机会时，更多的线程数才能发挥出更好的性能。

_网络_和_磁盘_类似。通过以太网接口读写数据时也会形成阻塞，10G带宽会比1G带宽的阻塞少一些，1G带宽又会比100M带宽的阻塞少一些。不过网络通常是放在第三位考虑的，有些人会在性能计算中忽略它们。

由上我们可知，连接池大小通常应该由CPU核数决定。更严格的来说，应该由系统可同时执行的任务数决定。可同时执行的任务数越多，则连接池应该越大。但是任务的耗时长短不一，占用资源也不尽相同。通常，我们会将应用分为CPU密集型和IO密集型两种进行讨论。

应用程序的最小线程数应该等于可用的处理器核数。如果所有的任务都是CPU密集型的，则创建处理器可用核心数那么多个线程就可以了。在这种情况下，创建更多的线程对程序性能而言反而是不利的。 因为当有多个仟务处于就绪状态时，处理器核心需要在线程间频繁进行上下文切换，而这种切换对程序性能损耗较大。但如果任务都是IO密集型的，那么我们就需要开更多的线程来提高性能。

当一个任务执行IO操作时，其线程将被阻塞，于是处理器可以立即进行上下文切换以便处理其他就绪线程。如果我们只有处理器可用核心数那么多个线程的话，则即使有待执行的任务也无法处理，因为我们已经拿不出更多的线程供处理器调度了。

如果任务有50%的时间处于阻塞状态，则程序所需线程数为处理器可用核心数的两倍。如果任务被阻塞的时间少于50%，即这些任务是计算密集型的，则程序所需线程数将随之减少，但最少也不应低于处理器的核心数。如果任务被阻塞的时间大于执行时间，即该任务是IO密集型的，我们就需要创建比处理器核心数大几倍数量的线程。我们可以计算出程序所需线程的总数，总结如下：

线程数 = CPU可用核心数/(1 - 阻塞系数），其中阻塞系数的取值在0和1之间。
计算密集型任务的阻塞系数为0，而IO密集型任务的阻塞系数则接近1。一个完全阻塞的任务是注定要挂掉的，所以我们无须担心阻塞系数会达到1。

为了更好地确定程序所需线程数，我们需要知道下面两个关键参数：

处理器可用核心数；
任务的阻塞系数；

CPU可用核心数很容易确定，但确定阻塞系数就稍微困难一些。一般而言，我们有公式：

阻塞系数 = W / (W + C)，即阻塞系数 = 阻塞时间 /（阻塞时间 + 计算时间）。

我们可以先试着猜测，抑或采用一些性能分析工具来确定线程花在系统IO操作上的时间与CPU计算所耗时间的比值。在《Programming Concurrency on the JVM Mastering》一书中，给出了估算线程池大小的公式：

线程数 = Ncpu /（1 - 阻塞系数）