多线程下载由来已久,如 FlashGet、NetAnts 等工具,它们都是依懒于 HTTP 协议的支持(Range 字段指定请求内容范围),首先能读取出请求内容 (即欲下载的文件) 的大小,划分出若干区块,把区块分段分发给每个线程去下载,线程从本段起始处下载数据及至段尾,多个线程下载的内容最终会写入到同一个文件中。
只研究有用的,工作中的需求:要把多个任务分派给多个线程去执行,这其中就会有一个任务列表指派到线程的策略思考:已知:1. 一个待执行的任务列表,2. 指定要启动的线程数;问题是:每个线程实际要执行哪些任务。
策略是:任务列表连续按线程数分段,先保证每线程平均能分配到的任务数,余下的任务从前至后依次附加到线程中--只是数量上,实际每个线程执行的任务都还是连续的。如果出现那种僧多(线程) 粥(任务) 少的情况,实际启动的线程数就等于任务数,一挑一。这里只实现了每个线程各扫自家门前雪,动作快的完成后眼见别的线程再累都是爱莫能助。
实现及演示代码如下:由三个类实现,写在了一个 java 文件中:TaskDistributor 为任务分发器,Task 为待执行的任务,WorkThread 为自定的工作线程。代码中运用了命令模式,如若能配以监听器,用上观察者模式来控制 UI 显示就更绝妙不过了,就能实现像下载中的区块着色跳跃的动感了,在此定义下一步的着眼点了。
代码中有较为详细的注释,看这些注释和执行结果就很容易理解的。main() 是测试方法
执行结果如下,注意观察每个线程分配到的任务数量及区间。直到所有的线程完成了所分配到的任务后程序结束:
线程 0 的任务数:22 区间[0,21]
线程 1 的任务数:22 区间[22,43]
线程 2 的任务数:22 区间[44,65]
线程 3 的任务数:21 区间[66,86]
线程 4 的任务数:21 区间[87,107]
实际要启动的工作线程数:5
当前线程 ID 是:Thread-0 | 任务 ID 是:0
当前线程 ID 是:Thread-1 | 任务 ID 是:22
当前线程 ID 是:Thread-2 | 任务 ID 是:44
当前线程 ID 是:Thread-3 | 任务 ID 是:66
当前线程 ID 是:Thread-4 | 任务 ID 是:87
当前线程 ID 是:Thread-0 | 任务 ID 是:1
当前线程 ID 是:Thread-1 | 任务 ID 是:23
当前线程 ID 是:Thread-2 | 任务 ID 是:45
...........................................................................
上面坦白来只算是基本功夫,贴出来还真见笑了。还有更为复杂的功能:
像多线程的下载工具的确更充分利用了网络资源,而且像 FlashGet、NetAnts 都实现了:假如某个线程下载完了欲先所分配段的内容之后,会帮其他线程下载未完成数据,直到任务完成;或某一下载线程的未完成段区间已经很小了,用不着别人来帮忙时,这就涉及到任务的进一步分配。再如,以上两个工具都能动态增加、减小或中止线程,越说越复杂了,它们原本比这复杂多了,这些实现可能定义各种队列来实现,如未完成任务队列、下载中任务队列和已完成队列。难以细究了。
[版权声明]本站内文章,如未标注 [转载],均系原创或翻译之作,本人 Unmi 保留一切权利。本站原创及译作未经本人许可,不得用于商业用途及传统媒体。网络媒体可随意转载,或以此为基础进行演译,但务必以链接形式注明原始出处和作者信息,否则属于侵权行为。另对本站转载他处文章,俱有说明,如有侵权请联系本人,本人将会在第一时间删除侵权文章。及此说明,重之之重。