● jdbc资源的回收问题[转载]发信人: petbear (雨中的人), 信区: J2EE
标 题: jdbc资源的回收问题[转载]
发信站: BBS 水木清华站 (Sun May 9 11:33:20 2004), 站内
我们使用连接池访问数据库，是不是在关闭了connection之后它所属的statement和resul
t都会自动关闭了呢？就是说只需要关闭connection？
那么这样的话是不是只要在try{...}catch{...}finnally{conn.close();}这样的框架下工
作就肯定是不会存在连接资源占用的情况了呢？
经过我在DB2上测试的情况是这样的，不知道是不是不同的jdk或者as环境下会有所不同？
我一直无法完全肯定这一问题，请大家赐教！
本来我只要养成在关闭connection之前把其他对象一一关闭的习惯，就不会存在这个问题
了，但是我为了偷懒起见，把简单的查询和更新操作封装到了一个基类的公用函数中，方
便随时在代码中调用，代码如下：
public static ResultSet sysSelect(Connection conn,String sql)throws SQLExcepti
on{
Statement st = null;
st = conn.createStatement();
return st.executeQuery(sql);
}
由于这样的功能随时随地会被使用，这不得不使我考虑这个函数中产生中间对象statemen
t st的生存期问题！*_*
Re: jdbc资源的回收问题！ 发表时间: 2004年04月15日 10:47:19 回复
发表人: FgtPWD 发表文章: 6 / 注册时间: 2004-04
帮你顶，我也想知道清楚
Re: jdbc资源的回收问题！ 发表时间: 2004年04月15日 14:56:56 回复
发表人: oldma 发表文章: 86 / 注册时间: 2003-09
是，最起码数据库端资源是得到了释放
不过这也不绝对，因为statement，result对应的是curior，而有些
DB的curior是share的，
总之，关了connection就可以了
Re: jdbc资源的回收问题！ 发表时间: 2004年04月16日 17:05:07 回复
发表人: mysapphire 发表文章: 17 / 注册时间: 2003-12
你是说：在有的时候就算是释放了connection也可能有部分的Statement和ResultSet还占
用着数据库资源？
如果是这样的话，那么在这个时候java和数据库的连接虽然断开了，可由于没有在连接的
时候预先释放这些Statement和ResultSret资源（在数据库方应该理解为游标或者其他资源
），会影响数据库的性能的吧？这似乎无以从程序上来证实！
Re: jdbc资源的回收问题！ 发表时间: 2004年04月18日 20:41:05 回复
发表人: oldma 发表文章: 86 / 注册时间: 2003-09
> 你是说：在有的时候就算是释放了connection也可能有部分的
> tatement和ResultSet还占用着数据库资源？
不会，本地的statement和ResultSet会被回收，但数据库端的资源不一定会释放，但你不
必担心此事，应为这不是一件坏事，就像你用的数据库连接池，数据库也可以对curior做
cache，毕竟频繁创建curior对DB来说是比较expansive的.
当然，前提是数据库share_curior参数的设置不是0
Re: jdbc资源的回收问题！ 发表时间: 2004年04月16日 17:16:17 回复
发表人: seaman0916 发表文章: 19 / 注册时间: 2004-02
关注,我对这个问题也一直搞不清楚!
Re: jdbc资源的回收问题！ 发表时间: 2004年04月19日 12:51:46 回复
发表人: TiGEr.zZ 发表文章: 7 / 注册时间: 2004-04
本地对象如果不被使用的确可以释放，但tcp连接什么时候释放是个问题，还有tcp连接和
connection对应还是和resultset对应，这个似乎是未知的，不过看起来java里似乎是和c
onnection对应的，否则只需要全局维护一个长连接connection对象就可以了，只考虑生成
（是否可用）的问题而不用考虑关闭的问题(除非出于性能目的，可以考虑多连接加锁的实
现，也无需用户去关闭）,ado里面好像可以这么做。如果tcp连接过多，一定会把数据库拖
垮的。
至于conn, rs, st之间的依赖关系似乎也不明确，所以我在这个时候是自己写一个result
set接口的实现，然后重载close方法，去一一关闭其依赖对象，甚至你可以在final函数里
面关闭，不过后者看起来没什么大用。
Re: jdbc资源的回收问题！ 发表时间: 2004年04月19日 13:37:52 回复
发表人: navyzhu 发表文章: 7 / 注册时间: 2003-03
Statement也要Close,本人在使用中发现，若单单调用Connection.Close，实际上Connect
ion并不会立即Close,可能要等到垃圾回收Statement后Connection才会Close, 本人使用的
数据库是SQLServer.
Re: jdbc资源的回收问题！ 发表时间: 2004年04月19日 14:48:17 回复
发表人: jellyprince 发表文章: 11 / 注册时间: 2004-04
我曾试过将Connection对象作为一个static属性放在一个类DBConnection中，然后，建立
一个连接后，其它所有要用连接的地方就调用
DBConnection.connection,
最后再关掉，本以为这是一高招，但结果却是不可行。connection被用一次后，调用DBCo
nnection.connection时就不行了。
但我认为思路应该是对的，不知是否还有同志尝试过
至于statement,要关掉并不难，可以在一个要连某个数据库的类中将其可connection一同
声明为static,这样在任何地方用完后，就可以很方便的关掉了
Re: jdbc资源的回收问题！ 发表时间: 2004年04月19日 14:53:33 回复
发表人: rtm 发表文章: 13 / 注册时间: 2002-11
全部都要关闭，关闭connection后statement和result还是可以用的，可以在关闭connect
ion后，再试试遍历result还是可以得到数据的，result不关闭会导致游标超出范围等错误
Re: jdbc资源的回收问题！ 发表时间: 2004年04月19日 15:13:02 回复
发表人: mysapphire 发表文章: 17 / 注册时间: 2003-12
请问navyzhu和rtm： 你们是在什么数据库上测试得到的这个结果的？
我在DB2和ORACLE8.1.2上测试出来的结果都很明显地提示：SQLException:关闭的连接...
.（所有的conn,st,rs使用的时候是默认方式）
Re: jdbc资源的回收问题！ 发表时间: 2004年04月19日 15:22:43 回复
发表人: huzhigang 发表文章: 23 / 注册时间: 2003-12
Connection一旦关闭，所有由它打开的ResultSet不在可用。这在jdk文档中有说明。否则
，没有必要定义javax.sql.RowSet了。
Re: jdbc资源的回收问题！ 发表时间: 2004年04月20日 10:50:17 回复
发表人: shardy 发表文章: 4 / 注册时间: 2003-04
Statement,ResultSet肯定都是关闭了得，但是资源还没有释放阿。如果从性能方面考虑的
话，一定的明显的关闭Statement,ResultSet，还有两点需要注意：
1，不要隐式产生Statement,ResultSet对象
2，关闭对象一定要在finally中关闭
Re: jdbc资源的回收问题！ 发表时间: 2004年04月19日 15:21:25 回复
发表人: TiGEr.zZ 发表文章: 7 / 注册时间: 2004-04
这么看来odbc/jdbc的设计现在也不太适宜了，为什么有conn, st的存在是因为希望可以复
用，减少开销，但增加了程序员的负担，可能不多的几行代码，建立对象和关闭对象占了
一半。甚至复用也很难实现，因为很多页面中可能只访问一两次数据库，如果没有自己设
计或者底层的连接池，页面切换该消耗的还是要消耗。就算不是这样，按照设计的一般标
准，需要把粒度细化，这样结果和上面一样，如果要重用，必须附加上多余的耦合变量，
更加不好。
反过来有了连接池，也基本上不需要conn，或者st，后者根据使用者的经验，似乎可以表
达为得到rs后就可以关闭或者直接重用。conn也是可以重用的（否则也就不能连接池了）
，不过大概需要在前一个返回的resultset被关闭之后，也就是我说的和tcp连接对应的概
念，这个和ado不同。
Re: jdbc资源的回收问题(To mysapphire)！ 发表时间: 2004年04月19日 17:48:06
回复
发表人: navyzhu 发表文章: 7 / 注册时间: 2003-03
我用的数据库是SQLServer2000,程序是一个数据月结程序，开始我发现月结有时成功，有
时失败，看了后台才发现因为Statement没有Close,所以Connection太多以至于打开几百个
Connection,结果处理失败。
Re: jdbc资源的回收问题！ 发表时间: 2004年04月20日 11:01:32 回复
发表人: xunzy 发表文章: 4 / 注册时间: 2004-04
JDBC3.0规范中提出了一个新的规范：把Statement也进行缓存（一般是应用服务器厂商实
现），这样就可以在不同的connection之间可以共享Statement。所以我个人以为，在释放
connection之前，最好先close Statement，这样有利于statement的重用（而且这也是规
范所推荐的比较好的编程习惯）。
Re: jdbc资源的回收问题！ 发表时间: 2004年04月20日 11:35:01 回复
发表人: cats_tiger 发表文章: 79 / 注册时间: 2003-05
Statement和PreparedStatement已经将数据库操作封装的很好了，所以我从来不再作一个
类完成类似的操作。另外connection资源一定要用完就关。不要返回ResultSet对象，用R
owSet代替。
Re: jdbc资源的回收问题！ 发表时间: 2004年04月20日 16:34:19 回复
发表人: arthurlian 发表文章: 5 / 注册时间: 2003-09
我在oracle中，如果不关statement,最后oracle会报错
ORA-1000: max cursor exceeded.
可以在 v$open_cursor中查询未关闭的cursor.
最好还是用完就关。
Re: jdbc资源的回收问题！ 发表时间: 2004年04月20日 21:25:38 回复
发表人: mysapphire 发表文章: 17 / 注册时间: 2003-12
有一点应该是统一的吧？那就是：当直接connection.close()的时候java端的st对象资源
必定已经被释放了，而在DB端相应的cursor资源也许不会马上释放，不同的DB厂商针对这
有情况有不同的资源回收策略。
但问题是：是不是正如oldma所说的那样，我们也可以把DB端的资源回收当作黑盒（或者一
个能自我调整的容器）来看待，而不必去关心它的溢出或者阻塞？？？正如我们现在经常
使用的连接池pool一样！！
1）如果是这样的，那么我们可以只处理connection的关闭，因为connection的关闭会自动
引起java端的rs、st和pst的关闭，而在DB端，则有cache可以复用这些未被显式释放的cu
rsor资源，使这些资源不至于被挂起；
2）如果不是这样，那么我们必须手工关闭rs、st和pst这些与数据库资源对应的对象来释
放DB端的资源，然后在最后关闭conn，因为DB不会聪明地调度这些被挂起的资源,不主动关
闭它们会导致DB资源被耗尽。
通过回答这一问题，请大家告诉我，我在发帖的时候写的那个函数在极度频繁被调用时可
行吗？因为这个函数不处理任何close()操作，只是根据调用者的connection参数和Strin
g参数返回rs给调用者，在调用者的代码的最后会有rs.close()和connection.close()操作
，但是肯定不会有st.close()。 那么这个未被显式地close()的st就是我一直不清楚的东
西，在非常频繁地被重复这样调用（事实上这样的调用就象out.print（）一样多）后，D
B端会是怎样一种情况？
Re: jdbc资源的回收问题！(To mysapphire) 发表时间: 2004年04月21日 09:00:06
回复
发表人: navyzhu 发表文章: 7 / 注册时间: 2003-03
对于频繁调用的函数Connecton及Statement绝对要Close,正如其他网友所说，不同的数据
库可能有不同的实现，但考虑到重用及数据库的移植等问题，还是Close吧。
Re: jdbc资源的回收问题！(To mysapphire) 发表时间: 2004年04月21日 09:24:03
回复
发表人: flag 发表文章: 3 / 注册时间: 2004-04
有道理!
※ 来源:·BBS 水木清华站 smth.org·[FROM: 211.71.11.*]
索引页面|上一篇|下一篇
[返回] 中文XML论坛 - 专业的XML技术讨论区 →
计算机技术与应用 → 『 Java/Eclipse 』 → jdbc资源的回收问题[转载]
(订阅本版)
2004/9/23 0:39:00
新浪微博
jdbc资源的回收问题[转载]
