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