使用异步/等待foreach循环
在 foreach 循环中,使用 async
/是否有任何问题?我正在尝试在每个文件的内容上循环浏览一系列文件和
等待。
import fs from 'fs-promise'
async function printFiles () {
const files = await getFilePaths() // Assume this works fine
files.forEach(async (file) => {
const contents = await fs.readFile(file, 'utf8')
console.log(contents)
})
}
printFiles()
此代码确实有效,但是这可能会出现问题吗?我有人告诉我,您不应该在这样的高阶函数中使用 async
/等待
,所以我只想问是否有任何问题与此。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(30)
当然,代码确实有效,但是我敢肯定,它不会执行您期望的事情。它只是启动了多个异步调用,但是
printfiles
函数在此之后立即返回。按顺序读取,
如果您想按顺序读取文件,确实不能使用
foreach
。只需使用现代来取...
循环,其中等待
就可以按预期工作:阅读
如果您想并行读取文件,则并行 ,您不能确实使用 确实使用。每个
async
回调函数呼叫确实会返回承诺,但是您将它们扔掉而不是等待它们。只需使用MAP
,您就可以等待您将通过Promise.all
:Sure the code does work, but I'm pretty sure it doesn't do what you expect it to do. It just fires off multiple asynchronous calls, but the
printFiles
function does immediately return after that.Reading in sequence
If you want to read the files in sequence, you cannot use
forEach
indeed. Just use a modernfor … of
loop instead, in whichawait
will work as expected:Reading in parallel
If you want to read the files in parallel, you cannot use
forEach
indeed. Each of theasync
callback function calls does return a promise, but you're throwing them away instead of awaiting them. Just usemap
instead, and you can await the array of promises that you'll get withPromise.all
:借助ES2018,您可以大大简化上述所有答案:
参见规格:
简化:
2018-09-10:这个答案最近引起了很多关注,请参阅 Axel Rauschmayer的博客文章有关异步迭代的更多信息。
With ES2018, you are able to greatly simplify all of the above answers to:
See spec: proposal-async-iteration
Simplified:
2018-09-10: This answer has been getting a lot of attention recently, please see Axel Rauschmayer's blog post for further information about asynchronous iteration.
而不是
promise.all
与array.prototype.map
结合使用(不保证解决Promise
解决的顺序),我使用array.prototype.reduce
,以解决的Promise
:Instead of
Promise.all
in conjunction withArray.prototype.map
(which does not guarantee the order in which thePromise
s are resolved), I useArray.prototype.reduce
, starting with a resolvedPromise
:问题是,迭代功能返回的承诺被
foreach()
忽略。foreach
在完成每个异步代码执行后,不等待移至下一个迭代。所有fs.ReadFile
功能将在同一事件循环中调用,这意味着它们是并行启动的,而不是连续启动,并且执行在调用foreach()之后立即继续
等待所有
fs.ReadFile
操作完成。由于Foreach不等待每个承诺解决,因此循环实际上在解决承诺之前完成了迭代。您期望foreach
完成后,所有异步代码已经执行,但事实并非如此。您最终可能会尝试访问尚不可用的值。您可以使用此示例代码测试行为
该解决方案使用的是循环。
The issue is, the promise returned by the iteration function is ignored by
forEach()
.forEach
does not wait to move to the next iteration after each async code execution is completed. All thefs.readFile
functionswill be invoked in the same round of the event loop, which means they are started in parallel, not in sequential, and the execution continues immediately after invoking forEach(), without
waiting for all the
fs.readFile
operations to complete. Since forEach does not wait for each promise to resolve, the loop actually finishes iterating before promises are resolved. You are expecting that afterforEach
is completed, all the async code is already executed but that is not the case. You may end up trying to access values that are not available yet.you can test the behaviour with this example code
the solution is using the for-of loop.
图片价值1000个字 - 仅用于顺序方法
背景:我昨晚处于类似情况。我将异步函数用作for for for for Angrage。结果是不可预测的。当我对代码进行了3次测试时,它没有问题2次,失败了1次。 (有些奇怪的是)
终于我四处走动&进行了一些刮擦测试。
中,它可以使用异步添加效率。
方案1-在foreach
方案2-使用
for -of -of
loop as @bergi as @bergi as @bergi建议i.sstatic.net/qwbri.png“ rel =“ noreferrer 像我一样小的老派,您可以简单地将经典循环使用,也可以使用:)
我希望这对某人有帮助,美好的一天,欢呼!
Picture worth 1000 words - For Sequential Approach Only
Background : I was in similar situation last night. I used async function as foreach argument. The result was un-predictable. When I did testing for my code 3 times, it ran without issues 2 times and failed 1 time. (something weird)
Finally I got my head around & did some scratch pad testing.
Scenario 1 - How un-sequential it can get with async in foreach
Scenario 2 - Using
for - of
loop as @Bergi above suggestedIf you are little old school like me, you could simply use the classic for loop, that works too :)
I hope this helps someone, good day, cheers!
p-titeration npm上的模块实现了数组迭代方法,因此可以在非常直接的情况下使用它们与异步/等待的方式。
您的案件的一个例子:
The p-iteration module on npm implements the Array iteration methods so they can be used in a very straightforward way with async/await.
An example with your case:
这是一些
foreachAsync
原型。请注意,您需要等待
他们:Note ,您可能将其包含在您自己的代码中,但您不应将其包含在将其分发给他人的库中(以避免污染他们的代码全球)。
要使用:
请注意,您也需要一个现代化的
esrun
才能在打字稿中的最高级别使用。Here are some
forEachAsync
prototypes. Note you'll need toawait
them:Note while you may include this in your own code, you should not include this in libraries you distribute to others (to avoid polluting their globals).
To use:
Note you'll need a modern too like
esrun
to use await at the top level in TypeScript.@Bergi已经给出了有关如何正确处理此特定情况的答案。我不会在这里复制。
我想解决 for 和循环的
之间的
区别strong> <代码> foreach works
让我们看一下
foreach
的工作方式。根据 ecmascript Specificity a href =“ https://developer.mozilla.org/en-us/docs/web/javascript/reference/reference/global_objects/array/aray/foreach#polyfill” rel =“ noreferrer”>多填充。我将其复制并在此处粘贴,并删除评论。让我们回到您的代码,让我们将回调作为函数提取。
因此,基本上是
回调
返回承诺,因为它用async
声明。内部foreach
,回调
只是以正常方式调用,如果回调本身返回承诺,则JavaScript引擎将不等待其解决或拒绝。相反,它将Promise
放在作业队列中,并继续执行循环。等待fs.ReadFile(file,'utf8')
在回调>回调
?基本上,当您的async
callback 有机会被执行,JS引擎将暂停,直到
fs.ReadFile(file,'utf8')
被解析或拒绝,并在实现后恢复执行异步功能。因此,内容
变量存储fs.ReadFile
的实际结果,而不是Promise
。因此,console.log(contents)
记录文件内容而不是Promise
为什么 for ... of 有效?
当我们为Of 循环编写通用
时,我们将获得比
的控制权更多。让我们重构printfiles
。当评估循环时,我们有
等待
保证async
函数,执行将暂停,直到等待
已解决。因此,您可以认为文件是按确定的顺序逐一读取的。有时会顺序执行
,我们确实需要以顺序执行的异步函数。例如,我有一些存储在数组中的新记录要保存到数据库中,我希望它们以顺序保存,这意味着应该先保存数组中的第一个记录,然后再保存,然后再保存,直到最后一个记录。
这是一个示例:
我使用
settimeout
来模拟将记录保存到数据库的过程 - 它是异步的,并且花费了随机的时间。使用foreach
,记录以不确定的顺序保存,但使用 使用,它们被顺序保存。
@Bergi has already gave the answer on how to handle this particular case properly. I'll not duplicate here.
I'd like to address the difference between using
forEach
andfor
loop when it comes toasync
andawait
how
forEach
worksLet's look at how
forEach
works. According to ECMAScript Specification, MDN provides an implementation which can be used as a polyfill. I copy it and paste here with comments removal.Let's back to your code, let's extract the callback as a function.
So, basically
callback
returns a promise since it's declared withasync
. InsideforEach
,callback
is just called in a normal way, if the callback itself returns a promise, the javascript engine will not wait it to be resolved or rejected. Instead, it puts thepromise
in a job queue, and continues executing the loop.How about
await fs.readFile(file, 'utf8')
inside thecallback
?Basically, when your async
callback
gets the chance to be executed, the js engine will pause untilfs.readFile(file, 'utf8')
to be resolved or rejected, and resume execution of the async function after fulfillment. So thecontents
variable store the actual result fromfs.readFile
, not apromise
. So,console.log(contents)
logs out the file content not aPromise
Why
for ... of
works?when we write a generic
for of
loop, we gain more control thanforEach
. Let's refactorprintFiles
.When evaluate
for
loop, we haveawait
promise inside theasync
function, the execution will pause until theawait
promise is settled. So, you can think of that the files are read one by one in a determined order.Execute sequentially
Sometimes, we really need the the async functions to be executed in a sequential order. For example, I have a few new records stored in an array to be saved to database, and I want them to be saved in sequential order which means first record in array should be saved first, then second, until last one is saved.
Here is an example:
I use
setTimeout
to simulate the process of saving a record to database - it's asynchronous and cost a random time. UsingforEach
, the records are saved in an undetermined order, but usingfor..of
, they are saved sequentially.该解决方案还进行了内存优化,因此您可以在 10,000 个数据项和请求上运行它。这里的一些其他解决方案会使服务器在大型数据集上崩溃。
在 TypeScript 中:
如何使用?
This solution is also memory-optimized so you can run it on 10,000's of data items and requests. Some of the other solutions here will crash the server on large data sets.
In TypeScript:
How to use?
替换不起作用的
forEach()
wait 循环的一个简单的嵌入式解决方案是将forEach
替换为map
并添加Promise .all(
到开头。例如:
await y.forEach(async (x) => {
到
await Promise.all(y.map(async (x) )=> {
最后需要额外的
)
。A simple drop-in solution for replacing a
forEach()
await loop that is not working is replacingforEach
withmap
and addingPromise.all(
to the beginning.For example:
await y.forEach(async (x) => {
to
await Promise.all(y.map(async (x) => {
An extra
)
is needed at the end.除了@Bergi的回答之外,我还想提供第三种选择。它与 @Bergi 的第二个示例非常相似,但您不是单独等待每个
readFile
,而是创建一个承诺数组,每个承诺都在最后等待。请注意,传递给
.map()
的函数不需要是async
,因为fs.readFile
无论如何都会返回一个 Promise 对象。因此,promises
是一个 Promise 对象数组,可以将其发送到Promise.all()
。在@Bergi 的回答中,控制台可能会按照读取的顺序记录文件内容。例如,如果一个非常小的文件在一个非常大的文件之前完成读取,那么它将首先被记录,即使在
files
数组中小文件位于大文件之后。但是,在我上面的方法中,可以保证控制台将以与提供的数组相同的顺序记录文件。In addition to @Bergi’s answer, I’d like to offer a third alternative. It's very similar to @Bergi’s 2nd example, but instead of awaiting each
readFile
individually, you create an array of promises, each which you await at the end.Note that the function passed to
.map()
does not need to beasync
, sincefs.readFile
returns a Promise object anyway. Thereforepromises
is an array of Promise objects, which can be sent toPromise.all()
.In @Bergi’s answer, the console may log file contents in the order they’re read. For example if a really small file finishes reading before a really large file, it will be logged first, even if the small file comes after the large file in the
files
array. However, in my method above, you are guaranteed the console will log the files in the same order as the provided array.在文件中弹出几个方法非常轻松,这些方法将以序列化顺序处理异步数据,并为您的代码提供更传统的风格。例如:
现在,假设保存在“./myAsync.js”中,您可以在相邻文件中执行类似于以下操作的操作:
it's pretty painless to pop a couple methods in a file that will handle asynchronous data in a serialized order and give a more conventional flavour to your code. For example:
now, assuming that's saved at './myAsync.js' you can do something similar to the below in an adjacent file:
当
fs
基于 Promise 时,Bergi 的解决方案效果很好。为此,您可以使用
bluebird
、fs-extra
或fs-promise
。但是,节点原生
fs
库的解决方案如下:注意:
require('fs')
强制将函数作为第三个参数,否则抛出错误:Bergi's solution works nicely when
fs
is promise based.You can use
bluebird
,fs-extra
orfs-promise
for this.However, solution for node's native
fs
libary is as follows:Note:
require('fs')
compulsorily takes function as 3rd arguments, otherwise throws error:从循环中调用异步方法并不好。这是因为每次循环迭代都会被延迟,直到整个异步操作完成。这不是很高效。它还避免了
async
/await
的并行化优势。更好的解决方案是一次创建所有 Promise,然后使用 Promise.all() 访问结果。否则,在前一个操作完成之前,每个后续操作都不会开始。
因此,代码可以重构如下;
It is not good to call an asynchronous method from a loop. This is because each loop iteration will be delayed until the entire asynchronous operation completes. That is not very performant. It also averts the advantages of parallelization benefits of
async
/await
.A better solution would be to create all promises at once, then get access to the results using
Promise.all()
. Otherwise, each successive operation will not start until the previous one has completed.Consequently, the code may be refactored as follows;
一个重要的警告是:
await + for .. of
方法和forEach + async
方法实际上具有不同的效果。在真正的
for
循环中使用await
将确保所有异步调用都一一执行。forEach + async
方式会同时触发所有的 Promise,这种方式速度更快,但有时会不知所措(如果你进行一些数据库查询或访问一些有流量限制的 Web 服务 并且不想一次发出 100,000 个呼叫)。如果您不使用
async/await
并且希望确保文件被一个接一个地读取reduce + Promise(不太优雅) >。或者您可以创建一个 forEachAsync 来帮助但基本上使用相同的 for 循环底层。
One important caveat is: The
await + for .. of
method and theforEach + async
way actually have different effect.Having
await
inside a realfor
loop will make sure all async calls are executed one by one. And theforEach + async
way will fire off all promises at the same time, which is faster but sometimes overwhelmed(if you do some DB query or visit some web services with volume restrictions and do not want to fire 100,000 calls at a time).You can also use
reduce + promise
(less elegant) if you do not useasync/await
and want to make sure files are read one after another.Or you can create a forEachAsync to help but basically use the same for loop underlying.
您可以使用
array.prototype.foreach
,但是异步/等待不是那么兼容。这是因为从异步回调返回的承诺期望得到解决,但是array.prototype.foreach
无法从执行其回调中解决任何承诺。因此,您可以使用foreach,但是您必须自己处理承诺解决方案。串联读取和打印每个文件的方法
这是一种使用
array.prototype.foreach
并行文件You can use
Array.prototype.forEach
, but async/await is not so compatible. This is because the promise returned from an async callback expects to be resolved, butArray.prototype.forEach
does not resolve any promises from the execution of its callback. So then, you can use forEach, but you'll have to handle the promise resolution yourself.Here is a way to read and print each file in series using
Array.prototype.forEach
Here is a way (still using
Array.prototype.forEach
) to print the contents of files in parallel只是添加到原始答案
Just adding to the original answer
OP的原始问题
在 @bergi的
因此,让我们讨论这些问题,显示了简短和简洁的实际代码,并且 使用第三方库。易于切割,粘贴和修改的东西。
并行阅读(一次),以序列形式打印(尽可能尽早)。
最简单的改进是像@bergi的答案,但是进行一个小的更改以使每个文件是在保留订单时尽快打印。
上面,同时运行两个单独的分支。
很容易。
与并发限制并行读取,以串行打印(尽可能尽早)。
“并发限制”意味着不超过
n
文件。就像一家仅允许一次允许如此多客户(至少在Covid期间)的商店。
首先,引入了辅助功能
-Code> Bootable Promise(Kickme :()=&gt; promise&lt; any&gt;)
函数
kickme
作为启动任务的参数(在我们的情况下readfile
),但没有立即启动。Bootable Promise
返回一个属性promise
type promise()=&gt; void
promise
在生活中有两个阶段Promise
在调用boot()
时从第一个状态到第二个状态。bootable Promise
在printfiles
中使用,就像之前有两个分支
现在要打印差异,不得超过
共同限制
承诺可以同时运行。重要的变量是
boots
:呼吁强制其相应过渡的函数的数组。它仅在分支1中使用。set
:随机访问容器中有保证,以便一旦实现,它们就可以轻松删除。该容器仅在分支1中使用。BootableProm
:这些与最初的承诺相同。它仅在分支2中使用。使用模拟
fs.ReadFile
运行,该需要以下时间(文件名与MS中的时间)。test run times such as this are seen, showing the concurrency is working --
Available as executable in the typescript playground sandbox
The OP's original question
was covered to an extent in @Bergi's selected answer,
which showed how to process in serial and in parallel. However there are other issues noted with parallelism -
So let's address these issues showing actual code that is brief and concise, and does not use third party libraries. Something easy to cut, paste, and modify.
Reading in parallel (all at once), printing in serial (as early as possible per file).
The easiest improvement is to perform full parallelism as in @Bergi's answer, but making a small change so that each file is printed as soon as possible while preserving order.
Above, two separate branches are run concurrently.
That was easy.
Reading in parallel with a concurrency limit, printing in serial (as early as possible per file).
A "concurrency limit" means that no more than
N
files will ever being read at the same time.Like a store that only allows in so many customers at a time (at least during COVID).
First a helper function is introduced -
The function
bootablePromise(kickMe:() => Promise<any>)
takes afunction
kickMe
as an argument to start a task (in our casereadFile
) but is not started immediately.bootablePromise
returns a couple of propertiespromise
of typePromise
boot
of type function()=>void
promise
has two stages in lifepromise
transitions from the first to the second state whenboot()
is called.bootablePromise
is used inprintFiles
--As before there are two branches
The difference now is the no more than
concurLimit
Promises are allowed to run concurrently.The important variables are
boots
: The array of functions to call to force its corresponding Promise to transition. It is used only in branch 1.set
: There are Promises in a random access container so that they can be easily removed once fulfilled. This container is used only in branch 1.bootableProms
: These are the same Promises as initially inset
, but it is an array not a set, and the array is never changed. It is used only in branch 2.Running with a mock
fs.readFile
that takes times as follows (filename vs. time in ms).test run times such as this are seen, showing the concurrency is working --
Available as executable in the typescript playground sandbox
您可以将简单的传统用于这样的循环
You can use a simple traditional for loop like this
但是,上述解决方案的两种解决方案都可以用更少的代码来完成这项工作,这是它如何帮助我从数据库,几个不同的儿童refs解决数据,然后将它们全部推入数组,然后将其置于诺言中,毕竟是完毕:
Both the solutions above work, however, Antonio's does the job with less code, here is how it helped me resolve data from my database, from several different child refs and then pushing them all into an array and resolving it in a promise after all is done:
就像 @Bergi的回应一样,但有一个区别。
Promise.All
如果被拒绝,则拒绝所有承诺。因此,使用递归。
ps
readfilesqueue
在printfiles
之外导致副作用*由console.log
引入,最好模拟,测试和或间谍因此,拥有返回内容的函数(Sidenote)并不酷。因此,可以简单地设计代码:“纯” **的三个分离功能,并且不引入副作用,处理整个列表并可以轻松修改以处理失败的情况。
未来编辑/当前状态
节点支持顶级等待(这还没有插件,还没有和可以通过Harmony标志启用),很酷,但不能解决一个问题(从策略上我仅在LTS版本上工作)。如何获取文件?
使用构图。鉴于代码,我的原因是它在模块内部,因此应该具有执行功能的函数。如果没有,则应使用IIFE将角色代码包装到异步函数中,创建简单的模块,该模块为您全部完成,或者可以采用正确的方式,有构图。
请注意,可变的名称由于语义而变化。您通过函数(可以通过另一个函数调用的函数),并在内存上收回一个指针,其中包含应用程序逻辑的初始块。
但是,如果不是模块,您需要导出逻辑?
将功能包裹在异步函数中。
或更改变量的名称,无论如何...
*
by Side效果Menans的应用程序效果可以更改应用程序中的雕像/行为或Intouce错误,例如IO。**
by“纯”,它在撇号中,因为函数不是纯净的,并且当没有控制台输出时,只有数据操作就可以将代码收集到纯版本。除此之外,要纯粹,您需要使用处理副作用的单子,这些副作用容易出错,并分别处理该应用程序的错误。
Like @Bergi's response, but with one difference.
Promise.all
rejects all promises if one gets rejected.So, use a recursion.
PS
readFilesQueue
is outside ofprintFiles
cause the side effect* introduced byconsole.log
, it's better to mock, test, and or spy so, it's not cool to have a function that returns the content(sidenote).Therefore, the code can simply be designed by that: three separated functions that are "pure"** and introduce no side effects, process the entire list and can easily be modified to handle failed cases.
Future edit/current state
Node supports top-level await (this doesn't have a plugin yet, won't have and can be enabled via harmony flags), it's cool but doesn't solve one problem (strategically I work only on LTS versions). How to get the files?
Using composition. Given the code, causes to me a sensation that this is inside a module, so, should have a function to do it. If not, you should use an IIFE to wrap the role code into an async function creating simple module that's do all for you, or you can go with the right way, there is, composition.
Note that the name of variable changes due to semantics. You pass a functor (a function that can be invoked by another function) and recieves a pointer on memory that contains the initial block of logic of the application.
But, if's not a module and you need to export the logic?
Wrap the functions in a async function.
Or change the names of variables, whatever...
*
by side effect menans any colacteral effect of application that can change the statate/behaviour or introuce bugs in the application, like IO.**
by "pure", it's in apostrophe since the functions it's not pure and the code can be converged to a pure version, when there's no console output, only data manipulations.Aside this, to be pure, you'll need to work with monads that handles the side effect, that are error prone, and treats that error separately of the application.
目前 Array.forEach 原型属性不支持异步操作,但我们可以创建自己的 Poly-fill 来满足我们的需求。
就是这样!现在,您可以在这些 to 操作之后定义的任何数组上使用 async forEach 方法。
让我们测试一下...
我们可以对其他一些数组函数(例如map
......等等)做同样的事情:)
需要注意的一些事情:
Currently the Array.forEach prototype property doesn't support async operations, but we can create our own poly-fill to meet our needs.
And that's it! You now have an async forEach method available on any arrays that are defined after these to operations.
Let's test it...
We could do the same for some of the other array functions like map...
... and so on :)
Some things to note:
Array.prototype.<yourAsyncFunc> = <yourAsyncFunc>
will not have this feature available今天我遇到了多种解决方案。在 forEach 循环中运行 async wait 函数。通过构建包装器,我们可以实现这一点。
有关其工作原理的更详细说明在内部,对于本机 forEach 以及为什么它无法进行异步函数调用,以及有关各种方法的其他详细信息,请在此处的链接中提供
的多种方式如下:
可以完成此操作 1:使用包装纸。
方法 2:使用与 Array.prototype 的泛型函数相同的方法
Array.prototype.forEachAsync.js
用法:
方法 3:
使用 Promise.all
方法 4:传统 for 循环或现代 for 循环
Today I came across multiple solutions for this. Running the async await functions in the forEach Loop. By building the wrapper around we can make this happen.
More detailed explanation on how it works internally, for the native forEach and why it is not able to make a async function call and other details on the various methods are provided in link here
The multiple ways through which it can be done and they are as follows,
Method 1 : Using the wrapper.
Method 2: Using the same as a generic function of Array.prototype
Array.prototype.forEachAsync.js
Usage :
Method 3 :
Using Promise.all
Method 4 : Traditional for loop or modern for loop
要查看如何出错,请在方法末尾打印Console.log。
一般可能出错的事情:
这些并不总是错的,但在标准用例中经常是错误的。
通常,使用foreach将导致除最后一个。它将调用每个函数,而无需等待功能,这意味着它告诉所有功能启动,然后在不等待函数完成的情况下完成。
这是本机JS中的一个示例,它将保留顺序,防止函数过早返回,从理论上讲,该功能保留了最佳性能。
这将:
使用此解决方案,第一个文件将在可用的情况下立即显示,而无需等待其他文件首先可用。
它还将同时加载所有文件,而不必等待第一个文件才能完成,才能启动第二个文件读取。
唯一的回报和原始版本是,如果一次启动了多个读数,那么由于有更多的错误可能发生的错误,因此很难处理错误。
使用一次读取文件的版本,然后将停止故障,而不会浪费时间尝试读取更多文件。即使有了精心设计的取消系统,也很难避免在第一个文件上失败,但也已经读取了其他大多数文件。
性能并非总是可以预见的。尽管许多系统将使用并行文件读取速度更快,但有些系统更喜欢顺序。有些是动态的,可能会在负载下转移,提供潜伏期的优化并不总是在重大争论下产生良好的吞吐量。
在该示例中也没有错误处理。如果某事要求它们成功地显示或根本不表现出来,则不会做到这一点。
在每个阶段,建议使用Console.Log进行深入的实验,然后假文件读取解决方案(而随机延迟)。尽管许多解决方案在简单的情况下似乎都具有相同的作用,所有解决方案都具有微妙的差异,需要进行一些额外的审查。
使用此模拟来帮助分辨解决方案之间的区别:
To see how that can go wrong, print console.log at the end of the method.
Things that can go wrong in general:
These are not always wrong but frequently are in standard use cases.
Generally, using forEach will result in all but the last. It'll call each function without awaiting for the function meaning it tells all of the functions to start then finishes without waiting for the functions to finish.
This is an example in native JS that will preserve order, prevent the function from returning prematurely and in theory retain optimal performance.
This will:
With this solution the first file will be shown as soon as it is available without having to wait for the others to be available first.
It will also be loading all files at the same time rather than having to wait for the first to finish before the second file read can be started.
The only draw back of this and the original version is that if multiple reads are started at once then it's more difficult to handle errors on account of having more errors that can happen at a time.
With versions that read a file at a time then then will stop on a failure without wasting time trying to read any more files. Even with an elaborate cancellation system it can be hard to avoid it failing on the first file but reading most of the other files already as well.
Performance is not always predictable. While many systems will be faster with parallel file reads some will prefer sequential. Some are dynamic and may shift under load, optimisations that offer latency do not always yield good throughput under heavy contention.
There is also no error handling in that example. If something requires them to either all be successfully shown or not at all it won't do that.
In depth experimentation is recommended with console.log at each stage and fake file read solutions (random delay instead). Although many solutions appear to do the same in simple cases all have subtle differences that take some extra scrutiny to squeeze out.
Use this mock to help tell the difference between solutions:
使用 Task、futurize 和可遍历列表,您可以简单地执行
以下操作:这是您的设置方式
另一种构建所需代码的方法是
或者甚至更面向功能
然后从父函数开始
如果您确实想要更大的灵活性在编码中,你可以这样做(为了好玩,我正在使用建议的 Pipe Forward运算符 )
PS - 我没有在控制台上尝试此代码,可能有一些拼写错误...“直接自由泳,离开圆顶顶部!”正如90后的孩子们会说的。 :-p
Using Task, futurize, and a traversable List, you can simply do
Here is how you'd set this up
Another way to have structured the desired code would be
Or perhaps even more functionally oriented
Then from the parent function
If you really wanted more flexibility in encoding, you could just do this (for fun, I'm using the proposed Pipe Forward operator )
PS - I didn't try this code on the console, might have some typos... "straight freestyle, off the top of the dome!" as the 90s kids would say. :-p
正如其他答案所提到的,您可能希望它按顺序而不是并行执行。 IE。运行第一个文件,等待它完成,然后完成后运行第二个文件。那不会发生什么。
我认为解决为什么这种情况没有发生很重要。
想想
forEach
是如何工作的。我找不到源代码,但我认为它的工作原理是这样的:现在想想当你执行这样的操作时会发生什么:
在
forEach
的for
循环中,我们正在调用cb(arr[i])
,最终成为logFile(file)
。logFile
函数内部有一个await
,因此for
循环可能会在继续之前等待这个await
i++
?不,不会的。令人困惑的是,这并不是
await
的工作原理。来自文档:因此,如果您有以下内容,则不会在
"b"
之前记录数字:循环回到
forEach
,forEach
就像>main
和logFile
就像logNumbers
一样。main
不会仅仅因为logNumbers
做了一些await
操作而停止,并且forEach
不会仅仅因为logNumbers
停止 < code>logFile 做了一些await
操作。As other answers have mentioned, you're probably wanting it to be executed in sequence rather in parallel. Ie. run for first file, wait until it's done, then once it's done run for second file. That's not what will happen.
I think it's important to address why this doesn't happen.
Think about how
forEach
works. I can't find the source, but I presume it works something like this:Now think about what happens when you do something like this:
Inside
forEach
'sfor
loop we're callingcb(arr[i])
, which ends up beinglogFile(file)
. ThelogFile
function has anawait
inside it, so maybe thefor
loop will wait for thisawait
before proceeding toi++
?No, it won't. Confusingly, that's not how
await
works. From the docs:So if you have the following, the numbers won't be logged before
"b"
:Circling back to
forEach
,forEach
is likemain
andlogFile
is likelogNumbers
.main
won't stop just becauselogNumbers
does someawait
ing, andforEach
won't stop just becauselogFile
does someawait
ing.类似于Antonio Val的
p-titeration
,替代NPM模块是async-af
:or
async-af
具有静态方法(log/logaf),可log :但是,库的主要优点是您可以链接异步方法来执行以下操作:
>
> ASYNC-AF
Similar to Antonio Val's
p-iteration
, an alternative npm module isasync-af
:Alternatively,
async-af
has a static method (log/logAF) that logs the results of promises:However, the main advantage of the library is that you can chain asynchronous methods to do something like:
async-af
这是在 forEach 循环中使用异步的一个很好的例子。
编写自己的asyncForEach
你可以像这样使用它
Here is a great example for using async in forEach loop.
Write your own asyncForEach
You can use it like this
如果您想同时迭代所有元素:
如果您想非同时迭代所有元素(例如,当您的映射函数有副作用或一次在所有数组元素上运行映射器将过于耗费资源):
选项 A:Promise
选项 B:异步/等待
If you'd like to iterate over all elements concurrently:
If you'd like to iterate over all elements non-concurrently (e.g. when your mapping function has side effects or running mapper over all array elements at once would be too resource costly):
Option A: Promises
Option B: async/await
的包装器
Promise.all(array.map(iterator))
使用Promise.all(array.map(iterator))
具有正确类型 ,因为打字稿的STDLIB支持已经处理通用。promise.all(array.map(iterator))
每次需要async映射显然是次优的,promise.all(array.map(iterator))不能很好地传达代码的意图 - 因此,大多数开发人员都会将其包装到
asyncmap()
包装器函数中。但是,这样做需要使用仿制药来确保以start value设置的值=等待asyncmap()
具有正确的类型。和快速测试:
sleep()
只是:For TypeScript users, a
Promise.all(array.map(iterator))
wrapper with working typesPromise.all(array.map(iterator))
has correct types since the TypeScript's stdlib support already handles generics.Promise.all(array.map(iterator))
every time you need an async map is obviously suboptimal, andPromise.all(array.map(iterator))
doesn't convey the intention of the code very well - so most developers would wrap this into anasyncMap()
wrapper function. However doing this requires use of generics to ensure that values set withconst value = await asyncMap()
have the correct type.And a quick test:
sleep()
is just: