Druid连接池源码解析（2）DruidDataSource-2

关闭时调用close()方法，主要流程：

在DruidDataSource中单独定义了一个StackTrace，就是在初始化的时候获取了当前线程的StackTrace，目测目的是为了自定义输出调试信息

重启时调用restart()方法，主要流程：
加锁->判断活跃连结数是否为0-> 调用close() ->调用resetStat()
resetStat()重置配置到默认值，设置各个原子计数器为0

如果有配置变动，调用configFromPropety()重新配置各属性
此时重启便结束了，下一次调用getConnection()的时候，会调用init()重新初始化

关于几个原子计数器，由于Druid说是为监控而生的连接池，默认是基于内存计数的，所以restart里清空的几个计数器，根据名字就能比较明显地知道是统计各种情况发生的次数的，如：链接错误数，事务提交、回滚数等等
那么之前init中的几个计数器，是做什么的么？
connectionIdSeedUpdater 追了下，主要是生成连接id的，对应到holder中的connectionId，
在DataSource中的getPoolingConnectionInfo()，放到了一个map里，缓存了连接信息
在DruidStatManagerFacade和DruidStatService 中获取了map中的连接信息，供监控控制台使用
dataSource的id本身是自增的，留出来的步长是生成connectionid等根据id的前缀判断属于哪个datasource

使用AtomicLongFieldUpdater的好处是：
因为当需要进行原子限定的属性所属的类会被创建大量的实例对象,如果用AtomicLong每个实例里面都要创建AtomicLong对象,从而多出内存消耗，使用AtomicLongFieldUpdater仅需要在抽象的父类中声明一个静态的更新器，就可以在各个对象中使用了。

以上就是关于Druid连接池源码解析（2）DruidDataSource-2全部的内容，包括:Druid连接池源码解析（2）DruidDataSource-2、、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！