资源池的两个小教训

"不要使用全局的资源池。除非你真的知道它的合理配置--如大小、超时等。"

我在这个坑里踩了两次了。

第一次是Http的连接池。我用了一个默认的PoolingHttpClientConnectionManager来进行REST服务调用。没想到，默认配置下的http连接池中，同一个域名最多只创建两个链接。结果压力稍微上来一点就瞬间悲剧了。

第二次是线程池。Spring的task:annotation-driven配置会将全局的@Async注解类/方法，以及定时任务都放到同一个线程/任务池中进行异步调用。结果，当其中某些任务阻塞住了工作线程时，系统中一大批多线程操作都超时了。

除了这两个坑外，我算是成功的躲开了一个坑。

使用Java 8的parallel stream来运行多线程任务时，默认情况下，所有线程由ForkJoinPool.commonPool()来调度、运行。与我第二次踩坑时的问题相似：如果有某些任务阻塞住了工作线程时，其它多线程任务会付出额外的等待时间，甚至超时。

这次我用了自定义的ForkJoinPool来躲开这个坑。并且我提醒自己：使用全局资源池时，一定要慎重。例如，全局的线程池、http/db连接池、缓存池等等。因为"全局"的覆盖面和影响面都太广，一个地方的无心之失，就可能导致千百处问题。这样的风险太大、太不可控了。

不过，数据库连接池算是一个特例。实际上，数据库连接池同样有上面这些风险，只不过大部分情况下，我们对数据库连接池机制研究以及大小、超时时间等方面的配置已经比较完善了，因此才很少出现影响应用服务的问题。另外，由于数据库操作实在是太频繁了，数据库连接池算是一个刚需，没它不行。

区分使用资源池，可以起到问题隔离的作用。不过，过多的资源池有时候也会造成资源浪费。虽然这种情形的概率会更小，但是一旦真的出现问题了，那么要定位和解决起来就不是那么容易的了。

我的经验是，区分一下各类操作的类型（CPU密集运算、数据库读写操作、网络IO、硬盘IO等），对不同类型操作使用不同资源池（如不同的线程池）；对同一类型的操作，可以再做细分（如内网IO、外网IO等），并以此为依据使用不同的资源池。

但总归，不要简单粗暴的使用全局统一的资源池。