关于Vue多线程的思考

在前端调用的时候，我们难免需要同一时刻向后端请求多组数据或是总是期待着是否存在一个独立的线程去处理一系列的数据。线程相应，资源的抢占这是前端较为麻烦的点。这里就来聊聊我在前端踩的坑。

首先是线程问题说到线程，我们可以发现前端确实不是单一线程进行事务处理的。前端准备发出axios请求时会新开一个独立的线程并且是该线程进入等待阶段，等待后端数据的返回。那么原先的线程会继续执行。（这里需要描述清楚一点，线程和进程。一般现在电脑都是多核CPU也就是电脑同时能进行多条线程的运算。曾经设想过，假设一个线程能独立进行运算处理指定的数据，不影响其他业务的流转，结果发现想多了。）实验证明前端如果使用了等待算法。

async sleep (millisecond){
      return new Promise(resolve => {
        setTimeout(()=>{
          resolve()
        },millisecond);
      })
    }

当等待时间比较长，数据量比较大的情况下，整体界面相当于完全卡死。

当时场景是使用锐浪进行打印机调用，锐浪在获取打印模板和打印数据的时候都是自己独立进行的。之前由于如果在上一个数据执行完之前，下一个数据源再次重新获取后，会导致该功能报错，所以补了一个延时。从而进行控制，避免应用报错。

这时候我有一个假设，其实游览器一个页面只开了一个进程进行整体数据的处理，虽然内部不同的线程会不停的创建关闭，但是一旦涉及到到等待之类的，整体都会被拖死。

Promise.all的应用。

主线程中我开了多个后端调用，我准备等全部后端调用完成后再将界面的锁定进行放开，但是发现主线程走完了，Promise.all后面在慢慢执行，其确实是等全部的请求都获取到了，但是其并不会将主线程卡住。感觉更像是开了一个新的线程。去等待所以HTTP请求的结束。

那么应对这种方式，那么会将下一步的处理一到Promise.all中。

setSampleOrder(model, reportSeqno) {
    let oneItem = webRequest
              .HttpPost('A',data)
              .then(res => {
              }).catch(error => {

              })    
 deanTempList.push(oneItem);
 oneItem = webRequest
              .HttpPost('B',data)
              .then(res => {
              }).catch(error => {

              })    
Promise.all(deanTempList).then((res) => {
              console.log("选项加载完成")
              this.getReportItemList()
            })
}