java链接池的maxIdle该如何配置

问题现象

用60个线程并发访问某个读和写均有的业务接口，性能测试人员查看Oracle数据库负载CPU很是高，并且oracle的Logons指标达到148.1次/秒（这个值的含义是数据库客户端登陆认证的每秒的次数）。

并且查看应用程序中的线程栈，也发现了较多数量的线程处于建立新的oracle物理链接处。

这当时就让我有点儿糊涂了，咱们不是用了链接池吗？怎么还会常常建立物理链接呢？

问题分析解决

遇到这个问题，我当时也是从本身掌握的各类知识里去想可能的缘由，都想到了是否是由于tcp链接的超时时间是否是过短，仔细一想这些可能性都排除掉了。而后查看链接池的配置，当时咱们的同窗告诉我这些配置跟线上的是同样的，应该没有问题，我当时是就怀疑是maxIdle设置过小致使的缘由，可是没有什么具体的依据。

因此我就简单开发了一个页面能够实时查看当时应用链接池的active number（当前被使用的数据库链接数）和idle number（当前处于空闲状态的数据库链接数）。再次运行测试脚本，经过查看链接池的链接数就能够看出来，链接数的波动较大，有时候链接总数（上面两个数字相加）从20多忽然降到10，说明物理链接被销毁了，建立了新的物理链接，那这就与咱们看到的一些异常现象相吻合了，建立新的链接就会致使oracle数据库服务器的logons数量增长。因为链接的复用率较差，致使频繁的建立物理链接，oracle数据库的资源消耗增大。

网上找到一篇文章详细介绍dbcp链接池配置的，它关于maxIdle的配置说明是这么写的。

maxIdle值与maxActive值应配置的接近。 由于，当链接数超过maxIdle值后，刚刚使用完的链接（刚刚空闲下来）会当即被销毁。而不是我想要的空闲M秒后再销毁起一个缓冲做用。这一点DBCP作的可能与你想像的不同。 若maxIdle与maxActive相差较大，在高负载的系统中会致使频繁的建立、销毁链接，链接数在maxIdle与maxActive间快速频繁波动，这不是我想要的。 高负载系统的maxIdle值能够设置为与maxActive相同或设置为-1(-1表示不限制)，让链接数量在minIdle与maxIdle间缓冲慢速波动。

原文参考： http://elf8848.iteye.com/blog/1931778

看到这个我明白了由于咱们的配置是maxIdle配置的值是5，而maxActive配置的值为40，这样当并发较高的时候，当链接数接近maxActive值的状况下，空闲链接数很容易超过maxIdle，很快就被链接池给主动销毁了，这样就致使了链接频繁的建立，弱化了数据库链接池的做用。

此次的性能测试然让我深入的感觉到了数据库链接池对的价值，使用得当，它可以很好地复用已有的物理链接，在高并发的场景下，减小频繁的建立和销毁物理链接，下降系统的压力。用得很差，它的价值就发挥不出来，就像我们今天这个案例同样。

为何是这样的？

maxIdle的值为何要与maxActive的接近呢？果然如此吗？咱们还要经过源码来分析它背后的根本缘由。

看看上图是对dbcp链接池的获取和归还链接对象的流程图的描述，经过该图咱们就一目了然了。

详细的原理和源码分析请看这里：http://www.myexception.cn/apache/1874092.html

maxIdle配置总结

maxIdle值与maxActive值应配置的接近。

由于，当链接数超过maxIdle值后，刚刚使用完的链接（刚刚空闲下来）会当即被销毁。而不是我想要的空闲M秒后再销毁起一个缓冲做用。这一点DBCP作的可能与你想像的不同。

若maxIdle与maxActive相差较大，在高负载的系统中会致使频繁的建立、销毁链接，链接数在maxIdle与maxActive间快速频繁波动，这不是咱们想要的。

高负载系统的maxIdle值能够设置为与maxActive相同或设置为-1(-1表示不限制)，让链接数量在minIdle与maxIdle间缓冲慢速波动。多余的空闲链接等待回收线程来缓慢回收。

至于具体多少合理取决于你们的具体应用场景，可是配置的原则是这样的：

1.若是是链接池命中率（即应用在获取链接时直接得到已经建立物理链接的比率）优先的应用。适合链接资源较充裕的环境，能够尽量将maxIdle设置得更大一些，多数应用设置的大一些会更加安全。

2.若是是链接资源利用率（即被使用链接占的比率）优先的应用。适合那些链接资源紧张的环境。能够尽量将maxIdle设置得更小一些，这样空闲链接可以获得更快的释放，保持一个较小的链接，可是设置的太小的话会致使链接池命中率很是低，弱化链接池的做用。