《面試篇》Http協(xié)議 中，我們有提到大文件下載和斷點(diǎn)續(xù)傳，本篇我們就來(lái)開(kāi)發(fā)一個(gè)多線程文件下載器，最后我們用這個(gè)多線程下載器來(lái)突破下載的限速。

兄弟們看到這個(gè)標(biāo)題可能會(huì)覺(jué)得是個(gè)標(biāo)題黨，為了解決疑慮，我們先來(lái)看下最終的測(cè)試結(jié)果：

測(cè)試云盤(pán)下載的文件 46M，自己本地最大下載速度 2M

1. 單線程下載，總耗時(shí): 603s

2. 多線程下載，50個(gè)線程，總耗時(shí)：13s

測(cè)試結(jié)果，「提速46倍」，我還是太謙虛了，只說(shuō)提速30倍，此處我們覺(jué)得應(yīng)該有掌聲（我聽(tīng)不到，還是點(diǎn)贊實(shí)在）

?

源碼地址：https://gitee.com/silently9527/fast-download

喜歡請(qǐng)記得star哦

?

HTTP協(xié)議Range請(qǐng)求頭

Range主要是針對(duì)只需要獲取部分資源的范圍請(qǐng)求，通過(guò)指定Range即可告知服務(wù)器資源的指定范圍。格式: Range: bytes=start-end

比如：獲取字節(jié)范圍 5001-10000

Range: bytes=5001-10000

也可以指定開(kāi)始位置不指定結(jié)束位置，表示獲取開(kāi)始位置之后的全部數(shù)據(jù)

Range: bytes=5001-

服務(wù)器接收到帶有Range的請(qǐng)求，會(huì)在處理請(qǐng)求之后返回狀態(tài)碼為206 Partial Content的響應(yīng)。

基于Range的特性，我們就可以實(shí)現(xiàn)文件的多線程下載，文件的斷點(diǎn)續(xù)傳

準(zhǔn)備工作

本文我們使用的SpringMVC中的RestTemplate；由于云盤(pán)的鏈接是Https，所以我們需要設(shè)置RestTemplate繞過(guò)證書(shū)驗(yàn)證

1. pom.xml

pom.xml

1. 編寫(xiě)RestTemplate的構(gòu)造器，以及繞過(guò)https的證書(shū)驗(yàn)證

RestTemplateBuilder

1. 在下載的過(guò)程中，我們需要知道當(dāng)前下載的速度是多少，所以需要定義一個(gè)顯示下載速度的接口

DisplayDownloadSpeed

因?yàn)橛?jì)算下載速度，我們需要知道每秒傳輸?shù)淖止?jié)數(shù)是多少，為了監(jiān)控傳輸數(shù)據(jù)的過(guò)程，我們需要了解SpringMVC中的接口ResponseExtractor

ResponseExtractor

該接口只有一個(gè)方法，當(dāng)客戶端和服務(wù)器端連接建立之后，會(huì)調(diào)用這個(gè)方法，我們可以在這個(gè)方法中監(jiān)控下載的速度。

1. DisplayDownloadSpeed接口的抽象實(shí)現(xiàn) AbstractDisplayDownloadSpeedResponseExtractor

AbstractDisplayDownloadSpeedResponseExtractor

1. 整個(gè)項(xiàng)目主要涉及到的類圖

簡(jiǎn)單的文件下載器

這里使用的是restTemplate調(diào)用execute, 先文件獲取到字節(jié)數(shù)組, 再將字節(jié)數(shù)組直接寫(xiě)到目標(biāo)文件。

這里我們需要注意的點(diǎn)是: 這種方式會(huì)將文件的字節(jié)數(shù)組全部放入內(nèi)存中, 及其消耗資源；我們來(lái)看看如何實(shí)現(xiàn)。

1. 創(chuàng)建ByteArrayResponseExtractor類繼承AbstractDisplayDownloadSpeedResponseExtractor

ByteArrayResponseExtractor

1. 調(diào)用restTemplate.execute執(zhí)行下載，保存字節(jié)數(shù)據(jù)到文件中

1. 測(cè)試下載819M的idea

執(zhí)行一段時(shí)間之后，我們可以看到內(nèi)存已經(jīng)使用了800M左右，所以這種方式只能使用于小文件的下載，如果我們下載幾G的大文件，內(nèi)存肯定是不夠用的。至于下載時(shí)間，因?yàn)槲募笠矝](méi)有等下載完成就結(jié)束了程序。

單線程大文件下載

上面的方式只能下載小的文件，那大文件的下載我們?cè)撚檬裁捶绞侥?？我們可以把流輸出到文件而不是?nèi)存中。接下來(lái)我們來(lái)實(shí)現(xiàn)我們大文件的下載。

1. 創(chuàng)建FileResponseExtractor類繼承AbstractDisplayDownloadSpeedResponseExtractor，把流輸出到文件中

1. 文件下載器，先把流輸出到臨時(shí)下載文件（xxxxx.download），下載完成后在重命名文件

1. 測(cè)試下載819M的idea

執(zhí)行一段時(shí)間之后，我們?cè)倏纯聪聝?nèi)存的使用情況，發(fā)現(xiàn)這種方式內(nèi)存消耗較少，效果比較理想，下載時(shí)間：199s

多線程文件下載

如果服務(wù)器不限速的話，通常能夠把自己本地的帶寬給跑滿，那么使用單線程下載就夠了，但是如果遇到服務(wù)器限速，下載速度遠(yuǎn)小于自己本地的帶寬，那么可以考慮使用多線程下載。多線程我們使用CompletableFuture（可以參考之前的文章 《CompletableFuture讓你的代碼免受阻塞之苦》）。

實(shí)現(xiàn)多線程文件下載的基本流程：

1. 首先我們通過(guò)Http協(xié)議的Head方法獲取到文件的總大小
2. 然后根據(jù)設(shè)置的線程數(shù)均分文件的大小，計(jì)算每個(gè)線程的下載的字節(jié)數(shù)據(jù)開(kāi)始位置和結(jié)束位置
3. 開(kāi)啟線程，設(shè)置HTTP請(qǐng)求頭Range信息，開(kāi)始下載數(shù)據(jù)到臨時(shí)文件
4. 下載完成后把每個(gè)線程下載完成的臨時(shí)文件合并成一個(gè)文件

完成代碼如下：

1. 開(kāi)啟30個(gè)線程測(cè)試下載819M的idea

從執(zhí)行的結(jié)果上來(lái)看，因?yàn)殚_(kāi)啟了30個(gè)線程同時(shí)在下載，內(nèi)存的占用要比單線程消耗的多，但是也在接受范圍內(nèi)，下載時(shí)間：81s，速度提升2.5倍，這是因?yàn)閕dea的下載服務(wù)器沒(méi)有限速，本次多線程速度的提升僅僅是在充分的壓榨本地的帶寬，所以提示的幅度不大。

單線程下載和對(duì)線程下載對(duì)比測(cè)試

因?yàn)樵票P(pán)對(duì)單個(gè)線程的下載速度做了限制，大概是在100kb，所以我們使用云盤(pán)的下載鏈接，來(lái)測(cè)試多線程和單線程的下載速度。

1. 測(cè)試云盤(pán)中 46M 的文件的下載速度，自己本地最大下載速度 2M

2. 獲取文件的下載地址

?

注意：從瀏覽器中獲取的鏈接需要先使用URLDecode解碼，否則下載會(huì)失敗，并且云盤(pán)文件的下載鏈接是有時(shí)效性的，過(guò)期后就不能在下載，需要重新生成下載鏈接

?

測(cè)試單線程下載文件

執(zhí)行的結(jié)果可以看出，云盤(pán)對(duì)單線程的下載限速真的是喪心病狂， 46M的文件下載需要耗時(shí)：600s

測(cè)試多線程下載文件

為了充分的壓榨網(wǎng)速，找出最合適的線程數(shù)，所以測(cè)試了不同線程數(shù)的下載速度

從測(cè)試的結(jié)果上來(lái)看，對(duì)于自己的運(yùn)行環(huán)境把線程數(shù)設(shè)置在30個(gè)左右比較合適