很多次我遇到这样的说法，即应用程序应该始终明确地关闭它打开的所有资源。
我的编程方法是相当务实的，我不喜欢盲目地遵循任何我看不到好处的约定。因此我的问题。
让我们假设：
我真的必须关心关闭我打开的所有资源吗？我猜我打开的所有资源都会在应用程序/虚拟机退出时关闭/释放。我对吗？
如果这是真的，是否有任何令人信服的理由来关心在如此小的、短工作的应用程序中关闭资源？
更新：
这个问题纯粹是假设性的，但不关心这一点的理由是我可能只是在拼凑一些快速脚本并且不想编写任何与手头问题没有直接关系的不必要代码：关闭资源，做所有这些冗长的 try-catch-finally 东西，处理我不关心的异常等。
问题的关键在于不这样做是否会产生任何实际后果。
我猜我打开的所有资源都会在应用程序/虚拟机退出时关闭/释放。
没有定期释放的资源会发生什么，这是您无法控制的。它可能不会造成伤害，也可能会造成一些伤害。它还高度依赖于平台，因此仅对其中一个进行测试无济于事。
我为什么要关心在这么小的、短的工作应用程序中关闭这些资源？
应用程序的大小应该无关紧要。首先，应用程序通常会增长；第二，如果你不练习正确的方法，你将不知道如何在重要的时候去做。
如果不关闭资源，可能会导致资源耗尽时应用服务器频繁重启。因为操作系统和服务器应用一般都有资源上限
根据文档
典型的 Java 应用程序会操作多种类型的资源，例如文件、流、套接字和数据库连接。这些资源必须非常小心地处理，因为它们会为它们的操作获取系统资源。因此，您需要确保它们即使被释放万一出现错误。
实际上，不正确的资源管理是生产应用程序中常见的故障源，常见的缺陷是数据库连接和文件描述符在代码中的其他地方发生异常后仍保持打开状态。这会导致应用程序服务器在资源耗尽时频繁重启，因为操作系统和服务器应用程序通常对资源有上限。
java 7 中为讨厌 close 语句的程序员引入的try-with-resources语句。
简短的回答 - 是的。一方面，这是一种糟糕的编码实践，就像在生活的其他领域一样，自己不清理。另一方面，您无法预测操作系统是否会识别出 Java 环境不再需要这些资源，并且您最终可能会锁定文件/等，如果不强制重启就无法释放。
始终清理您打开的任何资源！
关于您对原始问题的更新的更新 - 添加 try/catch 块以关闭任何打开的资源需要 5 秒钟，并且可以防止您不得不花费 5 分钟重新启动计算机。做对了，最终总能节省时间。我爸爸总是告诉我，真正的懒人第一次就做对了，这样他们就不必再回来做这件事了。我只是说不要偷懒，做对了。编写一个 catch 块所花费的 5 秒永远不会显着减慢编写过程......通过不编写它节省的 5 秒可能会极大地减慢您的调试速度。