池化技术：如何减少频繁创建数据库连接的性能损耗？

假设公司的领导，把我们叫到会议室，告诉我们公司有一个新的商业机会，希望我们可以迅速研发出一套面向某个垂直领域的电商系统。

在人手紧张，时间不足的情况下，为了能够完成任务，我们毫不犹豫地采用了最简单的架构：前端一台 Web 服务器运行业务代码，后端一台数据库服务器存储业务数据。

这个架构图是我们每个人最熟悉的，最简单的架构原型，很多系统在一开始都是长这样的，只是随着业务复杂度的提高，架构做了叠加，然后看起来就越来越复杂了。

再说回我们的垂直电商系统，系统一开始上线之后，虽然用户量不大，但运行平稳，我们很有成就感，不过领导觉得用户量太少了，所以紧急调动运营同学做了一次全网的流量推广。

这一推广很快带来了一大波流量，但这时，系统的访问速度开始变慢。

分析程序的日志之后，我们发现系统慢的原因出现在和数据库的交互上。因为我们数据库的调用方式是先获取数据库的连接，然后依靠这条连接从数据库中查询数据，最后关闭连接释放数据库资源。这种调用方式下，每次执行 SQL 都需要重新建立连接，所以我们怀疑，是不是频繁地建立数据库连接耗费时间长导致了访问慢的问题。

通过 “tcpdump -i eth0 -nn -tttt port 3306” 命令抓取了MySQL建立连接的网络包来做分析，从抓包结果来看，整个MySQL的连接过程可以分为两部分：

• 第一部分是前三个数据包。第一个数据包是客户端向服务端发送的一个“SYN”包，第二个包是服务端回给客户端的“ACK”包以及一个“SYN”包，第三个包是客户端回给服务端 的“ACK”包，熟悉 TCP 协议的同学可以看出这是一个 TCP 的三次握手过程。
• 第二部分是 MySQL 服务端校验客户端密码的过程。其中第一个包是服务端发给客户端要 求认证的报文，第二和第三个包是客户端将加密后的密码发送给服务端的包，最后两个包是 服务端回给客户端认证 OK 的报文。
  
  那么单条 SQL 执行时间是多少呢？我们统计了一段时间的 SQL 执行时间，发现 SQL 的平均执行时间大概是 1ms，也就是说相比于 SQL 的执行，MySQL 建立连接的过程是比较耗 时的。这在请求量小的时候其实影响不大，因为无论是建立连接还是执行 SQL，耗时都是毫秒级别的。可是请求量上来之后，如果按照原来的方式建立一次连接只执行一条 SQL 的话，1s 只能执行 200 次数据库的查询，而数据库建立连接的时间占了其中 4/5。

那这时你要怎么做呢？一番谷歌搜索之后，我们发现解决方案也很简单，只要使用连接池将数据库连接预先建立好， 这样在使用的时候就不需要频繁地创建连接了。调整之后，发现 1s 就可以执行 1000 次 的数据库查询，查询性能大大的提升了。

用连接池预先建立数据库连接

其实，在开发过程中我们会用到很多的连接池，像是数据库连接池、HTTP 连接池、Redis 连接池等等。而连接池的管理是连接池设计的核心，就以数据库连接池为例，来说明一下连接池管理的关键点。

数据库连接池有两个最重要的配置：最小连接数和最大连接数，它们控制着从连接池中获取连接的流程：

• 如果当前连接数小于最小连接数，则创建新的连接处理数据库请求；
• 如果连接池中有空闲连接则复用空闲连接；
• 如果空闲池中没有连接并且当前连接数小于最大连接数，则创建新的连接处理请求；
• 如果当前连接数已经大于等于最大连接数，则按照配置中设定的时间（C3P0 的连接池配置是 checkoutTimeout）等待旧的连接可用；
• 如果等待超过了这个设定时间则向用户抛出错误；

对于数据库连接池，一般在线上建议最小连接数控制在 10 左右，最大连接数控制在 20~30 左右即可。

在这里，你需要注意池子中连接的维护问题。一般情况下，产生故障的原因可能有以下几种：

1. 数据库的域名对应的 IP 发生了变更，池子的连接还是使用旧的 IP，当旧的 IP 下的数据库服务关闭后，再使用这个连接查询就会发生错误；
2. MySQL 有个参数是“wait_timeout”，控制着当数据库连接闲置多长时间后，数据库会主动的关闭这条连接。这个机制对于数据库使用方是无感知的，所以当我们使用这个被关闭 的连接时就会发生错误。

那么，怎么保证启动的数据库连接池一定是可用的呢？

1. 启动一个线程来定期检测连接池中的连接是否可用，比如使用连接发送“select 1”的命令给数据库看是否会抛出异常，如果抛出异常则将这个连接从连接池中移除，并且尝试关闭。目前 C3P0 连接池可以采用这种方式来检测连接是否可用，也是比较推荐的方式。
2. 在获取到连接之后，先校验连接是否可用，如果可用才会执行 SQL 语句。比如 DBCP 连接池的 testOnBorrow 配置项，就是控制是否开启这个验证。这种方式在获取连接时会引入多余的开销，在线上系统中还是尽量不要开启，在测试服务上可以使用。

用线程池预先创建线程

在JDK 1.5 中引入的 ThreadPoolExecutor 就是一种线程池的实现，它有两个重要的参数：coreThreadCount 和 maxThreadCount，这两个参数控制着线程池的执行过程。

• 如果线程池中的线程数少于 coreThreadCount 时，处理新的任务时会创建新的线程；
• 如果线程数大于 coreThreadCount 则把任务丢到一个队列里面，由当前空闲的线程执行；
• 当队列中的任务堆积满了的时候，则继续创建线程，直到达到 maxThreadCount；
• 当线程数达到 maxTheadCount 时还有新的任务提交，那么我们就不得不将它们丢弃了；

这个任务处理流程看似简单，实际上有很多坑，你在使用的时候一定要注意。

首先， JDK 实现的这个线程池优先把任务放入队列暂存起来，而不是创建更多的线程，它比较适用于执行 CPU 密集型的任务，也就是需要执行大量 CPU 运算的任务。这是为什么呢？因为执行 CPU 密集型的任务时 CPU 比较繁忙，因此只需要创建和 CPU 核数相当的线程就好了，多了反而会造成线程上下文切换，降低任务执行效率。所以当当前线程数超过核 心线程数时，线程池不会增加线程，而是放在队列里等待核心线程空闲下来。

但是，我们平时开发的 Web 系统通常都有大量的 IO 操作，例如说查询数据库、查询缓存等等。任务在执行 IO 操作的时候 CPU 就空闲了下来，这时如果增加执行任务的线程数而不是把任务暂存在队列中，就可以在单位时间内执行更多的任务，大大提高了任务执行的吞吐量。所以你看 Tomcat 使用的线程池就不是 JDK 原生的线程池，而是做了一些改造，当线程数超过 coreThreadCount 之后会优先创建线程，直到线程数到达 maxThreadCount，这样就比较适合于 Web 系统大量 IO 操作的场景了，你在实际运用过程中也可以参考借鉴。

其次，线程池中使用的队列的堆积量也是我们需要监控的重要指标，对于实时性要求比较高的任务来说，这个指标尤为关键。

最后，如果你使用线程池请一定记住不要使用无界队列（即没有设置固定大小的队列）。也许你会觉得使用了无界队列后，任务就永远不会被丢弃，只要任务对实时性要求不高，反正早晚有消费完的一天。但是，大量的任务堆积会占用大量的内存空间，一旦内存空间被占满 就会频繁地触发 Full GC，造成服务不可用。

这是一种常见的软件设计思想，叫做池化技术，它的核心思想是空间换时间，期望使用预先创建好的对象来减少频繁创建对象的性能开销，同时还可以对对象进行统一的管理，降低了对象的使用的成本，总之是好处多多。

不过，池化技术也存在一些缺陷，例如说存储池子中的对象肯定需要消耗多余的内存，如果对象没有被频繁使用，就会造成内存上的浪费。再比方说，池子中的对象需要在系统启动的时候就预先创建完成，这在一定程度上增加了系统启动时间。

可这些缺陷相比池化技术的优势来说就比较微不足道了，只要我们确认要使用的对象在创建时确实比较耗时或者消耗资源，并且这些对象也确实会被频繁地创建和销毁，我们就可以使用池化技术来优化。

总结

其实，连接池和线程池我们并不陌生，不过可能对它们的原理和使用方式上还存在困惑或者误区。池化技术强调的重点是：

• 池子的最大值和最小值的设置很重要，初期可以依据经验来设置，后面还是需要根据实际运行情况做调整。
• 池子中的对象需要在使用之前预先初始化完成，这叫做池子的预热，比方说使用线程池时就需要预先初始化所有的核心线程。如果池子未经过预热可能会导致系统重启后产生比较多的慢请求。
• 池化技术核心是一种空间换时间优化方法的实践，所以要关注空间占用情况，避免出现空间过度使用出现内存泄露或者频繁垃圾回收等问题。

现在我们用池化技术解决了数据库连接复用的问题，这时，我们的垂直电商系统虽然整体架构上没有变化，但是和数据库交互的过程有了变化，在我们的 Web 工程和数据库之间增加了数据库连接池，减少了频繁创建连接的成本。现在的架构图如下所示：