1. 自从点击追踪系统是用redis连接池后，几乎没有出过什么问题了——即使在点击量增长到两千万每天的时候。
2. 然而奇怪的是，UI的后台和渠道的后台，最早就在用连接池，并且并发量很低，却动不动就redis连接报错，返回null对象。
之前实在是没想过代码是不是有问题。一直通过脚本重启项目。
3. 然后就有人抱怨你们这个系统有问题，要把redis改了！
4. 我简单和UI后台那边说了两句，点击追踪系统如此大的量都从未报错，UI使用频率够低了，为何频繁报错？你是不是有代码没有关闭连接池啊？
5. 人家检查了下项目后指出来有一个地方当时是没有关闭的。修改完线上版本后，我感觉必须确认是否还有别的地方了。
6. 于是想起了 grep 递归目录查找文件内容了。于是有了下面的方式：
[root@mc-arch-nginx-172-17-0-3@/home/arch/n_backend-v1/n_mc_project@12:39:36]
2009 $ grep -r "MCRedisInstance.getInstance" * > closejedis.txt
[root@mc-arch-nginx-172-17-0-3@/home/arch/n_backend-v1/n_mc_project@12:40:25]
2010 $ vi closejedis.txt
[root@mc-arch-nginx-172-17-0-3@/home/arch/n_backend-v1/n_mc_project@12:40:34]
2011 $ grep -r "jedis.close()" * > closejedis_close.txt
[root@mc-arch-nginx-172-17-0-3@/home/arch/n_backend-v1/n_mc_project@12:40:56]
2012 $ vimdiff closejedis.txt closejedis_close.txt
7. 同样，在/home/arch/mc_project_v7执行上述命令，
一目了然看到只有 closejedis.txt 里有下面的代码，却没有关闭连接池。
8. 最后发现两个项目里都是与报表相关的部分没有关闭连接池。报表又是使用频率最高的部分，难怪项目一直不稳定了！
9. 赶紧使用最新版项目修改问题，赶紧上线吧！
