背景：原来的项目，使用了hibernate+c3p0操作MySQL数据库，由于业务扩大，要迁移到MyBatis，为了提高性能，顺便更换了HikariCP连接池。由此引发了一桩旷日N天的血案~~
以下内容需要耐心 :)
项目里面有很多定时任务，定时任务里要扫描表，对数据进行判断和处理，于是自己写了个线程进行处理，因为任务处理类(继承Runnable)可能会是实时创建的，就没有使用Spring注入的方式使用，问题来了，没有Spring注入（其实通过Bean也可以动态创建，是后来才知道的，当时学艺不精，就自己实例化了），线程如何拿到访问数据库的Service？后来发现可以通过SpringBeanUtils.getBean()得到Service的对象，拿到了，就能使用。
但是运行后遇到个问题，启动后就报下面这个错误
org.hibernate.HibernateException: Could not obtain transaction-synchronized Session for current thread
由此开始了漫长的爬网，可是所有的解决方案都无效，大部分人遇到的问题，都不是我们遇到的这个场景。后来想想，transaction不就是事务问题吗？一咬牙，上大招，跟源码！
经过追踪c3p0的源码，无意间发现了一个非常令人振奋的代码：
try {
if (!TransactionSynchronizationManager.isSynchronizationActive())
TransactionSynchronizationManager.initSynchronization();
} catch (Exception ex) {
//nothing to do
}对于c3p0线程池来说，如果想要某个线程调用的Service方法，能够被事务管理， 必须要在这个线程的开始，执行 TransactionSynchronizationManager.initSynchronization();以便开启事务处理机制，这样，在任何线程中，执行从getBean()获取的Service，都能正常被事务管理了。
至此，总算解决了问题，一切运行良好，非常开心！！！
-------------------------------------------~我是分割线~--------------------------------------
然后，更换HikariCP连接池。
但是实际运行后，却出现了奇怪的问题，开始一切正常。
定时服务每天早上8：00执行，8：00之后，就会发现大量的如下异常：
uncategorized SQLException for SQL []; SQL state [null]; error code [0]; Connection is closed; nested exception is java.sql.SQLException: Connection is closed
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:84)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81)
at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:73)
at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:446)
....
这是什么鬼，瞬间就头大了！！！
从来没有主动使用过连接和连接池！都是直接调Service！！！ 连接池不都是底层代理自己管理的吗？！如果连接关闭了，连接池应该会自动重新连接的吧！怎么会一直报Connection is closed。难道HikariCP有BUG？这个不太可能，使用如此广泛的连接池，不可能有这么严重的BUG。或者配置参数不对？
连续捣鼓了好几天，各自尝试发现，配置正常，数据库正常，网络正常。事态逐渐焦灼了。老板都开始催了，，，
后来发现，奇怪的是：网页请求正常，通过网页请求进行读写数据都正常。
那么一定是定时服务线程有鬼！（仔细的看官我想大概已经知道问题出在哪里了）
于是又开始了漫长的爬网，无果，再次开始痛苦的源码跟踪过程。跟着跟着，在HikariCP里，发现了个熟悉的身影
TransactionSynchronizationManager.isSynchronizationActive() { --- 你怎么就那么亮！}
经过仔细的分析发现，HikariCP在发现上面的调用返回true以后，就认为当前线程已经开启了事务了（而不是理解为初始化了此线程允许事务的标记），从而再开启的事务，都是子事务了！。如果返回false，他就开一个新的顶级事务。
竟然还有这种操作！！！ 同样的函数，使用的场景完全不同了！！！
在C3P0里面，
TransactionSynchronizationManager.isSynchronizationActive()
这个表示：检查此线程，是否支持事务处理。
而在HikariCP里面，表示：这个线程，是否已经开启了一个事务。
坑啊，坑爹啊，真TM坑爹啊！
到此，问题终于清楚了：因为我在线程的开始调用了 TransactionSynchronizationManager.initSynchronization()，（之后死循环处理业务，直到系统退出），导致HikariCP以为我是自己管理了一个顶级的事务，所以可以想象，因为我的线程是永久运行的线程，只有程序结束后，才会执行事务的结束操作。因此HikariCP就永远不会释放这个连接，永远不会提交这个事务。
但是，虽然这样，怎么会发生连接关闭的问题的呢？
这里还有个环境因素很重要，mysql有个wait_timeout配置默认8个小时，就是说8个小时后，发现这个连接没有在忙，就会断开这个连接。因为当前线程的这个永不结束的事务，导致了事务关联的连接不会被连接池收回，最终造成这个连接永远不会进行重连，永远是假连接，于是大量报错。
问题清楚了，解决方法也就很明确了，去掉TransactionSynchronizationManager.initSynchronization()的调用就OK。