问题描写叙述：
在一个在线执行的java web系统中，会定时执行一个FTP上传的任务，结果有一天发现，文件正常生成后却没有上传。
问题初步分析：
1.查看日志文件
发现这个任务仅仅打印了開始进入FTP处理的日志，可是没有打印FTP处理完毕的日志。
从代码上看，FTP上传处理的代码异常保护都很的好，假设出现异常，就会进行打印，而日志文件里却没有相关的信息，甚是奇怪。怀疑是FTP过程问题，如对方FTPserver有什么问题导致，可是却找不到证据。
苦于无法窥探java执行系统内部信息，祭出杀手锏-jstack。
2.通过jstack分析
在执行系统上，通过jps命令（也能够通过其它方式，如ps）查看执行中的java程序的进程ID，使用jstack pid > jstack.log 将线程堆栈信息导出到jstack.log文件里，找到例如以下实用的信息。
通过代码确认，下方的UploadFtpTask确实就是我们的文件上传任务的运行代码。
通过堆栈信息看，线程状态为RUNNABLE,不是BLOCKED状态，说明不是由于锁导致线程堵塞，而是堵塞在了网络读取上。
<span style="font-size:14px;">"DefaultQuartzScheduler_Worker-5" prio=10 tid=0x00002aaaf4382801 nid=0x1874 runnable [0x000000004133b000..0x000000004133bda0]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
- locked <0x00002aaac3cdd061> (a java.io.InputStreamReader)
at sun.nio.cs.StreamDecoder.read0(StreamDecoder.java:107)
- locked <0x00002aaac3cdd061> (a java.io.InputStreamReader)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:93)
at java.io.InputStreamReader.read(InputStreamReader.java:151)
at it.sauronsoftware.ftp4j.NVTASCIIReader.readLine(NVTASCIIReader.java:105)
at it.sauronsoftware.ftp4j.FTPCommunicationChannel.read(FTPCommunicationChannel.java:142)
at it.sauronsoftware.ftp4j.FTPCommunicationChannel.readFTPReply(FTPCommunicationChannel.java:187)
at it.sauronsoftware.ftp4j.FTPClient.connect(FTPClient.java:1034)
- locked <0x00002aaac3cdd109> (a java.lang.Object)
at com.xx.FtpClientImpl.connect(FtpClientImpl.java:56)
at com.xx.UploadFtpTask.execute(UploadFtpTask.java:88)
at org.quartz.core.JobRunShell.run(JobRunShell.java:216)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)</span>
通过引用的jar包确认，这个FTP功能使用的开源包ftp4j来实现的，使用的版本号为1.5.1。
写个測试程序，看看FTP连接时的调用堆栈：
Socket.connect(SocketAddress) line: 469
Socket.<init>(SocketAddress, SocketAddress, boolean) line: 366
Socket.<init>(String, int) line: 180
DirectConnector.connect(String, int) line: 35
DirectConnector.connectForCommunicationChannel(String, int) line: 40
FTPClient.connect(String, int) line: 1024
FTPClient.connect(String) line: 991
Test.main(String[]) line: 19
而Socket 的469行是什么呢？
connect(endpoint, 0);
这个函数的定义为：public void connect(SocketAddress endpoint, int timeout) ，上面的调用相当于设置了timeout为0，那就意味着出现网络丢包或者对端服务有问题时，这个连接会无限制等待下去。这就杯具了。
再看看这个开源项目兴许是否对此问题做过改动呢？下载1.7.2版本号,再次測试，查看调用堆栈：
Socket.connect(SocketAddress, int) line: 490
DirectConnector(FTPConnector).tcpConnectForCommunicationChannel(String, int) line: 208
DirectConnector.connectForCommunicationChannel(String, int) line: 39
FTPClient.connect(String, int) line: 1036
FTPClient.connect(String) line: 1003
Test.main(String[]) line: 19
通过tcpConnectForCommunicationChannel去调用Socket的connect方法时，传入了超时时间，为10秒（10*1000）。这就引入了超时机制，假设出现上面问题时，就不会死等了。
总结：
1.jstack工具是定位在线执行java系统的利器，能够查看线程堆栈信息，这对于分析问题很重要，特别是在日志分析和代码分析无法确定问题时。
2.网络连接时，必须设置超时，不能无限制等待。发散一下，开发系统时，必须考虑各种异常情况。套用那句话，出来混，总是要还的。
转载请注明出处：http://blog.csdn.net/u014569459/article/details/38542949