连接池场景：
解决连接重用的方案分析
我们想象火车站售票大厅的情况，平时客流比较少时，我们只开几个售票窗口，不管有没有顾客来买票:多时间处于空闲状态。在如节假日等高峰期，所有售票窗口都会启用。特别地，在春运这样的最高峰期，可能会有临时窗口。但临时窗口也不是无限制地多开，开窗口要耗费物力人力。这样在高峰期只能让客户等待长一点的时间。春运最高峰时排队，这个时间客户就需要等待。
我们在重用数据库连接时也可以采用类似的方案。我们先打开一批连接等待客户使用(如同非高峰期我们开几个窗口) ,不管用没有客户使用。在高峰期到来时，我们可以多开几个连接让浏览器客户使用。如同春运一样不可能为了让每个人都有一个窗口服务，我们的数据库连接也不能无限开启(数据库连接要占用内存等资源，同时每个数据库能支持的并发连接数也不是无限的).在不能为需要的数据的客户立马服务时,只能让客户排队等待。如果用户一直无法得到一个连接对象时，就不要让用户无限期等待。
从上面可以看出，我们重用连接的方案，需要提供以下信息:
预先开启的连接数
能开启的最大连接数
一个连接要被多个客户使用，因而连接用完不能关闭
一个超时时间，如果超过这个时间，用户就无法获取连接而得到数据。
在JDBC连接数据库的连接重用方案里，我们称为连接池。
连接池中可以重用的包括Connection对象和Statement对象
2. c3p0，dbcp与druid 三大连接池的区别
https://blog.csdn.net/qq_34359363/article/details/72763491
3 问题
去年就想把我们电商平台的连接池由C3P0换成Druid连接池，原因如下：
初期在架构平台之处，用的连接池是DBCP，用了一段时间DBCP以后，发现DBCP有时候会自动断掉。必须重启才能有效。而且开发人员一多连接数据库开发的人也就多了，会造成DBCP连接数据库连不上，只能少部分人连接，人一多，就自动连不上，具体原因也没有去研究，就换成C3P0连接池。C3P0总体来说，运行稳定性还是可以，就是偶尔会断开，不过不需要重新连接，它自动就连上去了。所以影响也不是很大，也没有换连接池的想法。在今年年初就出问题了，在监控平台的日志过程中，发现C3P0有时候会连接超时，但是在下一次就又能连上了，而且也没有出现大问题（大问题是指平台的交易问题）。故觉得C3P0也存在漏洞。于是查看了下网站，也有很多人遇到同样的问题。但是都没有说具体解决方法。看了淘宝技术网站，发现他们开源了很多很好用也经过实际性能测试的框架开源，再对比了Druid和C3P0的性能，发现Druid比C3P0的性能要优越很多，具体可以查看Druid的官方地址，其中有一项各个连接池的对比数据。