我什么时候应该使用线程？

Question

就我而言，理想的线程数量是3：一个用于UI，一个用于CPU资源，一个用于IO资源。

但我可能错了。

我刚刚介绍给他们，但我总是使用一个用于UI，一个用于其他所有。

我什么时候应该使用线程？我怎么知道我是否应该使用它们？

Answer 1

不幸的是，使用Threads并没有严格的规则。如果您有太多线程，处理器将花费所有时间在它们之间生成和切换。使用太少的线程，您将无法获得应用程序中所需的吞吐量。另外使用线程并不容易。像C＃这样的语言让你更容易，因为你有像ThreadPool.QueueUserWorkItem这样的工具。这允许系统管理线程创建和销毁。这有助于减少创建新线程以将工作传递到其上的开销。你必须记住，创建一个线程不是你“免费”获得的操作。启动一个线程有相关的成本，所以应该始终考虑到这一点。

根据您用于编写应用程序的语言，您将决定使用线程需要多少担心。

我经常发现需要考虑明确创建线程的时间是：

• 异步操作
• 可以并行化的操作
• 持续运行后台操作

Answer 2

答案完全取决于你计划做什么。但是，一个CPU资源是一个不好的举措 - 你的CPU在零售CPU中可能有多达六个内核和超线程，而大多数CPU将有两个或更多。在这种情况下，您应该拥有与CPU核心一样多的线程，以及一些用于调度事故的线程。整个CPU不是单线程的野兽，它可能有很多核心，需要很多线程才能100％利用。

当且仅当您的目标人群几乎都具有多核（如当前台式机/笔记本电脑市场的情况）时，您应该使用线程，并且您已确定一个核心的性能不够。

Answer 3

来自SQLite FAQ：“Threads are evil。避免他们。”只有在必要时才使用它们。

如果必须，请采取措施避免通常的屠杀。使用线程池执行细粒度的任务，没有相互依赖性，使用GUI框架提供的工具将结果分发回UI。避免在长时间运行的线程之间共享数据;使用消息队列在它们之间传递信息（和同步）。

更奇特的解决方案是使用Erlang等语言，这些语言专为细粒度并行而设计，而不会牺牲安全性和可理解性。并发本身对计算的未来至关重要;线程只是表达它的一种可怕的，破碎的方式。

Answer 4

Herb Sutter为Dobb博士的期刊写了an article，其中他谈到了并发的三大支柱。本文非常好地分解了哪些问题是通过线程结构解决的好选择。

Answer 5

“理想的线程数”取决于您的特定问题以及您可以利用的并行度。如果你有一个“令人难以置信的并行”的问题，它可以被细分为独立的问题，它们之间几乎没有通信，你有足够的内核可以实现真正的并行性，那么你使用的线程数取决于诸如问题大小，缓存行大小，上下文切换和产生开销以及其他各种事先难以计算的事情。对于这种情况，您必须进行一些分析，以便跨线程选择最佳的问题分片/分区。但是，使用比核心更多的线程通常没有意义。如果您有很多同步，那么事实上，您可能会因使用线程而受到性能损失。它高度依赖于特定问题以及各步骤的相互依赖性。作为一个指导原则，您需要注意产生线程和线程同步是昂贵的操作，但如果通信和其他形式的同步最小化，并行执行计算可以提高吞吐量。您还应该知道，如果线程最终使相互共享的高速缓存行无效，则线程可能导致非常差的高速缓存性能。