最近线上监控 SFTP 连接频繁爆表，通过重启某个系统，连接数迅速下降，系统就能恢复正常，初步判断是应用程序连接未关闭的问题导致的。
LZ通过 IDE 全局搜索排查，SFTP 连接使用了 jsch 包，确实有一些功能点使用了SFTP 连接而未关闭的情况，或者不在 finally 语句块中正常关闭。
整改上线后，SFTP 还是爆表……
事后运维心态都要崩了，运维主动写了个 SFTP 连接监控，当连接超过 5 分钟空闲时就主动断开。
但这只是临时的处理，真正的原因肯定还是应用程序没有正常关闭导致的，于是再认真排查下程序，终于找出了元凶。。
下面是示例代码：
Session session =null;
ChannelSftp channel =null;
try{
for(...){
...
//创建会话
JSch jsch =newJSch();
jsch.getSession(host, username);
session = jsch.getSession(username, host, port);
session.setPassword(password);
session.connect();
//创建sftp连接
channel = session.openChannel("sftp");
channel.connect();
...
}
}catch(...){
...
}finally{
if(null!= channel && channel.isConnected()) {
channel.disconnect();
}
if(null!= session && session.isConnected()) {
session.disconnect();
}
}
大家都看出问题了吗？
这程序我检查了 2 遍，排查了 3 天才解决了这个问题。
写出这代码，同事真是个人才啊！！！
乍一看，连接确实是关闭了啊，也确实是在 finally 语句块关闭，为什么还会有问题？
原因就是在该死的 for 循环中创建连接的，虽然在 finally 中进行了关闭，但是连接变量在循环中进行重建和替换，所以关闭的永远只是最后一个连接。
而且，这还是个下载 Excel 明细的功能，数据很多的时候，一个操作就能导致连接瞬间爆表。
解决方案肯定是要把创建连接的部分拿到 for 循环前面去，连接创建一次就好了，可以反复使用。
另外，知道 JDK 7+ 中的 try-with-resources 语法的朋友可能会问，可以省略 finally 语句块吧，可以直接在 try(...) 中定义，它会自动关闭。
这个 jsch 连接包还真不行，我们来看它的源码吧，不然又是一个坑你没商量的坑。
com.jcraft.jsch.Session：
com.jcraft.jsch.Channel：
这两个类只实现了 Runnable 接口，没有实现 java.lang.AutoCloseable 接口，所以，它并不符合 try-with-resources 自动关闭的原则。
至此，线上 SFTP 连接爆表的问题终于解决了，可以安心睡个好觉了，同时，我也感觉我们的同事太牛逼了，又让我涨知识了。
大家引以为戒吧，也欢迎转发！
推荐学习：
网友评论