下载几个文件，然后同时暂停再继续概率出现从头开始下载

[hongbiangoal]

Before Issue

1. Please search on the Issues
2. Please search on the wiki
3. Please set FileDownloadLog.NEED_LOG=true and review the Logcat output from main process and :filedownloader process ( pay attention to Warn and Error level logcat)

Issue

1. What problem do you get?
2. Which version of FileDownloader are you using when you produce such problem?
3. How to reproduce such problem?
4. Do you set FileDownloadLog.NEED_LOG=true?
5. Could you please reproduce this problem and provide all main process and :filedownloader process logcat
6. Can you fix it by yourself and request PR, if not, what's problem do you get when you try to fix it

P.S. If you don't know how to get :filedownloader process, it's recommended to using pidcat to just filter all your application logcat, or define process.non-separate=true on filedownloader.properties

---

请在Issue前认真的跟进上面提到的建议，这样将可以极大的加快你遇到问题的处理。

[Jacksgong]

1. 如果使用的1.6.7之前的版本，存在低概率该问题，已经在1.6.7中修复。
2. 没有进行断点续传，不一定是FileDownloader的问题，有可能是服务端返回不支持，请进一步根据日志进行分析。

[hongbiangoal]

代码我大概看到这里有点疑惑
类FileDownloadManager的start方法里

if (model != null && (model.getStatus() == FileDownloadStatus.paused ||
            model.getStatus() == FileDownloadStatus.error) // FileDownloadRunnable invoke){
           // #isBreakpointAvailable to determine whether it is really invalid.
           。。。
}else{
if (model == null) {
                model = new FileDownloadModel();
            }
            model.setUrl(url);
            model.setPath(path, pathAsDirectory);
            model.setId(id);
            model.setSoFar(0);
            model.setTotal(0);
            model.setStatus(FileDownloadStatus.pending);
            model.setConnectionCount(1);
}

出问题时model.getStatus值时3(progress)

[Jacksgong]

@hongbiangoal 你用的哪个版本，1.6.6或之前的版本，确实有可能由于你提到的这里获取到3(process)导致断点续传失败。1.6.7中专门修复了这个问题。

[hongbiangoal]

ok 那我用最新的试试

[Jacksgong]

详细请参见: changelog-zh

[hongbiangoal]

试了下最新版本，还是有一种情况会导致从0开始下载
出问题时model.getStatus值时1(pending)

[Jacksgong]

@hongbiangoal 多谢提醒，其实这个状态我们在上层回调的时候有控制，但是确实在底层下载处理的时候，从某个版本开始，没有把pending的状态恢复。

我尽快修复下这个问题。

[Jacksgong]

该问题具体如下

1. 依然存在status为process导致无法断点续传问题

• 原因: 这个目前是线程高并发时，由于JMM在不同线程未及时更新，导致status在不同线程不一致，并且由于多个线程同时进行写，导致最终内容无法保证
• 解决方法: 使用AtomicInterger代替byte

2. 存在status为pending或者started导致无法断点续传

• 原因: pending在早期版本有处理，后面某个版本后便没有处理了，status虽然没有存储在数据库中，但是如果不重启进程，该值依然会影响
• 解决方法:: pending不再入库，并且如果是pending/started直接复用其上次进度

3. DownloadStatusCallback中的sendMessage可能消息变得无序

• 原因: 由于多个状态可能在极端的时间内进行更新，有时甚至可能小于1ms，因此Handler的队列无法保证其有序性
• 解决方法:: 为sendMessage加锁，为了保证最终结束的状态一致性；以及保证在结束状态刷新之前，结束整条派发线程。

4. DownloadLaunchRunnable#isAlive不够准确

• 原因: 由于在一个线程写入alive，另外一个线程读取alive，在极快的无序的进行不断写入，读取的过程中，即便alive是volatile但是依然可能alive写入完成，在不同线程表现不一致
• 解决方法:: 改为AtomicBoolean