对流关闭的一点认识

1.创建的流一定要有引用,便于回收.比如通过某个方法得到的流如果直接当成参数传递了就不能关闭了;
 比如f()函数返回InputStream,而 f1(InputStream); 我们不能就f1(f()),这样流就不能关闭了.

 

 

2.使用流一定要连续使用,举个例子,InputStream in=f.getInputStream();很可能我们的这个方法得到的流已经关闭了,但是对象依然存在内存里面,这个时候如果我们再用in去做读写操作,就会报流关闭的错误了.

 

在举个更具体点的例子,在a类里面我们可能给b类设置了流,并且关闭了,在c类里面要用b类的流去读写,这个时候就出问题了,因为流已经关闭了,所以在c类想用流做的一些事情就直接在a类里面做了,在关闭流这样就不会出现问题了

 

 

第二点尤其要注意,于此类似的还有数据库的连接,socket,也是一样的道理,因为这些资源跟普通的java类是不一样的,内存和文件,内存和数据库它是有一根隐形的"带子"连在一起,而其他的类没有,自己的感悟而已,跟大家分享一下,如有错误,请多指点

Stream这样的东西,能不传递就尽量不要传递,和包含瞬时状态的对象少传递为妙,比如Socket,Socket.getInputStream传递给其他方法,Socket close掉了,Stream自然close掉了

建议看看MINA的框架，好的框架会把流封装的很好，对于SOCKET来说寻找一个统一的领域是很容易的 因为在你的业务中都可以用BYTE［］进行传递。

比如A B C D四个业务节点，A是进行解压的B是进行解密的C是业务逻辑D是其他什么操作。
在这个流程中完全可以通过BYTE［］进行传递。这个是横向的设计。
纵向而言，SOCKET完全可以把它解收到的数据塞到业务中（应用回掉就是了），这样方便统一管理SOCKET，对于业务SOCKET不暴露，可以保证俩连接安全。

其实这个道理跟C＋＋内存分配与释放道理很相似。

楼上说的用封装来保证， 也是一个办法， 但是未免要求也过于高， 很多一般的程序员是很难做到的。

C＋＋， 我以前的处理原则就是 谁分配， 谁释放。 我想对于资源， 都可以使用类似办法。  －－－见笑了， 这个原则很多人不赞同的。

楼上的为什么这个原则不赞同？

我倒想听听

谁分配， 谁释放，对于小系统是适合的，但是如果资源有限，系统压力大的情况下 水位不容易控制。这时候这种就不适用了。

楼上的，还是有点想不通~


我觉得如果压力大，不能将其归结于 谁分配， 谁释放的原则。

希望能有更详细的例举~~~

OK  说说我的看法。
第一 谁分配的问题。你把分配权限公布出去，那么是不是谁都可以分配。那么你这个水位你控制。


第二 谁释放的问题。比你更高层的调用者怎么知道你什么时候会释放。

如果，你这个流是一个存活在多线程的环境中，你会怎么解决这个水位问题。

数据库连接池应该就是这个原则的体现

难道我们当我们遇到连接数不够的时候能将性能问题归结于我们用了连接池？


针对你说的
如果，你这个流是一个存活在多线程的环境中，你会怎么解决这个水位问题。

我认为不管这个流在哪种环境下，如果你不用了，你必须及时归还你的引用，关不关你就别操心了！

这个不违背 谁分配，谁释放的原则。

难道我们当我们遇到连接数不够的时候能将性能问题归结于我们用了连接池？

这个问题你要感谢连接池，如果没有连接池的保护，你的数据库可能会挂掉。

这个就是我说的水位保护问题。