Java 我必须关闭FileInputStream吗？

我是测试自动化的实习生。 我正在使用Eclipse创建Junit代码，并使用Eclipse运行。 因为我使用FileInputStream函数从excel工作表中检索数据

FileInputStream fi=new FileInputStream("c:\\search.xls");
Workbook w=Workbook.getWorkbook(fi);
Sheet s=w.getSheet(0);

---

是否需要关闭Inputstream函数？如果是这样的话，请给我一些编码。

是的，如果你想让你的系统资源释放回来，你需要关闭输入流

是您需要的。

您需要关闭（）或结束程序

FileInputStream fi=null;
try {
    fi=new FileInputStream("c:\\search.xls");
    Workbook w=Workbook.getWorkbook(fi);
    Sheet s=w.getSheet(0);
} finally {
    if (fi!=null) {
        fi.close();
    }
}

但是，如果不按要求关闭文件，可能会遇到令人困惑的问题

• 有时测试单独运行，或者在同一进程中运行一组测试。（因此，您可以进行一个测试，该测试以一种方式工作，但不能以另一种方式工作）
• 无法重命名或删除打开的文件

---

最好的做法是始终关闭您已使用完的资源，但我认为单元测试是脚本，不必始终遵循最佳做法。

Basic CompSci 101告诉我们，确保关闭我们以Java或任何语言打开的资源。所以，是的，你需要关闭它们。当你不这样做的时候，坏的jujuju肯定会发生

---

此外，您应该学习（并有兴趣）使用Javadocs。在Javadoc中查找FileInputStream和Closeable。答案就在那里。

关闭您使用的资源总是一个好主意，但是：

如果在resourceB中使用resourceA，则关闭B而不是A是明智的，前提是它有方法

在您的情况下，您在

工作簿

中使用

文件输入流

，因此您最好关闭

工作簿

，并依靠

Workbok

来关闭

文件输入流

---

在这种特殊情况下，实际上，

Workbook

FileInputStream

位于

getWorkbook（）

方法的末尾，但是

Workbook

能够被垃圾收集仍然是个好主意。

是的！在使用完这些资源之后，您应该始终释放它们一次。Java有一个强大的垃圾收集机制（请注意，它与资源管理/泄漏不同） 因此，垃圾收集器无法确定您将来是否需要该资源？未能释放资源可能会导致拒绝服务、性能差等问题

如前所述，但另一种省力的方法是

---

现在不需要显式调用fi.close（）方法

最近，当我试图重构代码时，我不得不将工作簿的创建移到另一个方法，而FileInputStream就是在该方法中创建的。该方法创建FileInputStream并返回工作簿。但是FileInputStream在主方法中不可见；那么，我将如何在main方法的末尾关闭FileInputStream呢？答案是，您不必关闭FileInputStream，而只需关闭工作簿，它会在内部关闭FileInputStream。简言之，无论发生什么情况都必须关闭FileInputStream是不正确的

我这样做是为了确保关闭excel文件输入流，这可能会有所帮助

abstract int workWithWorkBook(Workbook workBook);

protected int doWorkBook(Path excelFile) throws IOException {
    File f = excelFile.toFile();

    try (FileInputStream excelContent = new FileInputStream(excelFile.toFile())){
        POIFSFileSystem fileSystem = new POIFSFileSystem(excelContent);
        Workbook workBook = null;
        if (f.getName().endsWith("xls")) {
            workBook = new HSSFWorkbook(fileSystem);
        } else if (f.getName().endsWith("xlsx")) {
            workBook = new XSSFWorkbook(excelContent);
        }
        return workWithWorkBook(workBook);

    }catch (Exception e){
        e.printStackTrace();
        throw e;
    }
}

---

9b9ea92b-5b63-47f9-a865-fd40dd602cd5

执行类似操作

FileInputStream fi=null;
try{
fi = new FileInputStream("c:\\search.xls");
Workbook w=Workbook.getWorkbook(fi);
Sheet s=w.getSheet(0);
}catch(IOException ioe){
}finally{
if(fi != null){
fi.close();
}
fi = null;//This will be hint to get finalize() called on fi so that underlying resources used will released like files opened.
}

---

只需一个小注释-您还需要用try/catch将

close（）

语句包装为

close（）

声明抛出选中的IOException。事实上，你不能这样使用finally。您只能在运行时异常的情况下进行try/finally。但是对于检查过的异常，比如IOException及其子类，您必须有一个try/catch或try/catch/finally。。。它不会使用try/finally进行编译。这取决于是否为该方法声明了IOException。如果你抓住了它，你应该知道怎么处理它。重要的部分是将close（）放在finally块中。事实上，自动处理这一点是我非常期待在Java7中看到的特性之一。盲目地遵循既定规则而没有批评和理解原因，这是一种非常糟糕的方法？部分糟糕的事情会发生——哦，普通？！编程不是巫术，如果不提及未正确释放资源的后果（文件无法移动，通常可能会导致内存泄漏），您的答案是无用的，而且是有害的。否决票。噢，我用一种语言，你说“他相信巫毒”（而不是“啊啊啊，他没有说出来，选择了一些方言）还有相当多的其他回答没有说明后果，除非你去neg代表他们，否则你只是在有偏见的高高在上爬一堆肥皂盒。为什么我不解释这些问题（为什么这篇文章中的大多数人没有）？因为它们很容易找到合适的文献，供任何进行少量研究的人使用。如果您觉得不合适，您可以选择。关闭资源的理由很好。我会在列表中添加太多打开的文件和内存泄漏，特别是对于长期存在的进程。@Elist GCs和它们在清理时关闭。确实，进程的长生命周期可能不是原因。更常见的是，递归读取文件/目录会导致

打开的文件过多。

。无论如何，我自己也看到过这两种情况，所以无论触发因素是什么，这都是现实生活中的情况。但是

工作簿

界面没有方法名为

close

，如何关闭

工作簿

？请不要只发布代码。junit测试需要它吗？进程存在后不会释放资源吗？是的，进程退出后，没有什么可利用的。因此，操作系统将回收资源。但想法是让测试以稳定的方式运行这就像问“如果我关掉我的设备怎么办？”：-）这也取决于操作系统。查看此问题以了解更多详细信息

FileInputStream fi=null;
try{
fi = new FileInputStream("c:\\search.xls");
Workbook w=Workbook.getWorkbook(fi);
Sheet s=w.getSheet(0);
}catch(IOException ioe){
}finally{
if(fi != null){
fi.close();
}
fi = null;//This will be hint to get finalize() called on fi so that underlying resources used will released like files opened.
}