使用数据库连接池connection.close()不是真正关闭的疑问

最新推荐文章于 2021-02-13 05:56:32 发布

myminer

最新推荐文章于 2021-02-13 05:56:32 发布

阅读量5.9k

点赞数

分类专栏： java 文章标签：多线程 Spring Hibernate JDBC SQL

java 专栏收录该内容

10 篇文章

订阅专栏

本文探讨了数据库连接池的工作原理及其与事务管理的关系。提出了关于连接池中connection的使用和回收机制的问题，并讨论了在多线程环境下，如Spring和Hibernate框架中使用ThreadLocal进行事务控制时可能遇到的问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

引发几个疑问啊。
问题1:
使用数据库连接池得到的connection是不用程序关闭，连接池自己会把一定时间内没有使用的connection拿回到池里。----然后，我不知道这句话对不对。如果对，那么在spring中，hibernate中，很多都用了ThreadLocal来控制多线程中的事务，这样不会就有问题了吗？---连接池把con分给这个线程使用，放在ThreadLocal中，而一回收后又交给其他线程使用，放在ThreadLocal中，要是这些线程同时要做事务，同一个connection那还如何事务？

问题2:
人家都说调用connection的close()方法没关系，不会被关，怎么不会被关啊？
sun api文档方法说明：
[quote]void close()
Releases this Connection object's database and JDBC resources immediately instead of waiting for them to be automatically released. [/quote]
如果我没理解错，调用此方法是主动去释放这个连接的资源，以代替数据库或者jdbc自动释放，不就是关闭吗？
除非是从数据库连接池里get到的connection是经过包装的。
比如

class MyConnection extends java.sql.Connection
{
@override
 public void close()
 {
   //回收到连接池里
 }
}

而连接池的代码，得到connection实际是它的子类MyConnection

class ConnectionPool ..
{
 ...
 public Conncetion getConnection()
 {
   return new MyConnection(...);
  }
 ...
}

硬是把close方法重写了，这样调用close时就不会被真正关闭。
我懒人一个，没去看开源的数据库连接池代码。不知以上的观点对不对，或者还有其他机制，或者我想得根本不对！
有人知道其真正原理吗？能讨论下原理吗？