Jit*_*hew 2 java connection channel stream
我正在开发一个使用 JSch 连接到远程 unix 服务器的程序。我还连接到带有 jdbc 的 Hive 数据库和带有 Apache Hadoop HDFS API 的分布式文件系统。当我看到 close() 方法可用时，我一直在随意包含它们，但是在使用 try/catch/finally 块时尝试关闭通道/连接越来越令人沮丧。
保持流、通道或连接打开的实际后果是什么？它是否以负面方式影响远程机器？程序结束时所有流是否自动关闭？
保持流、通道或连接打开的实际后果是什么？
至少在这些端点关闭之前它会消耗资源，如果它们应该被垃圾收集，这可能会也可能不会发生。这可能构成资源泄漏。在极端情况下，程序可能会耗尽可用的资源（例如，同时打开的文件数）。
此外，对于输出，您写入此类接收器的数据可能会在内部保持缓冲状态，而不是实际推送到预期目的地。
它是否以负面方式影响远程机器？
通常，与远程服务的任何类型的持久连接都会占用远程端的系统资源。当连接完全关闭时，这些资源通常会被释放。如果它没有完全关闭，那么这些资源可能会在不确定的时间内保持提交给连接；细节取决于所涉及服务的性质和配置。
程序结束时所有流是否自动关闭？
从低层次的意义上来说，是的。对于面向连接的网络流，这通常会导致执行远程端将看到的网络层关闭。但是，如果有任何应用层关闭的相关意义，您就不能指望它会被执行。对远程系统可能产生的影响同样取决于所涉及服务的性质和配置。此外，如果您有缓冲输出挂起，它可能不会在底层系统资源关闭之前写入。
然而，总的来说，当你说
在使用 try/catch/finally 块时尝试关闭通道/连接越来越令人沮丧
，我有点同情。该模式是一致的，并且相当容易理解和实现。您认为它很乏味——也许确实如此——并没有给您正确跳过资源管理的许可。大量的编程实践相当单调。优秀的程序员能够始终如一地出色地处理所有这些问题。这是工作的一部分。