Java GC 为什么不能自动释放jdbc connection?# Java - 爪哇娇娃
T*x
1 楼
比如在一个函数内部，connection是一个local variable。
函数结束的时候为什么不自动释放jdbc connection？
做不到吗？内部有什么难度吗？
函数结束的时候为什么不自动释放jdbc connection？
做不到吗？内部有什么难度吗？
w*z
2 楼
it is more than memory, it is resource. Java 7 comes with closable to
rescure.
【在 T*******x 的大作中提到】
: 比如在一个函数内部，connection是一个local variable。
: 函数结束的时候为什么不自动释放jdbc connection？
: 做不到吗？内部有什么难度吗？
rescure.
【在 T*******x 的大作中提到】
: 比如在一个函数内部，connection是一个local variable。
: 函数结束的时候为什么不自动释放jdbc connection？
: 做不到吗？内部有什么难度吗？
f*t
3 楼
GC是一个独立的thread，变量生命周期结束后不确定什么时候会被释放。
a*w
4 楼
说句题外话，即使只涉及内存，有些内存GC也不会动，比如
obsolete object reference
【在 w**z 的大作中提到】
: it is more than memory, it is resource. Java 7 comes with closable to
: rescure.
obsolete object reference
【在 w**z 的大作中提到】
: it is more than memory, it is resource. Java 7 comes with closable to
: rescure.
c*e
5 楼
conn.close();
不就行了。
【在 T*******x 的大作中提到】
: 比如在一个函数内部，connection是一个local variable。
: 函数结束的时候为什么不自动释放jdbc connection？
: 做不到吗？内部有什么难度吗？
不就行了。
【在 T*******x 的大作中提到】
: 比如在一个函数内部，connection是一个local variable。
: 函数结束的时候为什么不自动释放jdbc connection？
: 做不到吗？内部有什么难度吗？
w*z
6 楼
不过，Java的resource close 是比较恶心，conn.close 也要放在try catch 里， 都
是没用的。
try-with-resource is a bit better
【在 c*********e 的大作中提到】
: conn.close();
: 不就行了。
是没用的。
try-with-resource is a bit better
【在 c*********e 的大作中提到】
: conn.close();
: 不就行了。
w*z
7 楼
不过，Java的resource close 是比较恶心，conn.close 也要放在try catch 里， 都
是没用的。
try-with-resource is a bit better
【在 c*********e 的大作中提到】
: conn.close();
: 不就行了。
是没用的。
try-with-resource is a bit better
【在 c*********e 的大作中提到】
: conn.close();
: 不就行了。
c*e
8 楼
有的把conn.close()还放在finally里。这玩艺都是约定俗成了，抄人家的code,也都是
这么写的。
c#里用using( ).
【在 w**z 的大作中提到】
: 不过，Java的resource close 是比较恶心，conn.close 也要放在try catch 里， 都
: 是没用的。
: try-with-resource is a bit better
这么写的。
c#里用using( ).
【在 w**z 的大作中提到】
: 不过，Java的resource close 是比较恶心，conn.close 也要放在try catch 里， 都
: 是没用的。
: try-with-resource is a bit better
T*x
9 楼
据说在finally里写是最好的:
try {
----Connection connection = dataSource.getConnection();
----Statement statement = connection.prepareStatement(sql);
----ResultSet result = statement.executeQuery();
...
} catch (Exception e) {
...
} finally {
----if (result != null) {
--------try {
------------result.close();
--------} catch (Exception e) {
--------}
----}
----if (statement != null) {
--------try {
------------statement.close();
--------} catch (Exception e) {
--------}
----}
----if (connection != null) {
--------try {
------------connection.close();
--------} catch (Exception e) {
--------}
----}
}
这么一大堆，好像是标准吧？
感觉挺麻烦的。而且一个函数中只能一个try跟一个finally。
多个try和多个finally，我感觉出口很复杂，可能会出漏洞。
【在 c*********e 的大作中提到】
: conn.close();
: 不就行了。
try {
----Connection connection = dataSource.getConnection();
----Statement statement = connection.prepareStatement(sql);
----ResultSet result = statement.executeQuery();
...
} catch (Exception e) {
...
} finally {
----if (result != null) {
--------try {
------------result.close();
--------} catch (Exception e) {
--------}
----}
----if (statement != null) {
--------try {
------------statement.close();
--------} catch (Exception e) {
--------}
----}
----if (connection != null) {
--------try {
------------connection.close();
--------} catch (Exception e) {
--------}
----}
}
这么一大堆，好像是标准吧？
感觉挺麻烦的。而且一个函数中只能一个try跟一个finally。
多个try和多个finally，我感觉出口很复杂，可能会出漏洞。
【在 c*********e 的大作中提到】
: conn.close();
: 不就行了。
g*g
10 楼
I think close connection is good enough. Or you can use JdbcTemplate and you
don't need to do anything at all.
【在 T*******x 的大作中提到】
: 据说在finally里写是最好的:
: try {
: ----Connection connection = dataSource.getConnection();
: ----Statement statement = connection.prepareStatement(sql);
: ----ResultSet result = statement.executeQuery();
: ...
: } catch (Exception e) {
: ...
: } finally {
: ----if (result != null) {
don't need to do anything at all.
【在 T*******x 的大作中提到】
: 据说在finally里写是最好的:
: try {
: ----Connection connection = dataSource.getConnection();
: ----Statement statement = connection.prepareStatement(sql);
: ----ResultSet result = statement.executeQuery();
: ...
: } catch (Exception e) {
: ...
: } finally {
: ----if (result != null) {
w*z
11 楼
you need to close all of them, connection, resultset, prepare statement.
otherwise memory leak.
you
【在 g*****g 的大作中提到】
: I think close connection is good enough. Or you can use JdbcTemplate and you
: don't need to do anything at all.
otherwise memory leak.
you
【在 g*****g 的大作中提到】
: I think close connection is good enough. Or you can use JdbcTemplate and you
: don't need to do anything at all.
w*z
12 楼
都这么写。写个helper会好一点。
【在 T*******x 的大作中提到】
: 据说在finally里写是最好的:
: try {
: ----Connection connection = dataSource.getConnection();
: ----Statement statement = connection.prepareStatement(sql);
: ----ResultSet result = statement.executeQuery();
: ...
: } catch (Exception e) {
: ...
: } finally {
: ----if (result != null) {
【在 T*******x 的大作中提到】
: 据说在finally里写是最好的:
: try {
: ----Connection connection = dataSource.getConnection();
: ----Statement statement = connection.prepareStatement(sql);
: ----ResultSet result = statement.executeQuery();
: ...
: } catch (Exception e) {
: ...
: } finally {
: ----if (result != null) {
e*t
13 楼
helper还是麻烦，等有java 8closure应该会好些吧。
【在 w**z 的大作中提到】
: 都这么写。写个helper会好一点。
【在 w**z 的大作中提到】
: 都这么写。写个helper会好一点。
g*g
14 楼
OK, you are probably right. I haven't done raw jdbc in years. Application
server always use a connection pool and you don't really want to open a
connection every time.
【在 w**z 的大作中提到】
: you need to close all of them, connection, resultset, prepare statement.
: otherwise memory leak.
:
: you
server always use a connection pool and you don't really want to open a
connection every time.
【在 w**z 的大作中提到】
: you need to close all of them, connection, resultset, prepare statement.
: otherwise memory leak.
:
: you
w*z
15 楼
java 7 added try with resource.
【在 e*****t 的大作中提到】
: helper还是麻烦，等有java 8closure应该会好些吧。
【在 e*****t 的大作中提到】
: helper还是麻烦，等有java 8closure应该会好些吧。
d*i
16 楼
Spring JDBC很好，把raw JDBC的麻烦都省掉了，看到一片文章说用Spring JDBC以后甚
至连Hibernate, JPA这些ORM都不用了，简单，直接又轻便。goodbug有何高见？
you
【在 g*****g 的大作中提到】
: I think close connection is good enough. Or you can use JdbcTemplate and you
: don't need to do anything at all.
至连Hibernate, JPA这些ORM都不用了，简单，直接又轻便。goodbug有何高见？
you
【在 g*****g 的大作中提到】
: I think close connection is good enough. Or you can use JdbcTemplate and you
: don't need to do anything at all.
r*s
17 楼
同意，
Criteria API真是寫的蛋疼也看得蛋疼
【在 d****i 的大作中提到】
: Spring JDBC很好，把raw JDBC的麻烦都省掉了，看到一片文章说用Spring JDBC以后甚
: 至连Hibernate, JPA这些ORM都不用了，简单，直接又轻便。goodbug有何高见？
:
: you
Criteria API真是寫的蛋疼也看得蛋疼
【在 d****i 的大作中提到】
: Spring JDBC很好，把raw JDBC的麻烦都省掉了，看到一片文章说用Spring JDBC以后甚
: 至连Hibernate, JPA这些ORM都不用了，简单，直接又轻便。goodbug有何高见？
:
: you
g*g
18 楼
俺们开始用Spring Data，好使。常见的query都不用写了。
【在 d****i 的大作中提到】
: Spring JDBC很好，把raw JDBC的麻烦都省掉了，看到一片文章说用Spring JDBC以后甚
: 至连Hibernate, JPA这些ORM都不用了，简单，直接又轻便。goodbug有何高见？
:
: you
【在 d****i 的大作中提到】
: Spring JDBC很好，把raw JDBC的麻烦都省掉了，看到一片文章说用Spring JDBC以后甚
: 至连Hibernate, JPA这些ORM都不用了，简单，直接又轻便。goodbug有何高见？
:
: you
r*s
19 楼
嗯,
spring data好使，
要拋棄criteria api
【在 g*****g 的大作中提到】
: 俺们开始用Spring Data，好使。常见的query都不用写了。
spring data好使，
要拋棄criteria api
【在 g*****g 的大作中提到】
: 俺们开始用Spring Data，好使。常见的query都不用写了。
w*z
20 楼
我们用 bonecp conneciton pool，performance 够好， 就是写SQL 比较蛋疼。想来
ORM 还是有用的。
有空要学习一下spring data， 我们只用Spring 的DI
【在 r*****s 的大作中提到】
: 嗯,
: spring data好使，
: 要拋棄criteria api
ORM 还是有用的。
有空要学习一下spring data， 我们只用Spring 的DI
【在 r*****s 的大作中提到】
: 嗯,
: spring data好使，
: 要拋棄criteria api
P*i
21 楼
bonecp+mybatis performance很好
【在 w**z 的大作中提到】
: 我们用 bonecp conneciton pool，performance 够好， 就是写SQL 比较蛋疼。想来
: ORM 还是有用的。
: 有空要学习一下spring data， 我们只用Spring 的DI
【在 w**z 的大作中提到】
: 我们用 bonecp conneciton pool，performance 够好， 就是写SQL 比较蛋疼。想来
: ORM 还是有用的。
: 有空要学习一下spring data， 我们只用Spring 的DI
d*i
22 楼
这个很不错，那JdbcTemplate的那些query都可以省了？
【在 g*****g 的大作中提到】
: 俺们开始用Spring Data，好使。常见的query都不用写了。
【在 g*****g 的大作中提到】
: 俺们开始用Spring Data，好使。常见的query都不用写了。
w*z
23 楼
我们都用stored procedure， 这还那么有用吗？
【在 d****i 的大作中提到】
: 这个很不错，那JdbcTemplate的那些query都可以省了？
【在 d****i 的大作中提到】
: 这个很不错，那JdbcTemplate的那些query都可以省了？
w*z
24 楼
我都人工写DAO layer， 就几个不复杂的query， 用ORM嫌麻烦，但人工写db column
mapping到 POJO， 确实烦。但一个service就几个POJO， 也不复杂。。。
【在 P****i 的大作中提到】
: bonecp+mybatis performance很好
mapping到 POJO， 确实烦。但一个service就几个POJO， 也不复杂。。。
【在 P****i 的大作中提到】
: bonecp+mybatis performance很好
b*y
25 楼
en, 我也是人工写，简单。关键是，用ORM的话，你学不到底层的东东
【在 w**z 的大作中提到】
: 我都人工写DAO layer， 就几个不复杂的query， 用ORM嫌麻烦，但人工写db column
: mapping到 POJO， 确实烦。但一个service就几个POJO， 也不复杂。。。
o*i
26 楼
我也是人工写，但是就是复制粘贴改改参数嘛，有什么底层的东东？
【在 b******y 的大作中提到】
:
: en, 我也是人工写，简单。关键是，用ORM的话，你学不到底层的东东
【在 b******y 的大作中提到】
:
: en, 我也是人工写，简单。关键是，用ORM的话，你学不到底层的东东
o*i
27 楼
有sql server支持么？
【在 g*****g 的大作中提到】
: 俺们开始用Spring Data，好使。常见的query都不用写了。
【在 g*****g 的大作中提到】
: 俺们开始用Spring Data，好使。常见的query都不用写了。
b*y
28 楼
en, 我没说清楚。是没啥东西了。
底层我们用的是Apache的multi-threaded object pooling library. 就是用来做jdbc
connection的那一层。
【在 o***i 的大作中提到】
: 我也是人工写，但是就是复制粘贴改改参数嘛，有什么底层的东东？
w*z
29 楼
dbcp ?
jdbc
【在 b******y 的大作中提到】
:
: en, 我没说清楚。是没啥东西了。
: 底层我们用的是Apache的multi-threaded object pooling library. 就是用来做jdbc
: connection的那一层。
jdbc
【在 b******y 的大作中提到】
:
: en, 我没说清楚。是没啥东西了。
: 底层我们用的是Apache的multi-threaded object pooling library. 就是用来做jdbc
: connection的那一层。
T*x
30 楼
connection pool也需要getConnection，
用完之后也要close吧。
【在 g*****g 的大作中提到】
: OK, you are probably right. I haven't done raw jdbc in years. Application
: server always use a connection pool and you don't really want to open a
: connection every time.
用完之后也要close吧。
【在 g*****g 的大作中提到】
: OK, you are probably right. I haven't done raw jdbc in years. Application
: server always use a connection pool and you don't really want to open a
: connection every time.
w*z
31 楼
connection pool implements close() method, it will put the connection back
to the pool. But for sure, caller needs to close ResultSet and Statement.
【在 T*******x 的大作中提到】
: connection pool也需要getConnection，
: 用完之后也要close吧。
to the pool. But for sure, caller needs to close ResultSet and Statement.
【在 T*******x 的大作中提到】
: connection pool也需要getConnection，
: 用完之后也要close吧。
b*y
32 楼
Yes, it is quite good and robust. Also, simple enough
【在 w**z 的大作中提到】
: dbcp ?
:
: jdbc
g*g
33 楼
都可以省了没有，简单的省了。不是太复杂的写个interface method足够。
【在 d****i 的大作中提到】
: 这个很不错，那JdbcTemplate的那些query都可以省了？
【在 d****i 的大作中提到】
: 这个很不错，那JdbcTemplate的那些query都可以省了？
g*g
34 楼
基于JPA，应该没有问题。
【在 o***i 的大作中提到】
: 有sql server支持么？
【在 o***i 的大作中提到】
: 有sql server支持么？
g*g
35 楼
I don't think you need to do that when using JdbcTemplate or Spring Data/
Hibernate/JPA. You probably don't need those at all with ORM.
【在 w**z 的大作中提到】
: connection pool implements close() method, it will put the connection back
: to the pool. But for sure, caller needs to close ResultSet and Statement.
Hibernate/JPA. You probably don't need those at all with ORM.
【在 w**z 的大作中提到】
: connection pool implements close() method, it will put the connection back
: to the pool. But for sure, caller needs to close ResultSet and Statement.
T*x
36 楼
也需要connection.close()才能put connection back to pool吧？
【在 w**z 的大作中提到】
: connection pool implements close() method, it will put the connection back
: to the pool. But for sure, caller needs to close ResultSet and Statement.
【在 w**z 的大作中提到】
: connection pool implements close() method, it will put the connection back
: to the pool. But for sure, caller needs to close ResultSet and Statement.
c*e
37 楼
re
【在 T*******x 的大作中提到】
: 也需要connection.close()才能put connection back to pool吧？
【在 T*******x 的大作中提到】
: 也需要connection.close()才能put connection back to pool吧？
w*z
38 楼
the connection pool implementation overrides the close method , if you call
close on the connection, it will be put back to the pool.
【在 c*********e 的大作中提到】
: re
close on the connection, it will be put back to the pool.
【在 c*********e 的大作中提到】
: re
b*y
39 楼
call
Ya, that's about right
【在 w**z 的大作中提到】
: the connection pool implementation overrides the close method , if you call
: close on the connection, it will be put back to the pool.
m*t
40 楼
because most of JDBC drivers use native code ( like C, or C++ ), which
create objects outside of java heap. Java GC cannot collect those native
object memory. close() method inside finally block can guarantee the
invocation of native memory release method provided by specific JDBC
provider.
create objects outside of java heap. Java GC cannot collect those native
object memory. close() method inside finally block can guarantee the
invocation of native memory release method provided by specific JDBC
provider.
w*z
41 楼
this one is a pure Java:
http://dev.mysql.com/doc/refman/5.6/en/connector-j-overview.htm
Oralce JDBC thin driver is also written in Java
http://docs.oracle.com/cd/E16655_01/java.121/e17657/overvw.htm
Consider the following when choosing a JDBC driver for your application or
applet:
In general, unless you need OCI-specific features, such as support for
non-TCP/IP networks, use the JDBC Thin driver.
If you want maximum portability and performance, then use the JDBC Thin
driver. You can connect to Oracle Database from either an application or an
applet using the JDBC Thin driver.
If you want to use Lightweight Directory Access Protocol (LDAP) over
Secure Sockets Layer (SSL), then use the JDBC Thin driver.
If you are writing a client application for an Oracle client environment
and need OCI-driver-specific features, such as support for non-TCP/IP
networks, then use the JDBC OCI driver.
If you are writing an applet, then you must use the JDBC Thin driver.
For code that runs in the database server and needs to access a remote
database or another session within the same database instance, use the JDBC
server-side Thin driver.
If your code runs inside the database server and needs to access data
locally within the session, then use the JDBC server-side internal driver to
access that server.
【在 m*********t 的大作中提到】
: because most of JDBC drivers use native code ( like C, or C++ ), which
: create objects outside of java heap. Java GC cannot collect those native
: object memory. close() method inside finally block can guarantee the
: invocation of native memory release method provided by specific JDBC
: provider.
http://dev.mysql.com/doc/refman/5.6/en/connector-j-overview.htm
Oralce JDBC thin driver is also written in Java
http://docs.oracle.com/cd/E16655_01/java.121/e17657/overvw.htm
Consider the following when choosing a JDBC driver for your application or
applet:
In general, unless you need OCI-specific features, such as support for
non-TCP/IP networks, use the JDBC Thin driver.
If you want maximum portability and performance, then use the JDBC Thin
driver. You can connect to Oracle Database from either an application or an
applet using the JDBC Thin driver.
If you want to use Lightweight Directory Access Protocol (LDAP) over
Secure Sockets Layer (SSL), then use the JDBC Thin driver.
If you are writing a client application for an Oracle client environment
and need OCI-driver-specific features, such as support for non-TCP/IP
networks, then use the JDBC OCI driver.
If you are writing an applet, then you must use the JDBC Thin driver.
For code that runs in the database server and needs to access a remote
database or another session within the same database instance, use the JDBC
server-side Thin driver.
If your code runs inside the database server and needs to access data
locally within the session, then use the JDBC server-side internal driver to
access that server.
【在 m*********t 的大作中提到】
: because most of JDBC drivers use native code ( like C, or C++ ), which
: create objects outside of java heap. Java GC cannot collect those native
: object memory. close() method inside finally block can guarantee the
: invocation of native memory release method provided by specific JDBC
: provider.
相关阅读
[转载] any Java Performance Tuning tools?Java GUI Testingwhere to get mock? Re: 考SCEA归来JDBC如何获取新加入的记录的索引Solaris Container 和 DTrace实实在在受不了了，还是来这里求教！使用eclipse方法对第三方库建立Wrapper的小技巧。关于Java Bean的一个有趣问题问一个generic的问题吧ASP 开发工具？急问！！！[转载] Java 1.5 Generic 问题How to read/load a .tif image?jit编译器？JSP的一个问题这二句为什么会抛出ClassCastException异常?static getInstance() 有没有java clustering的书或资料推荐？any good book for java certificated pgmer test?Core J2EE Design Pattern[转载] 怎样让oracle不要fail on error