一直以来对连接池与线程池的运作不清楚。
我参与的一个项目中存在一种情况，有一个业务在应用中存在并发的修改一张表的某个统计数据，那么如果程序或者其他事务原因，造成该数据出现行锁。
我的问题是：在容器(websphere)设置的连接超时时间前，是否 所有操作该业务的请求都将等待并占用一个数据库连接池的资源和一个线程，随着请求的不段增加，从而造成服务器宕机，数据库连接池的资源耗尽！
因为现成出现了服务器宕机，并且日志显示超时了：SRVE0133E: java.net.SocketTimeoutException: Async operation timed out
连接池和线程池是有本质区别的，当然也有相识的地方，打个比方吧：
连接池就好比一栋大楼所有电梯这样的一个集合；一台电梯好比连接池中一个连接。如果有人乘一台电梯上去，就不能为你服务，你只有选择其他空闲的电梯，或者你等待这个电梯服务完。连接池重要的是根据不同的应用要求配置参数可能完全不一样，比如，连接的超时时间，空闲回收时间，多久测试一次连接可用性（由于各种原因有时候连接空闲，但是无效，就好比电梯没有被其他人使用，你可以使用，但是没电），连接池中连接最大数，最小数等
线程池和连接池的配置大部分一样，因为原理很相似；但是又本质的区别：
连接池：
里面是数据库连接
线程池：
里面是线程
面向解决问题方向不一样：一个是减少数据库系统开销，提高数据库的实效，更多的为应用程序服务；另一个是，提高系统的处理能力和服务量。一个面向数据库连接资源，一个面向cpu资源
他们的的目的大致相同：提高系统的可靠性、充分利用资源
你的问题，两方面入手，一方面：数据库连接数稍微多一点，连接超时时长短一点；另一方面：线程数少一点，短事务，线程间适时让线程让出cpu（事务的前后，不要事务开启中间）。
如果想彻底解决，系统架构就要改变，不要操作公共资源
初步判断：
连接数用尽是因为资源竞争造成数据库锁，连接没有及时释放，所以连接数不断增长，直到用尽。
是的。操做系统的人发现系统反应慢，肯定会重复操作。锁表后，链接资源不释放，造成服务器负载上升。