多线程断点续传实践

请教二个问题
            // 得到content的长度  
            contentLength = con.getContentLength();  
1、上面这个长度和实际文件的长度是完全一致的吗？会不会有出入
2、有的网站好像不支持断点续传，怎样判断一个下载地址是否支持断点续传？

1、楼主辛苦了
2、让我们没有接触过这方面的人有所了解
3、代码仍存在一定的问题，希望下次您有空发个完善一点的上来让我们学习学习
4、DownloadTask要重构

都控制10行，是不是太小了？如果代码多，那岂不是要分成很多个方法？

  要根据业务来定的··一个方法最好别超过30行，反正原来一个方法里写的分到两个方法里去，绝对不会比在一个方法里快。

apache mina, jpos的源代码也不是说所有的函数都很小。
但是楼主确实应该抽象、封装下比较好。

for (;;) {
try {
// 打开URLConnection
con = (HttpURLConnection) task.url.openConnection();

~~~~~~~~~~~~~~~~
以上这里为什么要用无限循环？合理吗？

for (;;) {
   try {
// 打开URLConnection
con = (HttpURLConnection) task.url.openConnection();
这里怎么会用无线循环来做啊？这么做不会有问题吗？

  文章读完，提点小意见。
  知识归类不够！

  特别是已有规范这方面的东西，需要向大家说明。
 
  你写的是分段多线程下载
1.下载文件如何分段
   (例如：针对 http 协议，协议提供了 range 功能。
    那么如果使用ftp是否也有 range 了？)
2.如果对待分段后的文件流
  2.1 多线程分段策略
  2.2 超时处理策略
     （例如：http超时设置，捕获http超时信息，做出处理
       那么ftp是否是相似的处理方式）
3.分段后的文件流如何合并成一个文件

将每个功能点罗列，并告知哪些是已经有的，哪些是我们能做的，你这篇文章会易懂.

这样重要的代码


就不会被人忽视了。别人理解的你代码的重心就更好分配了。

谢谢分享.

有个疑问.多线程条件下,RandomAccessFile是线程安全的吗?

方法太长。。。。分解重构。。