我最近正在开发一个通过以太网和串行发送和接收消息的应用程序。然后我的任务是添加 DIO 离散的监控。我通过了，
"没有理由中断主 消息中涉及的线程 处理，我将创建 另一个线程监控 DIO。”
然而，这个决定被证明是糟糕的。有时主线程会在发送和接收串行消息之间中断。这种中断会打乱时间，唉，消息会丢失（永远）。
我找到了另一种方法来监控 DIO，无需使用其他线程，以太网和串行通信已恢复到正确的功能。
然而，整个惨败让我思考。 他们是否有关于何时不使用多线程的一般准则和/或是否有人再有使用多线程不是一个好主意的情况示例？ p>
**编辑：根据你的cmets，在网上搜索信息后，我写了一篇题为When is multi-threading not a good idea?的博客文章
【问题讨论】：
标签： multithreading language-agnostic
总的来说，如果您使用多个线程而不是解冻桌面应用程序和任何其他通用答案，您将使应用程序变慢如果由于线程中断而您有一个单核机器彼此。
为什么？因为硬件开关。硬件在线程之间切换总共需要时间。在多核机器上，继续为每个内核使用 1 个线程，您会看到大幅提升。
【讨论】：
套用一句老话：程序员遇到了问题。他想，“我知道，我会用线。”现在程序员有两个问题。 （通常归因于 JWZ，但它似乎早于他使用它来谈论正则表达式。）
一个好的经验法则是“不要使用线程，除非有非常令人信服的理由使用线程。”多个线程正在自找麻烦。尝试找到一种不使用多线程来解决问题的好方法，并且只有在避免使用线程与使用线程的额外努力一样麻烦时才回退到使用线程。此外，如果您在多核/多 CPU 机器上运行，请考虑切换到多线程，单线程版本的性能测试表明您需要额外内核的性能。
【讨论】：
如果出现以下情况，多线程是个坏主意：
多个线程访问和更新同一个资源（设置变量，写入文件），而你不懂thread safety。
多个线程相互交互，您不了解mutexes 和类似的线程管理工具。
您的程序使用静态变量（线程通常默认共享它们）。
您尚未调试并发问题。
【讨论】：
实际上，多线程是不可扩展的，而且很难调试，所以如果可以避免的话，在任何情况下都不应该使用它。在少数情况下它是强制性的：当多 CPU 的性能很重要时，或者当您处理有很多客户端需要很长时间才能响应的服务器时。
在任何其他情况下，您可以使用队列 + cron 作业等替代方案。
【讨论】：
您可能想查看 Dan Kegel 的“The C10K problem”网页，了解如何处理多个数据源/接收器。
基本上最好使用最少的线程，这可以在大多数操作系统中使用某些事件系统（或在 Windows 中使用 IOCP 异步）来完成。
当您遇到操作系统和/或库不提供以非阻塞方式执行通信的方法时，最好使用线程池来处理它们，同时向同一事件报告循环。
布局示例图：
Per CPU [*] EVENTLOOP ------ Handles nonblocking I/O using OS/library utilities
| \___ Threadpool for various blocking events
Threadpool for handling the I/O messages that would take long
【讨论】：
多线程是不好的，除了在单一情况下它是好的。这个案例是
如果缺少这两个条件中的一个或两个，多线程将不会是一个成功的策略。
如果工作不受 CPU 限制，那么您等待的不是线程完成工作，而是等待一些外部事件，例如网络活动，以便进程完成其工作。使用线程，会有额外的线程间上下文切换成本、同步成本（互斥锁等）以及线程抢占的不规则性。最常用的替代方案是异步 IO，其中单个线程监听多个 io 端口，并针对现在恰好准备好的任何一个进行操作，一次一个。如果这些慢通道碰巧同时都准备好了，那么您似乎会经历减速，但实际上这很少是真的。单独处理每个端口的成本通常与在每个通道被清空时在多个线程上同步状态的成本相当或更好。
许多任务可能受计算限制，但使用多线程方法仍然不切实际，因为进程必须在整个状态上同步。这样的程序不能从多线程中受益，因为不能同时执行任何工作。幸运的是，大多数需要大量 CPU 的程序都可以并行化到一定程度。
【讨论】：
如果您需要保证精确的物理时序（如您的示例中），多线程不是一个好主意。其他缺点包括线程之间的密集数据交换。如果您不太关心它们的相对速度/优先级/时序，我会说多线程非常适合真正的并行任务。
【讨论】：
我最近写的一个必须使用多线程的应用程序（尽管不是无限数量的线程）是一个我必须通过两个协议在多个方向上进行通信的应用程序，并监视第三个资源的更改。两个协议库都需要一个线程来运行各自的事件循环，当考虑到这些时，很容易为资源监控创建第三个循环。除了事件循环要求之外，通过线路的消息还有严格的时序要求，一个循环不能冒阻塞另一个循环的风险，使用多核 CPU (SPARC) 可以进一步缓解这种情况。
关于是否应将每个消息处理视为从线程池中分配给线程的工作进行了进一步讨论，但最终这是一个不值得工作的扩展。
总而言之，如果可能，仅当您可以将工作划分为定义明确的作业（或一系列作业）时才应考虑线程，这样语义相对容易记录和实现，并且您可以设置一个上受限于您使用的线程数和需要交互的线程数。最佳应用的系统几乎是消息传递系统。
【讨论】：
原则上每次调用者在队列中等待都没有开销。
【讨论】：
更多使用线程的可能原因：
在密集处理期间保持 GUI 响应并不总是需要额外的线程。一个回调函数通常就足够了。
如果以上都不适用，并且出于某种原因我仍然想要并行性，我更愿意在可能的情况下启动一个独立的进程。
【讨论】：
我会说多线程通常用于：
因此，如果您没有解决其中一个问题，那么添加线程不太可能让您的生活更轻松。事实上，这几乎肯定会让事情变得更难，因为正如其他人所提到的那样；调试多线程应用程序比单线程解决方案要多得多。
安全性可能是避免使用多线程（通过多个进程）的一个原因。有关多进程安全功能的示例，请参阅 Google chrome。
【讨论】：
多线程是可扩展的，并且允许您的 UI 在后台执行非常复杂的事情时保持其响应性。我不明白其他响应在哪里获取他们关于多线程的信息。
什么时候你不应该多线程是一个误导你的问题的问题。您的问题是：为什么我的应用程序的多线程导致串行/以太网通信失败？
该问题的答案将取决于实施，这应在另一个问题中讨论。我知道您可以在多线程应用程序中同时进行以太网和串行通信以及许多其他任务，而不会导致任何数据丢失。
不使用多线程的一个原因是：
使用多线程的原因是：
多线程编程的三种基本方法可以轻松实现线程安全——您只需要使用一种即可成功：
【讨论】：
进程是否并行？性能是一个真正的问题吗？是否像在 Web 服务器上一样有多个执行“线程”？我不认为有一个有限的答案。
【讨论】：
线程问题的常见来源是用于同步数据的常用方法。让线程共享状态然后在所有适当的位置实现锁定是设计和调试复杂性的主要来源。获得锁定权以平衡稳定性、性能和可扩展性始终是一个难以解决的问题。即使是最有经验的专家也经常出错。处理线程的替代技术可以减轻这种复杂性。 Clojure 编程语言实现了几种有趣的并发处理技术。
【讨论】：