要多线程还是不多线程！ [英] To multi-thread or not to multi-thread!
问题描述
这是问题！
什么时候必须使用多线程应用程序，通常在多线程中要考虑什么?
When is multi-threading an application a must, and what to consider in multi-threading in general?
如果将示例与说明一起发布，将不胜感激.
It would be greatly appreciated if an example is posted along with the explanation.
谢谢.
PS.我尝试在发布之前检查所有可能问题，如果该问题只是另一个重复，请关闭它.
PS. I tried checking all the possible questions before posting, if this question is simply another duplicate, please close it.
推荐答案
在 C#中的线程中，约瑟夫·阿尔巴海(Joseph Albahai)有一个漂亮的标题为 线程的使用和滥用.它列出了五个常见的线程用例.
In Threading in C# by Joseph Albahai has a nice section entitled Threading’s Uses and Misuses. It lists five common use cases for threading.
维护响应式用户界面
运行耗时 并行工作者"线程上的任务， 主UI线程可以自由继续 处理键盘和鼠标事件.
By running time-consuming tasks on a parallel "worker" thread, the main UI thread is free to continue processing keyboard and mouse events.
有效利用原本被阻塞的CPU
当一个线程时多线程很有用 正在等待另一个人的回应 计算机或硬件.尽管 执行时一个线程被阻塞 该任务，其他线程可以承担 否则负担不大的优势 电脑.
Multithreading is useful when a thread is awaiting a response from another computer or piece of hardware. While one thread is blocked while performing the task, other threads can take advantage of the otherwise unburdened computer.
并行编程
执行强化代码 计算可以更快地执行 多核或多处理器计算机 如果工作负载是共享的 一个线程中有多个线程 分而治之"策略
Code that performs intensive calculations can execute faster on multicore or multiprocessor computers if the workload is shared among multiple threads in a "divide-and-conquer" strategy
投机执行
在多核计算机上，您可以 有时通过以下方式提高性能 预测可能需要的东西 要做，然后再做 时间. LINQPad使用此技术 加快新产品的创建 查询.一种变化是运行 中的不同算法数量 并行解决所有相同的任务. 谁先完成 获胜"-当您 不能提前知道 算法将执行最快.
On multicore machines, you can sometimes improve performance by predicting something that might need to be done, and then doing it ahead of time. LINQPad uses this technique to speed up the creation of new queries. A variation is to run a number of different algorithms in parallel that all solve the same task. Whichever one finishes first "wins"—this is effective when you can’t know ahead of time which algorithm will execute fastest.
允许同时处理请求
在服务器上，客户端请求可以 同时到达，因此需要 并行处理(.NET 框架为此创建线程 如果您使用ASP.NET，WCF， Web服务或远程).这个可以 对客户也很有用(例如， 处理对等网络-或 甚至来自用户的多个请求.
On a server, client requests can arrive concurrently and so need to be handled in parallel (the .NET Framework creates threads for this automatically if you use ASP.NET, WCF, Web Services, or Remoting). This can also be useful on a client (e.g., handling peer-to-peer networking—or even multiple requests from the user).
什么时候不去
他继续警告读者
When not to
He goes on to caution the reader
使用ASP.NET和 WCF，您可能没有意识到 多线程甚至需要 地点-除非您访问共享数据 (也许通过静态字段)没有 适当的锁定，违反 线程安全.
With technologies such as ASP.NET and WCF, you may be unaware that multithreading is even taking place—unless you access shared data (perhaps via static fields) without appropriate locking, running afoul of thread safety.
线程也自带 附加条件.最大的是 多线程可以增加 复杂.有很多线程 本身并不能创造太多 复杂;这是互动 线程之间(通常通过共享 数据).这是否适用 互动不是故意的 并可能导致较长的开发周期 以及持续的易感性 间歇性和不可复制的错误. 因此，必须付出代价 互动到最低限度，并 坚持简单可靠的设计 在任何可能的地方.本文 主要集中于处理公正 这些复杂性；除掉 互动，而要做的事情少得多 说！
Threads also come with strings attached. The biggest is that multithreading can increase complexity. Having lots of threads does not in and of itself create much complexity; it’s the interaction between threads (typically via shared data) that does. This applies whether or not the interaction is intentional, and can cause long development cycles and an ongoing susceptibility to intermittent and nonreproducible bugs. For this reason, it pays to keep interaction to a minimum, and to stick to simple and proven designs wherever possible. This article focuses largely on dealing with just these complexities; remove the interaction and there’s much less to say!
一个好的策略是 将多线程逻辑封装到 可重用的类可以是 独立检查和测试. 框架本身提供了许多 更高级的线程结构， 我们稍后会介绍.
A good strategy is to encapsulate multithreading logic into reusable classes that can be independently examined and tested. The Framework itself offers many higher-level threading constructs, which we cover later.
也线程化 产生资源和CPU成本 调度和切换线程(当 活动线程多于 CPU核心)-还有一个 创建/删除成本. 多线程并不总是可以加快速度 您的应用程序—它甚至可能会变慢 如果使用过多，则降下来；或 不适当地.例如，当 涉及大量磁盘I/O，可能是 快几个工人 线程按顺序运行任务，而不是 一次执行10个线程. (在等待和脉冲信号中，我们 描述如何实施 生产者/消费者队列， 仅提供此功能.)
Threading also incurs a resource and CPU cost in scheduling and switching threads (when there are more active threads than CPU cores)—and there’s also a creation/tear-down cost. Multithreading will not always speed up your application—it can even slow it down if used excessively or inappropriately. For example, when heavy disk I/O is involved, it can be faster to have a couple of worker threads run tasks in sequence than to have 10 threads executing at once. (In Signaling with Wait and Pulse, we describe how to implement a producer/consumer queue, which provides just this functionality.)
这篇关于要多线程还是不多线程！的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
