【发布时间】:2021-09-30 12:08:33
【问题描述】:
CPU 密集型问题是需要 CPU 进行计算的问题。 IO 绑定问题是需要等待网络、磁盘或输入的问题。 单个 API 请求是 IO 绑定的。
问题是,当我使用 for 循环发出 100 个 API 请求时,我们是否说这些请求是 IO 绑定的?还是我们说它们受 CPU 限制?还是说它们都受 CPU 和 IO 限制?
通常对于 IO 绑定,我们使用多线程,或者如果我们使用单线程,我们可以使用 async/await。至于 CPU 绑定的进程,我们使用并行编程或多处理或异步等待 Task.Run。
对于我在 for 循环中的 100 个 API 请求的示例,async/await 是否比多线程或 async/await+Task.Run 或 TPL 更好?
【问题讨论】:
-
这么多混乱...您是在 制作 api 调用还是从 API 的角度来看?如果您对网络 api 进行 100 次调用,那么在该客户端上下文中,它完全是 I/O 绑定的。如果你在另一边,那么这取决于api在做什么。它可能是 I/O、CPU 或混合的。
-
顺便说一句:“单线程异步等待”没有任何意义。最后,你真的不知道你最终会使用多少个线程。 Async/Await 任务从线程层抽象出来。它可能在单个线程或多个线程上执行。但最后:你不在乎。它的设计让您不必在意(当然有例外)。
-
“对于我在 for 循环中 100 个 api 请求的示例,异步等待是否比多线程更好?” - 你对“更好”的定义是什么?
-
您能否向我们展示如何使用并行编程(或多线程)来发出 100 个并发 I/O 绑定 API 请求?我之所以问,是因为困境可能不是“并行与异步/等待”,而是“同步与异步”。
-
@fildor - 假设我不使用Task.Run,那么这不是保证将使用相同的线程吗?
标签: c# ajax multithreading api asynchronous