线程还是异步?

ThreadPool . 线程池也是异步函数经常使用的。产生大量线程实际上会影响性能。线程池的设计目的是产生足够的线程,以最快的速度完成工作。因此,除非线程池不能满足您的需要,否则一定要使用线程池,而不是spwang您自己的线程。

附言:并密切关注 Parallel Extensions 来自微软

繁殖线程只会浪费资源,如果你开始繁殖成吨的线程,一个或两个额外的线程不会影响平台的性能,事实上系统目前有超过70个线程供我使用,msn使用32个线程(我真的不知道一个messenger怎么能使用这么多线程,特别是当它最小化并且不真正做任何事情时…)

通常,当某些事情需要很长时间,但您需要继续做其他事情时,就可以生成线程。

比如说计算需要30秒。最好的办法是为计算生成一个新线程,这样你就可以继续更新屏幕,并处理任何用户输入,因为如果你的应用程序冻结到完成计算,用户会讨厌它。

另一方面,创建线程来完成几乎可以立即完成的任务几乎是毫无意义的,因为创建(甚至只是使用线程池将工作传递给现有线程)的开销将高于一开始就完成的任务。

我会支持你的 Fire Lancer's 答案-创建自己的线程是处理大型任务或处理可能会“阻塞”其他同步应用程序的任务的极好方法, 但是

例如,我最近研究的一个例子——Java控制台应用程序定期运行,通过屏幕抓取URL、使用DOM解析文档、提取数据并将其存储在数据库中来捕获数据。

作为一个单线程应用程序,正如您所期望的,它需要一段时间,对于一个50kb的页面,平均每秒1个url。还不算太糟,但当您扩展到需要成批处理数千个URL时,这是不好的。

对应用程序进行分析表明,大多数时候活动线程处于空闲状态—它在等待I/O操作—打开远程URL的套接字,打开与数据库的连接等。这种情况可以通过多线程轻松改善。即使在单核cpu上,重写为多线程且仅使用5个线程而不是1个线程,吞吐量也会增加20倍以上。

在这个例子中,每个“worker”线程都被显式地限制为它所做的事情——打开远程url,解析数据,将其存储在db中。所有的“高级”处理——生成要解析的URL列表、确定下一个URL、处理错误——都由主线程控制。

线程的使用使您能够更多地考虑应用程序需要线程的方式,并且从长远来看,可以更容易地改进/控制性能。
异步方法使用起来更快,但它们有点神奇——许多事情恰好使它们成为可能——因此,在某个时候,您可能需要一些它们无法提供给您的东西。然后您可以尝试滚动一些自定义线程代码。
这完全取决于你的需要。

答案是“视情况而定”。

最简单的解决方案是找到另一种提高性能的方法。运行分析器。寻找热点。减少不必要的IO。

下一个解决方案是将程序分成多个进程,每个进程都可以在自己的地址空间中运行。这是最简单的,因为单个进程不可能相互干扰。

下一个解决方案是使用线程。在这一点上,您打开了一个主要的蠕虫程序,所以从小的开始,并且只多线程执行代码的关键路径。

请注意,这些解决方案中的每一个都有多个子解决方案——有不同种类的线程和不同种类的异步IO,每一种都有稍微不同的性能特征,但同样,通常最好让框架为您处理。