资源池的两个小教训
“不要使用全局的资源池。除非你真的知道它的合理配置——如大小、超时等。”
创新互联长期为成百上千客户提供的网站建设服务,团队从业经验10年,关注不同地域、不同群体,并针对不同对象提供差异化的产品和服务;打造开放共赢平台,与合作伙伴共同营造健康的互联网生态环境。为清水河企业提供专业的成都网站建设、成都网站制作,清水河网站改版等技术服务。拥有10余年丰富建站经验和众多成功案例,为您定制开发。
我在这个坑里踩了两次了。
第一次是Http的连接池。我用了一个默认的PoolingHttpClientConnectionManager来进行REST服务调用。没想到,默认配置下的http连接池中,同一个域名最多只创建两个链接。结果压力稍微上来一点就瞬间悲剧了。
第二次是线程池。Spring的task:annotation-driven配置会将全局的@Async注解类/方法,以及定时任务都放到同一个线程/任务池中进行异步调用。结果,当其中某些任务阻塞住了工作线程时,系统中一大批多线程操作都超时了。
除了这两个坑外,我算是成功的躲开了一个坑。
使用Java 8的parallel stream来运行多线程任务时,默认情况下,所有线程由ForkJoinPool.commonPool()来调度、运行。与我第二次踩坑时的问题相似:如果有某些任务阻塞住了工作线程时,其它多线程任务会付出额外的等待时间,甚至超时。
这次我用了自定义的ForkJoinPool来躲开这个坑。并且我提醒自己:使用全局资源池时,一定要慎重。例如,全局的线程池、http/db连接池、缓存池等等。因为“全局”的覆盖面和影响面都太广,一个地方的无心之失,就可能导致千百处问题。这样的风险太大、太不可控了。
不过,数据库连接池算是一个特例。实际上,数据库连接池同样有上面这些风险,只不过大部分情况下,我们对数据库连接池机制研究以及大小、超时时间等方面的配置已经比较完善了,因此才很少出现影响应用服务的问题。另外,由于数据库操作实在是太频繁了,数据库连接池算是一个刚需,没它不行。
区分使用资源池,可以起到问题隔离的作用。不过,过多的资源池有时候也会造成资源浪费。虽然这种情形的概率会更小,但是一旦真的出现问题了,那么要定位和解决起来就不是那么容易的了。
我的经验是,区分一下各类操作的类型(CPU密集运算、数据库读写操作、网络IO、硬盘IO等),对不同类型操作使用不同资源池(如不同的线程池);对同一类型的操作,可以再做细分(如内网IO、外网IO等),并以此为依据使用不同的资源池。
但总归,不要简单粗暴的使用全局统一的资源池。
本文题目:资源池的两个小教训
分享链接:http://azwzsj.com/article/jgjgcj.html