最近、オンライン監視SFTP接続が頻繁にバーストし、システムを再起動することにより、接続数が迅速に低下し、システムが正常に戻ることができるようになります、最初の判断は、アプリケーションの接続が問題のために閉じていないことです。当初は、アプリケーション接続が閉じられていないため、スタックマネージャは、IDEのグローバル検索を介して調査し、SFTP接続はjschパッケージを使用し、確かにいくつかの関数ポイントは、SFTP接続を使用しているが閉じていない、または最終的にステートメントブロックに正常に閉じていません。その後、運用保守の精神が崩壊しそうなので、運用保守が率先してSFTP接続監視を書き、接続が5分以上アイドル状態になると、積極的に切断するようにしました。しかし、これは一時的な治療法であり、本当の理由はまだアプリケーションが適切に閉じていないに違いないので、真剣に手順をチェックし、最終的に犯人を発見しました。ここにサンプルコードがあります：
問題がわかりますか？私はこのプログラムを2回チェックしましたが、この問題を解決するのに3日かかりました。このコードを書いて、同僚は本当に才能があります！一見したところ、接続は確かに閉じられていますし、finally文のブロックでも閉じられています。その理由は、接続はforループの中で作成され、finally文の中で閉じられていますが、接続変数はループの中で再構築され置き換えられているため、閉じられるのは常に最後の接続だけだからです。さらに、これはエクセルの詳細をダウンロードする関数であり、大量のデータがある場合、1回の操作で接続が即座にバーストしてしまいます。解決策は、接続の作成部分をforループの先頭に持ってきて、接続を一度作成すれば何度でも使えるようにすることです。さらに、JDK 7+のtry-with-resources構文をご存じであれば、finallyブロックを省略し、try(...)で定義することができます。 try(...)の中で定義すれば、自動的に終了します。このjsch接続パッケージにはそれができません。 ソースコードを見てみましょう。com.jcraft.jsch：
com.jcraft.jsch.Channel：
この2つのクラスは、Runnableインターフェイスを実装しているだけで、java.lang.AutoCloseableインターフェイスを実装していませんので、try-with-resources自動クローズの原則に準拠していません。これまでのところ、オンラインSFTP接続は、最終的に問題が解決バーストされている、あなたは良い夜の睡眠を安心することができ、同時に、私はまた、同僚があまりにも素晴らしいと感じ、私は知識を得ることができます。
