手把手教你线程池配合CompletableFuture实现图片下载并压缩

刺骨的言语ヽ痛彻心扉 2022-10-09 13:27 177阅读 0赞

## 你知道的越多，不知道的就越多，业余的像一棵小草！ ##

成功路上并不拥挤，因为坚持的人不多。

## 编辑：业余草 ##

juejin.cn/post/6976454072685559822

## 推荐：https://www.xttblog.com/?p=5221 ##

## 前言 ##

继续更新，得空记录下之前写得一个需求，欢迎大家前来指教，轻喷????

> ❝
> 
> 需求 导出Excel：本身以为是一个简单得导出,但是每行得记录文件中有一列为图片url,需要下载所有记录行对应得图片，然后压缩整个文件夹。
> 
> ❞

![44d4702e02ad2884e68c8a573a2d73a1.png][]

这里只做步骤 4、5 的代码讲解描述，其它也没什么好说得，话不多说上代码。

## 实现思路 ##

多线程实现使用了**「线程池」**，Jdk1.8 并发包下的**」**

第一步：得到基础数值

// 线程数
    Integer threadNum = 10;
    // 每条线程需要处理的图片数  
    int dataNum = imageInfoVos.size() / threadNum;
    // 写入线程数
    List<Integer> threadS = new ArrayList<>();
    for(int i=0; i<threadNum; i++){
            threadS.add(i);
    }

首先我们保存了需要下载的图片的 Url 列表，多线程的方式下载我们需要保证每个线程下载的图片不会重复，因此我们需要根据规则来切割保存 Url 列表的集合，从而保证每个线程下载属于自己的任务,上代码 ：

// 接上文代码
     threadS.stream().map(item -> CompletableFuture.runAsync(() ->{
            List<Image> theadItem = imageInfoVos.subList(dataNum * item,(item+1)==threadNum?imageInfoVos.size():Math.min(dataNum * (item + 1 ), imageInfoVos.size()));
                    threadDownPic(theadItem,item,dirName);
        },threadPoolTaskExecutor)).collect(Collectors.toList()).forEach(item ->{
            try {
                item.get();
            }catch (Exception e){
                log.error("============  多线程down执行等待异常 msg:{} =============", e.getMessage());
            }
    });

这里进行拆分讲解

使用 CompletableFuture.runAsync 走异步方式，遍历 item

如 item=10，也就是线程数为 10,则直接执行 10 次(**「有线程池的前提下」**)

// 使用CompletableFuture.runAsync 走异步方式,遍历item
     // 如item=10,也就是线程数为10,则直接执行10次(有线程池的前提下)
     threadS.stream().map(item -> CompletableFuture.runAsync(() ->{

**「规则」**：根据item数值通过 sublist 从开始到结束，截取对应线程所需要下载的 Url列表。

> ❝
> 
> 例：dataNum 为每个线程需要完成的下载数如上文 dataNum 为 100 时 如：item=0 dataNum\* item(0) =0,Math.min(dataNum \* (item + 1 )=100 (item+1)==threadNum?imageInfoVos.size() 此次是为了保证最后一个线程处理最后不足的图片
> 
> ❞

根据如上规则即可得到每个线程需要下载的图片Url保证不会重复

// 根据item数值通过sublist 从开始到结束,截取对应线程所需要下载的Url列表
    // 例：dataNum为每个线程需要完成的下载数如上文 dataNum为100时
    // 如：item=0 dataNum* item(0) =0,Math.min(dataNum * (item + 1 )=100
    // 根据如上规则即可得到每个线程需要下载的图片Url保证不会重复
    // (item+1)==threadNum?imageInfoVos.size() 此次是为了保证最后一个线程处理最后不足的图片
    List<ImageInfoVo> theadItem = imageInfoVos.subList(dataNum * item,(item+1)==threadNum?imageInfoVos.size():Math.min(dataNum * (item + 1 ), imageInfoVos.size()));
    // theadItem:图片Url  item：所属下标  dirName：写入路径url
    threadDownPic(theadItem,item,dirName);

由于执行的异步方式，此处是为了线程池中所有线程都结束才能往下走，执行压缩文件步骤，这里提一嘴，如果没有手动赋予线程池，CompletableFuture 默认使用ForkJoinPool.commonPool，会根据电脑核心数来指定。

比如：我本机未指定就是 7 个线程，执行方法时，会执行完前面 7 个线程任务，才会继续创建 3 个线程继续执行后续未完成的。

threadS.stream().map(item -> CompletableFuture.runAsync(() ->{
        List<Image> theadItem = imageInfoVos.subList(dataNum * item,(item+1)==threadNum?imageInfoVos.size():Math.min(dataNum * (item + 1 ), imageInfoVos.size()));
                threadDownPic(theadItem,item,dirName);
    },threadPoolTaskExecutor)).collect(Collectors.toList()).forEach(item ->{
        try {
            item.get();
        }catch (Exception e){
            log.error("============  多线程down执行等待异常 msg:{} =============", e.getMessage());
        }
    });

## 实测 ##

主要代码也写完了，这种方式真的能提高效率吗？下面我贴几张测试图来说明

![a2b8a239866cefd9a70921343c1a61b8.png][]

多线程图片下载

其实这种方式并没有显著的提高效率，当然这是我本机环境测试的。

**「效率是由网速决定,而不是由本机 Cpu 和 io 决定，比如 10M 带宽，一个线程一个一个顺序下载,但速度是 10M，10 个线程,可能每个线程的速度是 1M,结果没有什么两样。相对于网速，多线程带来的 cpu 以及 io 节省的时间几乎可以忽略，瓶颈还是在网速。」**

**「接口优化点为：提高压缩效率可以不将图片保存到本地而直接压缩文件流」**

## 结尾 ##

我的同事，当然也包括一些网友，总感觉很多知识学习了没有应用的场景。本文从一个实践的真实项目场景出发，教大家使用上 CompletableFuture，线程池等知识点。如果你认为本文代码在实现方式上还有改进的地方，比如本文的线程池可以接合 CountdownLatch 使用等都可以讨论。

水文不易，欢迎大家参与讨论和指出不足的✌

![19cf18a24b8b262e7fee111c94ee66a5.png][]

[44d4702e02ad2884e68c8a573a2d73a1.png]: /images/20221005/9d132e14bb514813a0635a60b8c58d89.png
[a2b8a239866cefd9a70921343c1a61b8.png]: /images/20221005/2344baea6879432f80803026fb5a7c0b.png
[19cf18a24b8b262e7fee111c94ee66a5.png]: /images/20221005/289390d62ebc476aaf9676b439b93c91.png