线程使程序的设计，实现和调试变得更加困难。
然而，许多人似乎认为可以线程化的程序中的每个任务都应该是线程化的，即使在单个核心系统上也是如此。
我可以理解线程类似MPEG2解码器的东西，它将在多核cpu（我已经完成）上运行，但是当你谈论单个核心系统甚至是单个核心系统时，线程的重要开发成本是什么呢？如果你的任务没有从并行实现中获得显着的性能，那么是多核系统吗？
或者更简洁地说，什么样的非绩效相关问题证明线程是正确的？
修改
我刚刚遇到一个不受CPU限制的实例，但线程产生了很大的不同：
TCP, HTTP and the Multi-Threading Sweet Spot
当尝试通过高延迟网络连接将带宽最大化到另一个对等方时，多个线程非常有用。非阻塞I / O将使用明显更少的本地CPU资源，但设计和实现起来会更加困难。
答案 0 :(得分：6)
例如，在不阻止用户界面的情况下执行CPU密集型任务。
答案 1 :(得分：5)
您可能在等待资源的任何应用程序（例如，阻止来自网络套接字或磁盘设备的I / O）都可以从线程中受益。
在这种情况下，缓慢操作的线程阻塞可以在其他线程继续运行时进入休眠状态（在某些操作系统下，包括GUI线程，如果操作系统暂时无法联系它，将提供使用机会摧毁它，认为它以某种方式陷入僵局。）
所以对于多核机器来说，它根本不是 。
答案 2 :(得分：4)
一个有趣的例子是一个网络服务器 - 您需要能够处理多个彼此无关的传入连接。
答案 3 :(得分：2)
什么样的非表现相关 问题是否符合线索？
Web应用程序是典型的例子。每个用户请求在概念上都是一个新线程。与性能无关，它只是设计的自然选择。
答案 4 :(得分：2)
与非阻塞代码相比，阻塞代码通常更易于编写，更易于阅读（因此也更易于维护）。然而，使用阻塞代码将您限制为单个执行路径，并且还会锁定诸如用户界面（提及）和其他IO端口之类的东西。在这些情况下，线程是一种优雅的解决方案。
要考虑多线程的另一种情况是，当您有几个应该管理的近同步IO通道时：使用多个线程（通常是本地消息队列）可以提供更清晰的代码。
答案 5 :(得分：1)
以下是一些特定且简单的场景，我已经启动了线程......
用户长时间运行的报告请求。提交报告时，它将放在队列中以由单独的线程处理。然后，用户可以在应用程序中继续查看并稍后查看他们的报告状态，他们不会留下“正在处理...”页面或图标。
一个迭代缓存存储的线程，删除已过期或不再需要的数据。应用程序中的线程作业独立于特定用户的任何处理，但是整个应用程序运行时维护的一部分。
虽然不是特别是一个线程场景，但我们网站内的日志记录会转移到并行进程，因此记录日志数据所需的时间不会妨碍网站的吞吐量。
我同意仅为了线程而进行线程不是一个好主意，如果没有正确完成，它可能会在您的应用程序中引入问题，但它是解决某些问题的极其有用的工具。
答案 6 :(得分：1)
每当你需要调用一些外部组件（无论是数据库查询，3方库，操作系统原语等）时，只提供同步/阻塞接口或使用异步接口不值得额外的麻烦和痛苦 - 你还需要某种形式的并发 - 例如为服务器中的多个客户端提供服务或保持GUI仍然响应。
答案 7 :(得分：1)
那么，你怎么知道你的应用程序是否会在多核系统上运行？
除此之外，还有很多流程占用时间，但不需要CPU。如写入磁盘或网络。谁想要在GUI中按下按钮然后必须坐在那里等待网络连接。即使在单核心机器上，拥有单独的IO线程也可以极大地改善用户体验。您总是至少想要一个单独的UI线程。
答案 8 :(得分：0)
然而很多人似乎都这么认为 程序中的每个任务都可以 螺纹应该是螺纹的，即使是在螺纹上 单核系统。
“很多人”......谁？
另外根据我的经验，许多应该是多线程的程序都没有（尤其是游戏......我有i7，但大多数游戏仍然只使用我的1个核心），所以我不确定你在说什么关于。绝对像calc.exe这样的程序不是多线程的（或者，如果它们是1个线程完成了99％的工作）。
执行CPU密集型任务 没有阻止用户界面， 例如。
是的，这是真的，但这很容易实现，而且它不是OP所指的（因为，在这种情况下，1个线程几乎完成了所有的工作，你只需要很少的互斥量）