就不该用全局对象，node优势在于密集io，拿内存做存储或缓存是不靠谱的。node的gc有很多坑，我建议把你的全局对象换成redis来做，不仅避开了node各种gc问题，而且可以扩展。你现在的连接池，拿一个全局对象来搞，node是单进程模型，扩展性为0啊。。。

分享一个我曾经踩的坑吧，我曾尝试过用node内存对象充当缓存，我知道这样干不靠谱，但百度的server要申请redis集群很麻烦，成本也不低，当时的业务场景让我尝试性地做了这件事，怕leak，所以经过反复压测，我确认我的缓存池没有内存泄露，十几个node实例分别维护着各自的缓存对象，这样持续了几个小时，观察内存监控我确认缓存池触底，gc正常，进程没崩。隔了一夜之后的中午，突然出现奇怪的现象，eventloop似乎变得很慢，node向后端数据库请求的超时判断受到了巨大影响，随之造成顶在前面的nginx由于upstream重连及多层nginx的放大效应，疯狂地请求node，最终结果是node进程打爆，软件上的重启无效。。。联系op。。。硬重启。。。此后不再尝试类似的缓存，老老实实redis或memcache。。。

这个问题我研究了一段时间v8源码，没找到直接证据能够证明v8的高强度gc会直接影响eventloop，但gc造成进程假死的说法确实存在。我目前的怀疑依然是v8的gc产生了副作用致使eventloop变慢。如果有了解这方面的朋友欢迎讨论。