TransactionalEventListener 是一个复合注解，从Spring4.2+开始支持
image.png
我们通过源码看到，他继承了EventListener注解的功能，他与EventListener不同的是，他可以支持在事务提交之后再去执行对应的事件。
正好我们项目就有一处需求需要在事务提交后统一去处理一些事情，就采用了TransactionalEventListener方式去实现。直到有一天测试压测的时候，竟然死锁了，通过分析，最后得知， 真凶竟然就是在这里面。
经过一段debug源码，最后得出一个结论：
TransactionalEventListener可以保证事件触发的时候事务已经提交，但数据库连接并没有被释放，因此也没有被连接池回收。并且由于Spring的机制，在这个事件处理代码块里面，如果需要使用连接，会继续复用之前事务内的数据库连接Connection。
这就会带来以下几个问题：
1、如果对应的事件处理器里面并不需要获取数据库连接，并且对应的代码块中一旦阻塞，在高并发下，会造成连接池瞬间打满，造成系统宕机。即使没有打满，也没有及时释放出资源，在连接有限的情况下，会对系统健壮性有一定影响。
（注：作者就因为在处理器中使用了一个队列，然而队列满了一直处于等待状态，可是不幸这些等待连接的线程均占用了数据库连接，引发了死锁）
2、如果在对应的事件处理器里面需要切换数据源的话，由于事务内Spring会共用同一个数据源连接，同理，在这里面也会用同一个数据源连接，不会去重新获取连接，造成数据源切换失败！
于是本人对事件处理器代码进行改造，为了及时去释放数据库连接，决定采取异步去执行对应的处理方法，这样就能保证连接及时释放掉。而且由于是一个新的线程，数据源切换也就迎刃而解了。
网友评论