为什么要关闭数据库连接，可以不关闭吗

首先要说明的是连接数是有限制的：

代码如下：

for (int i = 0i <10000i++)

{

SqlConnection conn = new SqlConnection(@"Data Source=.\SQLEXPRESS

AttachDbFilename=""E:\DB\NORTHWND.mdf""

Integrated Security=TrueConnect Timeout=30User Instance=True")

conn.Open()

Console.WriteLine("打开了{0}个连接", i)

}

运行结果如下：

过一会就会提示打开连接超时了：

可以看到数据库连接时有限制的，如果连接不关闭，而且使用的人比较多，那么系统很快就down掉了。

但是有时候由于某些原因应用程序可能只是几个人使用，所以就有人设计了：

在应用程序启动的时候打开数据库连接，在应用程序关闭的时候关闭数据库连接

那么使用这种方式有什么问题呢？

首先假设有一张表Nums，表定义如下：

Main代码如下：

SqlConnection conn = new SqlConnection(@"Data Source=.\SQLEXPRESS

AttachDbFilename=""E:\DB\NORTHWND.mdf""

Integrated Security=TrueConnect Timeout=30User Instance=True")

conn.Open()

Parallel.For(1, 9999, (id) =>

{

ExecuteCommand(conn, id)

})

就是从1到9999开始执行ExecuteCommand

ExecuteCommand代码如下：

private static void ExecuteCommand(SqlConnection conn, int id)

{

Console.WriteLine("正在执行." + id)

Thread.Sleep(100)

SqlCommand cmd = new SqlCommand(

string.Format("Insert into Nums values('{0}') ", id), conn)

cmd.ExecuteNonQuery()

}

运行：

可以看到ExecuteNonQuery方法抛出了异常，原因是连接处于关闭状态。

可是我们的连接一直都是open着的啊，并没有调用close，dispose之类的方法啊。

于是在ExecuteCommand前面增加判断条件：

if (conn.State != System.Data.ConnectionState.Open)

conn.Open()

再次运行：

可以看到还是会出现连接已关闭的问题。你知道什么原因吗？

这里是由于多线程环境引起的。所以需要加锁。

private static object syncObj = new object()

private static void ExecuteCommand(SqlConnection conn, int id)

{

lock (syncObj)

{

if (conn.State != System.Data.ConnectionState.Open)

conn.Open()

Console.WriteLine("正在执行.." + id)

Thread.Sleep(100)

SqlCommand cmd = new SqlCommand(

string.Format("Insert into Nums values('{0}') ", id), conn)

cmd.ExecuteNonQuery()

}

}

再次运行：可以发现基本没问题了.

修改Parallel.For的最大值上限，要测试下是否可以长期执行了。

Parallel.For(1, Int32.MaxValue, (id) =>

{

ExecuteCommand(conn, id)

})

一天测试下来，没出现任何问题。

结论：对于某些只有几个人使用的应用程序，可以不关闭数据库连接，但是在写代码的时候最好要加上连接是否打开的判断。

你有什么好的看法呢，欢迎留下!

作者：LoveJenny

出处：http://www.cnblogs.com/LoveJenny/

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

分类: C#

正确使用SqlConnection对象，兼谈数据库连接池

今晚看到上了评论头条的LoveJenny写的为什么要关闭数据库连接，可以不关闭吗？，文章写得简单易懂非常不错，而且代码贴的很到位，下面的讨论也很激烈（老赵都跑过去留言两次了，我恨）。又查看了两遍原文中的代码，我同意评论中有几位的看法，真正造成多线程并行 *** 作数据库时的连接问题可能是由于对SqlConnection的不当使用。为什么呢？再来看一下LoveJenny兄弟贴出的一段重要源码：

1

2

3

4

5

6

7

8

9

string sqlConnString

= @"Data

Source=.\SQLEXPRESS

AttachDbFilename=""E:\DB\NORTHWND.mdf""

Integrated

Security=TrueConnect Timeout=30User Instance=True"

SqlConnection

conn = new SqlConnection(sqlConnString)

conn.Open()

Parallel.For(1,

Int32.MaxValue, (id) =>

{

ExecuteCommand(conn,

id)

})

其中，ExecuteCommand的具体实现如下：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

private static object syncObj

= new object()

private static void ExecuteCommand(SqlConnection

conn, int id)

{

lock (syncObj)

{

if (conn.State

!= ConnectionState.Open)

{

conn.Open()

}

Console.WriteLine("正在执行." +

id)

Thread.Sleep(100)

SqlCommand

cmd = new SqlCommand(

string.Format("Insert

into Nums values('{0}') ",

id), conn)

cmd.ExecuteNonQuery()

}

}

代码很简洁，但是很多人包括我自己忍不住都会有几个重大疑问：

1、怎么并行 *** 作n多次数据库只共用一个连接对象呢？

2、并行处理的地方加了锁，每次进行数据库 *** 作都要Lock一下（我感觉这根本没有发挥多线程并行处理的优势，个人认为还不如单线程执行的快呢），这个真的有这个必要吗？

3、同一个数据库连接字符串，使用数据库连接对象SqlConnection怎么还要传参呢，显式Open和Close不是更好吗？通常不都是using一下完事吗？

经过简单思考之后，在本地机器上改进了一下实现代码进行测试，如下：

1

2

3

4

Parallel.For(1,

Int32.MaxValue, (id) =>

{

ExecuteCommand(id)

})

ExecuteCommand方法不再接受SqlConnection对象作为参数，去掉Lock，数据库 *** 作看上去就像是 *** 作一次数据库，打开一次数据库连接，保证线程安全：

1

2

3

4

5

6

7

8

9

10

11

12

private static void ExecuteCommand(int id)

{

using (SqlConnection

conn = new SqlConnection(sqlConnString))

{

conn.Open()

Console.WriteLine("正在执行." +

id)

Thread.Sleep(100)

SqlCommand

cmd = new SqlCommand(

string.Format("Insert

into Nums values('{0}') ",

对于DB

Connection，JVM突然崩溃，DB

Server是有办法知道的，最起码它知道Socket连接断开了，数据库连接依赖于它。我测试过Oracle和MySQL的连接，对Oracle的连接，如果不调用Connection.close()方法，即使Socket连接断开了（比如JVM退出)，服务器端是不会关闭数据库连接的，但是它设置有超时时间。对MySQL的连接，一旦Socket连接断开，服务器端就会自动关闭数据库连接。

一般情况下使用完都会关的

但是例如连接池这种，就是大家直接使用即可，当web服务器结束时自动由框架帮你关闭。

我感觉关闭不关闭的原则是：如果可以很好的控制连接数量和最后的连接关闭，可以不用每次都关闭。

---