多线程分段下载文件时，为什么不下载到同一个大文件中？而是要分别下载到单独的文件然后再合并。

[lsk569937453]

https://gist.github.com/lsk569937453/e0496754cf3ebe740a33a7759516015e

我自己写了个 demo ，假设开 50 个线程下载，每个线程下载时间为 10s 钟，可以看到最后写入文件的时间才 1s 不到。

所以下载文件时，瓶颈是网络 IO 吧，操作文件 IO 的时间可以忽略不计了。所以是不是下载到一个文件中更优？

[monkeyWie]

@lovezhangdada 你指的是哪个实现原理？如果是指 http 下载的话基本是差不多，也就是我说的预分配 + seek 写，当然 aria2 是用的多线程 gopeed 用的多协程所以更省资源

[augustheart]

@shuax 很难说。大部分情况下，多线程不会消失，只会转移。从调用者来看是单线程没啥问题

[monkeyWie]

@shuax 这还真不是暴论，现代化的网络编程都是支持单线程高性能网络开发的(epoll 、eventloop 、协程)的，只能说现在载器还在用多线程技术的都是老古董

[AsAsSaSa]

@huixia0010 直接持续追加就行，直播流只需要 1x 速度一般没多 TCP 链接的需求，而且你获取的基本一直是最末尾的数据，简单追加即可，真想多链接，每个 m4s 的请求带 content-length 就可以确定下一个分片该保存的开始位置。

[monkeyWie]

@cheng6563 对的，但是不全对，windows 在没有管理员权限下也可以预分配只是比较慢，因为要做零填充，如果管理员模式就可以一瞬间分配好不管多大的容量

[Anarchy]

这个谈不上菜吧，这类代码很多场景只考虑带宽能不能跑满不在意文件 io 的，能快速写完代码就是最大优点了。

[augustheart]

@monkeyWie 你分析的方向错了。下载软件是为了下载速度更快，而不是省资源。多线程下载是在历史中卷速度卷出来的。而在这个过程中，select 什么的东西从一开始就存在，这是 socket 编程的基础。

[TrembleBeforeMe]

是的，所以我虽然买了 IDM 也不再使用了，改为用 imfile+aria2 下载辅助插件

[monkeyWie]

@augustheart #47 有没有可能既省了资源，下载速度也没落下呢，新的编程技术出来就是为了解决历史的糟粕的，开 32 个线程并发下载 cpu 干冒烟了，然而开 256 个协程并发下载 cpu 表示毫无压力，并发数还高速度还更快

[augustheart]

@monkeyWie 有没有可能 io 密集型的玩意开上 100 个 cpu 也谈笑风生呢？

[monkeyWie]

@augustheart #50 那你有没有听说过 io 密集的时候并发高了一样能把 cpu 打挂，当然我这里指的是多线程+IO 这种古老的东西，然后如果你还要继续反驳的话就是你说的对

[augustheart]

@monkeyWie 会的，当年万兆网卡直接把 cpu 干爆，然后？算了，我先来，你是对的

[Belmode]

chrome 下载不就是写到一个.downloading 临时文件里的吗。

[yidinghe]

这类策略都是因为受到硬件环境限制而做出的。比如你可能觉得“下载文件时，瓶颈是网络 IO 吧”，其实对机械硬盘和 U 盘来说，瓶颈就在文件系统 IO 。

所以对于多线程下载，一个应用采取何种策略，看作者愿意考虑多少场景。不要简单地看到就说作者菜。甚至还有的人会说“现在还要什么多线程下载”，这种人也是接触的场景比较少。当然我不知道你针对的是哪个应用，还是说你自己打算写一个。

[yidinghe]

@Belmode Chrome 是单线程

[Ashe007]

@kenvix 文件上传下载，应该是网络-->内存-->磁盘这一流程吧？我做上传的时候就是采用的分段上传，因此认为整个上传会导致其整个 size 占据内存空间

[kenvix]

@Ashe007 #56 .......你要不学习下流的使用？

[kenvix]

@Ashe007 #56 我看你似乎用 spring ，那也不应该像很多 php 用户不知道流的样子，常规的实现流式实现都只占用 buffer （例如 512KB ）大小的内存

[augustheart]

@yidinghe 我记得有多线程模式了（？）

[augustheart]

@yidinghe 我不记得哪儿看帖有人说的。我个人很多年都是火狐了