对流关闭的一点认识

我们自己写的数据库连接池都是用了然后显示的调用close来关闭的,我们的系统是几十万人用都没有出现过数据库崩溃的现象.谁创建谁关闭,就是这个原则.

系统是几十万人用，同一时间并发几个。如果你的系统是一个SOA平台中的转发节点（和路由器一样的） 同一时间压力的话你怎么办？  我不是反对谁创建谁关闭，我只是想说明一点，水位保护是一个让你系统更健壮的东西，不要排斥它。
简单的说，你的WEB服务器，你能想让几个人连接就有几个人连接吗？

假如你的数据库支持同一时间最多100个会话，按你的想法谁创建谁关闭，那么当同时并发超过100个的时候你怎么办？ 你怎么去做你的等待机制，再者，你怎么去很好知道我创建了的连接就 能被正确关闭，如果你的系统没问题，而数据库出问题了。你又如何提高你系统的容错能力。

我只是在设计的角度提出一种我认为比较可行的方案。

楼上的， POOL的东西， 不是应用本身建立的， 这个东西可以理解为pool自己创建的。

大家是如何理解为什么流需要自己手动关闭，而不是靠垃圾回收器或者操作系统来回收的？？？

系统对资源的回收永远不是及时的；
如果不自己manually关闭，可能潜在的隐患会不少

流和数据库连接这类系统资源有两个特点，一个是有限性，二独占性。所以这类资源被占用的时间应该尽可能短，而数据库连接池这类被池化的对象还有另外一层原因，创建资源过程消耗时间或空间过多。对象的生命周期基本上都是create-->ready-->serve(maybe many time)-->destroy,对于我们来说serve的过程是最重要的，如果对象是无状态的，则可以多线程共享，如果是有状态的或者提供的数据是不可分割的（事务的），则为每个线程服务完毕之后，需要置为ready状态才可为下个线程服务。我们需要增强的是ready-->serve这段，最坏的情况就是不能线程共享的对象要长时间的服务，假如事务的不可分割，需要长时间占用资源对象的serve时间，这就要需要协作对象之间有某种默契，谁创建谁关闭则是一种默契了，而另置一个事务控制器（通常是AOP织入）也是一种默契，前者是创建者兼任了事务控制器，有时候事务资源夸的调用太多了，那事务资源通常都会某种包装，比如创建者把资源包装起来，除了创建者本身，不能destroy资源（或者将资源重置ready状态），对于使用过Proxy模式的人来说这再熟悉不过了，这里有个陷阱就是创建者忘记关闭资源了，需要有个测试机制对其进行补漏，而事务控制器则不易出现这方面的缺陷。
还有的系统，事务设计是可分段提交的，或快速失败的，或乐观锁机制等等手段。无它，都是为了避免人脑（程序员）的出错（概率很高哦，风险也高）。