Java io包封装了常用的I/O操作，流式操作被统一为InputStream、OutputStream、Reader、Writer四个抽象类，其中InputStream和OutputStream为字节流，Reader和Writer为字符流。流式抽象的好处在于程序员无需关心数据如何传输，只需按字节或字符依次操作即可。
在使用流式对象进行操作时，特别是文件操作，使用完毕后千万不能忘记调用流对象的close()方法，这也是老生常谈的话题，但是偏偏很容易忘记，或者没忘记但是使用不当导致close()方法没调用到。正确的做法是把close()方法放在finally块中调用，比如这样：
InputStream in = ...;OutputStream out = ...;try {
doSth(in, out);} catch (Exception e) {
handleException();} finally {
try {
in.close();
} catch (Exception e1){
}
try {
out.close();
} catch (Exception e2){
}}Java流式操作在便捷了I/O操作的同时，也带来了错误处理上复杂性，这也是Java被人诟病的理由之一。Golang在这块的处理就非常优雅，它提供了defer关键字来简化流程。
当文件流未被显式关闭时，会产生怎样的后果？结果就是会引起文件描述符(fd)耗尽。以下代码会打开一个文件10次，向系统申请了10个fd。
public static void main(String[] args) throws Exception {
for (int i = 0; i < 10; i++) {
InputStream is = new FileInputStream(new File("file"));
}
System.in.read(b); // pause}到/proc/{pid}/fd目录下确定已打开的文件描述符：
root@classa:/proc/16333/fd# ls -ltotal 0lrwx------ 1 root root 64 Aug 2 20:43 0 -> /dev/pts/3lrwx------ 1 root root 64 Aug 2 20:43 1 -> /dev/pts/3lr-x------ 1 root root 64 Aug 2 20:43 10 -> /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/sunjce_provider.jar lr-x------ 1 root root 64 Aug 2 20:43 11 -> /root/file lr-x------ 1 root root 64 Aug 2 20:43 12 -> /root/file lr-x------ 1 root root 64 Aug 2 20:43 13 -> /root/file lr-x------ 1 root root 64 Aug 2 20:43 14 -> /root/file lr-x------ 1 root root 64 Aug 2 20:43 15 -> /root/file lr-x------ 1 root root 64 Aug 2 20:43 16 -> /root/file lr-x------ 1 root root 64 Aug 2 20:43 17 -> /root/file lr-x------ 1 root root 64 Aug 2 20:43 18 -> /root/file lr-x------ 1 root root 64 Aug 2 20:43 19 -> /root/file lrwx------ 1 root root 64 Aug 2 20:43 2 -> /dev/pts/3lr-x------ 1 root root 64 Aug 2 20:43 20 -> /root/file lr-x------ 1 root root 64 Aug 2 20:43 3 -> /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/rt.jar
但是根据以往经验，即使流未显式关闭，也没见过文件描述符耗尽的情况。这是因为Java文件流式类做了保护措施，FileInputStream和FileOutputStream类利用Java的finalizer机制向GC注册了资源回收的回调函数，当GC回收对象时，实例对象的finalize()方法被调用。以FileInputStream为例，看看它是怎么处理的：
/**
* Ensures that the close method of this file input stream is
* called when there are no more references to it.
*
* @exception IOException if an I/O error occurs.
* @see java.io.FileInputStream#close()
*/protected void finalize() throws IOException {
if ((fd != null) && (fd != FileDescriptor.in)) {
/*
* Finalizer should not release the FileDescriptor if another
* stream is still using it. If the user directly invokes
* close() then the FileDescriptor is also released.
*/
runningFinalize.set(Boolean.TRUE);
try {
close();
} finally {
runningFinalize.set(Boolean.FALSE);
}
}}当fd未释放时，finalize()方法会调用close()方法关闭文件描述符。有了这一层保障后，即使程序员粗心忘了关闭流，也能保证流最终会被正常关闭了。以下程序可以验证：
public static void main(String[] args) throws Exception {
for (int i = 0; i < 10; i++) {
InputStream is = new FileInputStream(new File("file"));
}
byte[] b = new byte[2];
System.in.read(b); // pause1
System.gc();
System.in.read(b); // pause2}Java运行参数加上GC信息便于观察：
# java -verbose:gc -XX:+PrintGCDetails -Xloggc:gc.log -XX:+PrintGCTimeStamps StreamTest
程序在pause1处打开了10个fd，接着强制通过System.gc()触发一次GC，等gc.log中GC日志输出后再观察/proc/{pid}/fd目录，发现已打开的文件描述符均已经关闭。
但是即便如此，依然存在资源泄漏导致程序无法正常工作的情况，因为JVM规范并未对GC何时被唤起作要求，而对象的finalize()只有在其被回收时才触发一次，因此完全存在以下情况：在两次GC周期之间，文件描述符被耗尽！这个问题曾经在生产环境中出现过的，起因是某同事在原本只需加载一次的文件读取操作写成了每次用户请求加载一次，在一定的并发数下就导致too many open file的异常：
Exception in thread "main" java.io.FileNotFoundException: file (Too many open files) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:146) ......
原文链接:http://outofmemory.cn/java/io-stream-resource-leak-analysis