之前我认为数据库连接池尽量设置的大些，越大数据库的性能越高，吞吐量越高。
现在来看是错误的。
先看一个连接池越大反而性能越低的例子：
Oracle性能小组发布的连接池大小性能测试，假设并发量为1万。模拟了9600个并发线程来操作数据库，没两次数据库操作之间sleep 550ms，测试用例及结果为：
1）：连接池数为2048，结果每个请求要在连接池队列中等待33ms，获得连接之后，执行SQL耗时77ms，CPU消耗在95%左右。
2）：连接池数为1024，结果每个请求要在连接池队列中等待38ms，获得连接之后，执行SQL耗时30ms，耗时减少很多。
两次比较结果为吞吐量基本没变，但是连接池数减半之后wait事件也减少了一半。
3）：连接池数为96，结果每个请求在连接池队列中平均等待时间为1ms，SQL执行耗时为2ms。吞吐量大大提高。
这是因为一核的CPU同一时刻只能执行一个线程，多个线程并发执行的话操作系统为每个线程分配时间片，然后快速切换时间片，执行其他线程，不停反复，给我们造成所有线程同时运行的假象。
因此单核CPU顺序执行AB两个线程永远比并发切换时间片执行AB要快！
一旦线程的数量超过了 CPU 核心的数量，再增加线程数系统就只会更慢，而不是更快，因为这里涉及到上下文切换耗费的额外的性能。