我正在使用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