记录一个跌宕起伏的解决bug过程

问题症状：测试发现在服务在运行一段时间之后就会挂掉，尤其是在进行安全漏洞扫描和性能测试时更加明显，后台没有报错日志，单纯的应用不再接收新的请求；

问题重现、分析和解决：刚开始很难在开发环境上复现这个问题（我们自己开发环境经常会重启），而且无法定位到在进行什么操作的时候才会导致服务器挂掉；只能通过多次进行扫描然后查看导致服务挂掉的请求时什么，发现每次扫描卡住之后最后一个请求都是登录请求，所以我们初步判断可能是登录导致应用挂掉，但是让人疑惑的是为什么正常操作时应用没有挂掉，而是操作一段时间之后应用才会挂掉，然后网上一顿搜索分析，发现服务不再响应的特征是数据库的连接数达到一定的数量而且这些连接由于被阻塞不能释放，导致数据库卡死；到这基本是找到了导致服务挂掉的罪魁祸首了，但是怎么解决这个问题呢，是那一块的代码导致了这个问题呢？然后我首先将可能导致数据库发生阻塞的代码重新走了一遍，甚至将很多不规范的写法都重新规范了一遍，还是不行，然后我又回想起每次挂掉前的最后一个扫描请求时登录，所以我又回到登录页面去查（因为我们登录时做的单点登录，在跳转到另一个系统进行登录的）一遍遍的修改调试都无果，而这时通过大量在开发环境的测试（我们在开发环境将最大连接数设置小一些，问题也更容易复现）我们发现不止是进行一定量的登录请求后会发生这个问题，不停的刷新首页也会导致这个问题，然后我们排除了登录的问题，而扫描漏洞导致服务挂掉前的最后一个请求每次都是登录请求也可以理解，因为我们某些页面有登录拦截，然后扫描漏洞的程序在每隔一定的时间就会进行登录操作，而一旦发现登录不上去了，程序就停止扫描了，而服务也许在这之前就已经挂掉了；言归正传，这时我们把问题锁定到首页上，因为不断f5刷新首页，确实可以看到后台数据库的阻塞进程在增加，然后就是分析首页的代码，一段一段的屏蔽排除发现是页面上的的图片加载会导致这个问题，这让我们又疑惑了，但是随着继续深入的测试，点击一个加载失败的图片链接让我们有了新的发现，这个加载失败的图片跳转到的一个404页面里面包含了获取后台用户数据的操作，继续前面的排除法，删除这部分代码就不会出现问题了，到这里我们至少知道该怎么去解决项目上的问题了，但是这并没有解决疑惑，为什么在404页面获取用户信息会导致这个问题，继续深入研究发现是数据库配置的问题，发现是在openSessionInViewFilter的拦截没有配置Error这个选项，导致在error页打开的session没有正常关闭，加上这个不修改error的tag页也可以解决问题！