JavaScript for 循环机制

写在前面

　　昨天把以前写的一个代码改了

　　原因是因为发现 Promise 的异步处理竟然没有效果

　　我不知道为什么会出现这种情况

　　于是去问大佬，人家说要用 async await

　　在此之前我试过很多东西以为是 for 循环机制的问题 ( 有待商榷 // 斜眼笑 // ）

　　但是研究了一会儿无果

　　今天弄了之后发现万变不离其宗

　　这是 js 单线程的机制问题

　　( 这篇随笔是我自己对知识内化的一个过程有些地方是我自己想的可能不对误人子弟希望有缘人辩证地看）

首先一段代码

 1  for (let i = 0; i < 5; i++) {
 2                     let timer = new Promise(function (resolve, reject) {
 3                         setTimeout(() => {
 4                             resolve(i)
 5                         }, Math.random() * 10000)
 6                     })
 7 
 8                     timer.then((data) => {
 9                         console.log(data);
10                     })
11                 }

　　运行一下，你会发现，本来想到的是同步处理的方式 0，1，2，3，4，变成了随机输出，

　　" 是呀，不是应该每一次 timer 中的 resolve 是在 setTimeout 时延结束了才会 resolve的吗，然后才触发 then 的 "

　　" 所以为什么会出现这种情况呢？”

　　看似我们的 promise 失去效果了但是其实不是这是因为我们没有深刻理解 js 的执行顺序（加上这里有一个 for 循环）

　　如果运行出来，你清楚怎么回事，那么应该没有什么问题（当然我是一个小白 ... 下面只是说一下我查阅资料并自己研究之后的结果 )

JS引擎的机制（自我理解版本）

　　其实解决 Promise 失效的问题的话，用 async await 就好了

　　如果不想探究请参考我那天写的随笔

　　https://www.cnblogs.com/WaterMealone/p/14418421.html

　　但是 为什么 呢？

　　我准备探究一下这个问题

　　要说 async 和 await 的话，我们不得不说先说 Promise 、

　　说到 Promise 又要扯到 js 的执行顺序 Event Loop

　　......

　　话说回来我先自己复习一下 Event loop ( 下面的说法酌情看我觉得可能是错的）

　　比如如下代码

　　有些时候，对于 js引擎不太熟悉的朋友就会觉得可能就是一直按照顺序打出

　　但是结果是这个（ undefined 应该是没有返回值参考 eval( ) ）

　　其实在执行的时候，有三个东西，( 有些地方比较抽象分成了宏任务 macro-task 和微任务 mirco-task , 还有各自的 event queue )

　　一个是调用栈 call back stack

　　第二个是消息队列 message queue

　　第三个是微任务队列 microtask queue

　　具体参考如下视频

　　https://www.bilibili.com/video/BV1kf4y1U7Ln

　　下面是我的想法如果以后看了相关资料如果有错会更正

　　针对上面的代码：

　　console.log() 是同步任务应该是属于调用栈

　　setTimeout() 是异步任务应该是属于消息队列

　　for 循环是依次执行的

　　当第一次循环中

　　根据代码的顺序 setTimeout 进入消息队列（看 setTimeout 的时间延迟&&栈空才将代码放入调用栈）

　　然后 console.log 被压入调用栈并执行

　　（也就是先在主线程中进行同步任务，异步任务 ( 函数 ) 在 Event table 中被注册并且自己的时延结束然后才放到 Event queue 等到主线程的同步任务处理完后才在队列里面的读取对应的函数）

　　这里我的想法就是虽然现在的栈被执行空了之后，本应该执行消息队列的代码，但是因为最小时延为4ms

　　（ setTimeout ( fn ,0 ) 的含义是指定某个任务在主线程最早可得的空闲时间执行，意思是不用等待多少秒了，只要主线程内的同步任务执行完毕，栈为空，马上就执行）

　 紧接着 for 的第二次循环也到了调用栈不为空由此压入了console.log() 如此反复

　　（也有可能是 for循环相当于一次次代码的累积顺次执行）

　　当 i = 4 时

　　这个时候，console.log 马上就要执行完了

　　栈为空 按顺序执行 setTimeout 中的代码

　　setTimeout 中的代码被压入调用栈中开始执行

　　综上，我们得到的是

　　当然这里 setTimeout 的执行时间几乎是同一时刻，这里我认为是因为执行的时间并没有多长

　　那么这几个语句几乎就只差没少的ms 在视觉层面上就像是一瞬间输出 0 1 2 3 4

　　所以我这样改了一下代码

　这个的效果就是最先打出来 5 个 out loop

　　然后等待 1 秒钟

　　0 - 4 依次从控制台输出出来

　简单的自问自答结束了 （我不知道这样的想法有没有错但是现在在没有其他资料的情况下这个解释能适合我）

　　但是，如果我们想要按照顺序来弄（同步操作）

　　我们应该怎么做呢

　　这里我首选的想法就是 Promise （但是有些时候会不尽人意）

Promise

　　Promise 简单来说就是一个承诺，这个承诺指的是，Promise 实例里面的代码做完了 ( resolve() ,或者是 reject( ) 传出参数 ) 之后才能继续 ( then( ) )

　　（简单理解一下，但是有些情况下并不是这样的）

　　具体我之前写了一篇随笔

　　可以将就看一下

　　https://www.cnblogs.com/WaterMealone/p/14396590.html

　　然后如果看了我之前的随笔还是不明白的话，可以再去看看其他大佬的分析

　　然后 Promise 最好用的结构应该是套用在一个 funtion 里面再去调用 ( 这样之后可以传递参数 )

　　这里我并没有这样做...

　　我们可以将原来的代码改成这样

　　然后我们的输出就变成了这样（ Promise 的pending 状态表示此刻正在处理应该是当 for 循环调用 timer() 时，return 的那个 Promise ）

　　这里省略了then异步操作的流程，因为那样讲的话太过臃肿了

　　这里的执行过程应该是 timer 进入了微任务队列，当我们栈里面为空的时候，才执行微任务队列里的任务

　　然后根据 setTimeout() 的时间延迟把message queue 队列中的 setTimeout ()放到栈中执行

　　因为有了resolved() 返回的参数 then 得以执行（这里 setTimeout 的时间延迟都是一样的所以是几乎一下子顺序输出 // 有一些处理时间，但是应该不是很大的时间间隙 // ）

　　所以输出了上面按序输出的结果

解释最开头的代码 　　

　　好了看了那么多之后，我相信大家对于这个执行流程应该有了一个简单的认识

　　如果现在有缘人看到这里没有被我语无伦次的文章绕昏了的话

　　我相信你现在自己也能推出为什么开头的代码会是这个样子

　　其实我开头的那段代码其实是在模拟一个 fileReader.onload 的操作，因为 onload 钩子函数是在执行完load之后执行的

　　所以这一段时间是随着文件的性质决定的

　　模拟的这个代码如图

　　那么为什么会造成这样的情况呢，其实就是因为执行时间的不同

　　再回顾一下最前面的问题代码

　　这个的执行顺序应该是这个样子的，这次我们也同样省略一下 then

　　其实前面的处理过程和之前的差不多，最后的一部分差了

　　前面无非也是

　　第一次循环 timer_1 进入微任务队列，然后栈空 timer_1 进入栈... timer_1中的 setTimeout_1 进入消息队列等待栈空&&时延结束进行调入栈

　　第二次循环 timer_2 进入微任务队列，然后栈空 timer_2 进入栈... timer_2中的 setTimeout_2 进入消息队列 ( 此时可能setTimeout_1 执行也可能 setTimeout_1 和 setTimeout_2 都存在 ) 等待栈空&&时延结束进行调入栈

　　....

　　我们的 message queue 里面的 setTimeout 的时延并不是一样的，导致了调入栈中的顺序不同 ( 可能后进入队列的先调用然后处理就先给 then 了）

　　那么我们的解决方法是什么呢？

解决方法

　　 async await

　　现在目前对于这种 ”队列情况“ 我想到最简单的方法就是 await 了

　　（当然可以写个递归函数但是太麻烦了 // 为什么写递归呢可以接着看 // ）

　　在一篇大佬介绍 async await 的文章中，我找到了这个

　　https://segmentfault.com/a/1190000007535316

　　我们需要阻塞，不然这些个代码这是会按照时延给调到栈里面执行时延少的就先给执行了

　　于是我们这样开始改代码

 1 for (let i = 0; i < 5; i++) {
 2                     let timer = new Promise(function (resolve, reject) {
 3                         setTimeout(() => {
 4                             resolve(i)
 5                         }, Math.random() * 10000)
 6                     })
 7                     testTimer();
 8                     async function testTimer() {
 9                         let num = await timer;
10                         console.log(num);
11                     }
12 
13                 }

View Code

　　哦豁为什么还是错的呢？

　　其实这里

　　唯一合理的解释就是 for 循环中对于循环变量的操作比如 i 的自增也是同步操作

　　前面的操作中不明显，虽然前面只是缺了这个条件，但是仔细想一下前面的理论也成立（只是省略了 for 循环中的循环变量的操作）

　　我现在才意识到这个问题

　所以只有在 await 将我们的循环变量 i 的自增进行阻塞才能真正的阻塞后面的操作

　　从而实现同步操作

 1 function timer(i) {
 2                     return new Promise(function (resolve, reject) {
 3                         setTimeout(() => {
 4                             resolve(i)
 5                         }, Math.random() * 10000)
 6                     })
 7                 }
 8                 testTimer();
 9                 function testTimer() {
10                     for (let i = 0; i < 5; i++) {
11                         let num = await timer(i);
12                         console.log(num);
13                     }
14                 }