什么时候我们应该在我们的应用程序中使用线程。换句话说，我什么时候应该将单线程应用程序转换为多线程应用程序。 作为开发人员，我认为阻碍您的应用程序顺利运行的任务。该任务可以由线程处理。就像我们在不断地获取 GPS 数据一样。 我认为，在您的应用程序中创建线程还有其他更多原因。请分享您的意见。
谢谢。
【问题讨论】：
标签： multithreading language-agnostic
我能想到的原因（我相信还有更多）是：
1. 将一批工作卸载到工作线程，以便您的程序可以继续响应用户输入，或者您可以继续运行不依赖该工作的其他代码。
2. 处理 I/O，尤其是响应时间可变或未知的服务器和网络通信。
3. 并行处理数据，您可以将工作细分为离散的非相关工作单元
4. 定时器相关工作，即'每 500 毫秒检查 x 是否发生变化'
但是，切换到多线程或并发编程并非没有陷阱，特别是如果这些线程需要访问共享数据，因此关于mutexes 和thread synchronisation 的问题数量非常多！
【讨论】：
“转换”的一个很好的理由是，多核机器正在成为常态，看到旧程序表现不佳，因为它们只在一个核上工作，这是非常可悲的。
我有一个数字运算应用程序，其中一个部分在具有 16 个虚拟内核的 Mac 上非常慢，因为所需的（通常称为）排序算法只在一个内核上运行。我实现了自己的多线程排序算法，以适应内核和宾果的数量，实现惊人的加速。
使用 CPU 监视器可以清楚地看到这种非常未优化的行为。
您的问题“我们什么时候应该使用线程？”的答案之一。只是“当您通过使软件仅在一个内核上运行而人为地减慢软件速度时”。
顺便说一句，这很有趣，因为在这个例子中，排序算法的复杂度保持为 O(n log n)，但“并行化效应”提供了惊人的速度提升。
其他原因可能是，在某些情况下，正确地多线程处理您的应用程序，例如通过使用经过深思熟虑的生产者/消费者方案，也有助于减少某种资源争用。
【讨论】：
线程的一个很好的用途是解耦不同的问题空间。例如，如果单个线程进行远程通信、用户交互和计算，那么随着程序的增长，可能会出现一些问题。随着通信速度变慢或处理器周期消耗的计算增加，用户体验可能会发生变化。
通过将代码的通信、用户和算法部分（一个简短的列表，特别是如果您正在开发实时系统）分离到它们自己的线程中，您可以提高代码的模块化和可理解性，从而降低可能性避免由于不可预见的后果而引入错误，并且您可以控制执行优先级和同步。
我最近开发的一个应用程序将线程用于日期时间管理、通信、GUI、定期远程请求、运动控制和看门狗。
当然，多线程确实有其自身的问题，尤其是竞争条件和发生超出预期顺序的事情，但这些问题可以通过信号量、互斥锁等进行管理。
【讨论】：
一般的想法是，当可以并行完成某些事情时，您可能受益于使用多个线程（并且您有多个内核可供使用。）想想embarrassingly parallel 问题。这里的目的是在同一时间内完成更多工作。阅读 H. Sutter 关于Effective Concurrency 的文章。
人们经常将用户界面响应与线程联系起来。这不一定是这种情况，取决于特定操作系统/框架/API 的设施，但常见的用法是在后台线程中执行冗长的操作，例如文件打开/保存，因此 UI 在该操作期间不会冻结。
另一种需要线程的情况是当你处理一个在内部使用线程的供应商库（消息产品等）时，你别无选择，只能显式处理线程。
虽然多线程不是火箭科学，但它很难。获得诸如竞争条件、死锁、优先级反转和内存模型等基础知识是值得的在你的脑海中挣扎。
【讨论】：
多线程的主要用途是，当有一个 并行代码流的要求。
我能举出的最好例子是破球游戏， 您必须在其中运行动画来显示球是 移动并从用户那里获取输入来移动球棒。
在这里，您将在线程上运行动画并与 其他线程上的用户。这是单线程应用无法解决的。
【讨论】：
OldEnthusiast 说的很对，利用内核是使用线程的原因之一。但是，即使您在不是 umpteen-core 的旧硬件上运行，仍然有理由使用线程。那就是如果您需要允许用户在您的程序执行冗长的任务时保持对 UI 的控制。您的程序可以将任务（例如处理文件或从网络获取某些内容）拆分到一个线程中，并且仍然允许用户与程序进行交互，例如排队另一个作业。
【讨论】：