我正在使用JSch连接到远程unix服务器的程序。我还使用jdbc和具有Apache Hadoop HDFS API的分布式文件系统连接到Hive数据库。当我看到它们可用时，我一直随意包含close（）方法，但使用try/catch/finally块时尝试关闭通道/连接的情况越来越令人沮丧。如果我不关闭渠道，流和远程连接等事情会发生什么？
将流，通道或连接打开的实际结果是什么？它是否会以负面方式影响远程机器？程序结束时所有流都会自动关闭吗？
将流，通道或连接打开的实际结果是什么？
至少它会消耗资源，直到这些端点被关闭，如果它们应该被垃圾收集，它们可能会或可能不会发生。这可能构成资源泄漏。在极端情况下，程序可能会耗尽可用资源（例如同时打开的文件数量）。
此外，对于输出，您写入此类接收器的数据可能会保持内部缓冲而不是实际被推送到预定目标。
它是否会以负面方式影响远程机器？
通常，远程服务的任何类型的持续连接都会引起远程端的系统资源。当连接完全关闭时，这些资源通常会被释放。如果它是完全关闭的而不是，那么这些资源可能会在不确定的时间内保持连接状态;细节取决于相关服务的性质和配置。
当程序结束时，所有的流都会自动关闭吗？
在低级意义上，是的。对于面向连接的网络流，这通常会导致网络层关闭被执行，远程端会看到。但是，如果有关于应用层关闭的任何相关意义，则不能指望执行该操作。对远程系统可能产生的影响又取决于相关服务的性质和配置。此外，如果缓冲输出处于待处理状态，则可能在底层系统资源关闭之前未写入缓冲输出。
但总体而言，当你说
有关于尝试使用一个try/catch/finally块
何时关闭通道/连接日益不满，我有一点同情。该模式是一致的，相当容易理解和实施。你认为它很乏味 - 也许它是 - 并没有给你许可来正确地跳过管理资源。大量的编程实践相当单调乏味。好的程序员处理所有这些，始终如一。这是工作的一部分。
作为一个说明，为了解决try/catch/finally块的挫败感，只要创建一个具有静态方法'public static void close（Closeable c）'的助手类，并且在那里执行try-catch-finally厌倦了每次写它。我认为@JohnBollinger是正确的，程序员必须始终处理它，这是一个好习惯。 – Orin
@john感谢您的反馈！我将不得不深入研究Hadoop如何通过Java API处理连接的文档。至于正确管理资源：我不是一个好的程序员，所以我不知道管理异常和资源的最佳做法。我的许多同事也没有这样做，所以我需要能够将信息传递给他们，这有助于他们了解在生产软件方面需要适当的资源管理。 – JitterbugChew
@JitterbugChew，如果你正在编写程序，那么你应该至少*渴望*成为一名优秀的程序员。回家的信息应该是这样的：即使这样做是单调乏味的，也要继续确保关闭可关闭的资源。 –
实际上存在一些限制。连接是一种资源。资源有限。您的应用程序可能会耗尽全部或部分内容而无需额外处理。
假设你从你的应用程序连接到serverX。 ServerX只能处理10个连接。如果您在第11次忘记关闭10次与serverX的连接，则可能无法连接。这当然是简化的，但它描述了不关闭连接的问题的性质。
让流，通道或连接处于打开状态的实际结果是什么？
您连接的系统仍在处理此连接，即使您的进程没有使用它。这意味着额外的内存，cpu，套接字和可能的其他资源仍然被分配。
它是否会以负面方式影响远程机器？
是的。远程机器可以拒绝下一个连接，或者可以减慢速度。
当程序结束时，所有的流都会自动关闭吗？
它取决于你合作的系统。在你的情况下，我会认为是的，但在一段时间后。
你有内存泄漏 – Javant
我习惯于在本地有内存泄漏，我知道它们在进程终止时被解决。对于远程连接，情况同样如此吗？我担心在远程主机上可能产生的影响。 – JitterbugChew