AWS-用于在 AWS 上进行构建的工具

Discuss

1

如果你有n个繁忙线程都是100％独立工作，那么这将比Fork-Join（FJ）池中的n个线程更好。但它从来没有这样做过。

可能无法将问题精确地分成n个相等的部分。即使你这样做，线程调度也是不公平的。你最终会等待最慢的线程。如果你有多个任务，那么它们每个都可以以低于n路的并行性运行（通常效率更高），但在其他任务完成时可以达到n路。

那么为什么我们不把问题简化为FJ大小的部分并且有一个线程池工作。典型的FJ使用将问题分解成小块。以随机顺序执行这些操作需要在硬件级别进行大量协调。开销将是一个杀手。在FJ中，任务被放入队列中，线程以后进先出顺序（LIFO /堆栈）读取，并且工作窃取（通常在核心工作中）先进先出（FIFO /“队列”）。结果是长阵列处理可以在很大程度上顺序完成，即使它被分成很小的块。 （同样的情况是，在一次大爆炸中将问题分解成小的均匀大小的块可能并不是一件轻而易举的事。假设在没有平衡的情况下处理某种形式的层次结构。）

结论：FJ允许在不平衡的情况下更有效地使用硬件线程，如果您有多个线程，则总是如此。

2

• 是的，在您的示例中，Fork/Join没有经典线程池的优势。
• 在涉及阻塞时，Fork/Join可以显着提高性能
• Fork/Join可以避免一些死锁问题

3

• ForkJoin更适合计算密集型而不适合IO的操作（可以在代码的compute的地方打印出log，会发生很神奇的事情）
• 任务没有阻塞，不会发生卡死
• 尽量让线程负载均衡，从而减少“窃取”的发生，因为从其他线程队列中获取任务的开销要比在自己的队列执行pop操作的开销大，并且只运行自己部分的任务可以获得更好的数据访问局部性

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 wshten@gmail.com