我多次遇到这样的声明:应用程序应该始终显式关闭它打开的所有资源。
我的编程方法相当务实,我不喜欢盲目地遵循任何我不明白的好处。因此我的问题。
我们假设:
我真的要关心关闭我打开的所有资源吗?我猜我打开的所有资源都将在应用程序/虚拟机退出时关闭/释放。我是对的吗?
如果这是真的,有没有令人信服的理由关心在如此短小的工作申请中关闭资源?
更新:
这个问题纯属假设,但不关心的论点是,我可能只是在一起编写一些快速脚本而不想写任何不直接与之相关的不必要代码手头的问题:关闭资源,做所有这些冗长的try-catch-finally东西,处理我不关心的异常等。
问题的关键在于是否存在不执行此操作的实际后果。
答案 0 :(得分:10)
我猜我打开的所有资源都将在应用程序/虚拟机退出时关闭/释放。
未经过定期发布的资源会发生什么事情是您无法控制的。它可能没有坏处,也可能会有所作为。它也是高度依赖平台的,所以只对一个进行测试无济于事。
为什么我要关心在这么小的短工作应用程序中关闭这些资源?
应用程序的大小无关紧要。首先,应用程序通常会增长第二,如果你没有以正确的方式练习,你就不会知道如何做到这一点。
答案 1 :(得分:8)
如果不关闭资源,可能会导致应用程序服务器在资源耗尽时频繁重启。因为操作系统和服务器 应用程序通常具有资源的上限限制
根据docs
典型的Java应用程序操纵几种类型的资源,例如 文件,流,套接字和数据库连接。这些资源必须是 处理得非常谨慎,因为他们为他们获得了系统资源 因此,即使出现错误,您也需要确保它们被释放。
事实上,不正确的资源管理是导致失败的常见原因 生产应用程序,通常存在陷阱,即数据库连接 发生异常后仍然打开文件描述符 代码中的其他位置。这导致应用程序服务器频繁出现 资源耗尽时重启,因为操作系统和服务器 应用程序通常具有资源的上限。
try-with-resources在java 7中为厌恶密切语句的程序员引入的语句。
答案 2 :(得分:3)
简短回答 - 是的。首先,它是可怕的编码实践,就像生活中的每个其他领域一样,不能自行清理。另一方面,您无法预测操作系统是否会认识到java环境不再需要资源,并且您最终可能无法在没有强制重启的情况下释放文件/等等。
始终清理您打开的所有资源!
有关原始问题更新的更新 - 添加try / catch块以关闭所有打开的资源需要5秒钟,并且可以防止您花费5分钟重新启动计算机。做得对,总能节省时间。我父亲总是告诉我,真正懒惰的人第一次做对了,所以他们不必回来再做一次。我只是说不要偷懒而且做得对。写入一个catch块所花费的5秒钟将永远不会显着减慢写入过程...通过不写入而节省的5秒可能会大大减慢调试速度。