什么时候使用多线程？
什么时候在应用程序中使用线程？例如，在简单的CRUD操作中，使用smtp，如果服务器面临带宽问题，调用可能需要一些时间的web服务等。
老实说，我不知道如何确定是否需要使用线程（我知道这一定是在我们排除某项操作需要一些时间才能完成的情况下）。
这可能是一个“菜鸟”问题，但如果您与我分享您在线程方面的经验，那就太好了。
谢谢
When do you use threads in a application? For example, in simple CRUD operations, use of smtp, calling webservices that may take a few time if the server is facing bandwith issues, etc.
To be honest, i don't know how to determine if i need to use a thread (i know that it must be when we're excepting that a operation will take a few time to be done).
This may be a "noob" question but it'll be great if you share with me your experience in threads.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我在您的问题中添加了 C# 和 .NET 标签，因为您在标题中提到了 C#。如果这不准确，请随意删除标签。
多线程有不同的风格。例如，有带有回调函数的异步操作。 .NET 4 引入了并行 Linq 库。您将使用的多线程风格，或者是否使用任何多线程风格，取决于您想要完成的任务。
并行执行（例如并行 Linq 通常尝试执行的操作）利用多个处理器核心来执行不需要等待彼此数据的指令。 Linq 之外有许多此类算法的来源，例如此。但是，并行执行可能无法满足您的需要，或者它不适合您的应用程序。
更传统的多线程利用 .NET 库（在本例中）内的线程，如 System.Thread 提供的。请记住，在线程上启动进程会产生一些开销，因此仅当这样做的优点超过此开销时才使用线程。一般来说，只有当线程下运行的任务有很长的间隙（处理器可以在其中执行其他操作）时，您才需要使用这种类型的单处理器多线程。例如，来自硬盘（以及因此来自使用硬盘的数据库系统）的 I/O 比内存访问慢许多数量级。作为另一个例子，网络访问也可能很慢。多线程可以允许另一个进程在等待这些缓慢（与处理器相比）操作完成的同时运行。
我使用传统多线程的另一个例子是在会话中第一次访问特定 ASP.NET 页面时缓存一些值。我启动一个线程，以便用户在与页面交互之前不必等待缓存完成。我还规范了在用户请求另一个页面之前缓存未完成时的行为，这样，如果缓存未完成，也不是问题。它只是使一些以前太慢的进一步请求变得更快。
还要考虑多线程对应用程序的可维护性造成的成本。例如，线程应用程序可能更难调试。
我希望这至少能在一定程度上回答你的问题。
I added C# and .NET tags to your question because you mention C# in your title. If that is not accurate, feel free to remove the tags.
There are different styles of multithreading. For example, there are asynchronous operations with callback functions. .NET 4 introduces the parallel Linq library. The style of multithreading you would use, or whether to use any at all, depends on what you are trying to accomplish.
Parallel execution, such as what parallel Linq would generally be trying to do, takes advantage of multiple processor cores executing instructions that do not need to wait for data from each other. There are many sources for such algorithms outside Linq, such as this. However, it is possible that parallel execution may be unable to you or that it does not suit your application.
More traditional multithreading takes advantage of threading within the .NET library (in this case) as provided by
System.Thread. Remember that there is some overhead in starting processes on threads, so only use threads when the advantages of doing so outweigh this overhead. Generally speaking, you would only want to use this type of single-processor multithreading when the task running under the thread will have long gaps in which the processor could be doing something else. For example, I/O from hard disk (and, consequently, from a database system that uses one) is many orders of magnitude slower than memory access. Network access can also be slow, as another example. Multithreading could allow another process to be running while waiting for these slow (compared to the processor) operations to complete.Another example when I have used traditional multithreading is to cache some values the first time a particular ASP.NET page is accessed within a session. I kick off a thread so that the user does not have to wait for the caching to complete before interacting with the page. I also regulate the behavior when the caching does not complete before the user requests another page so that, if the caching does not complete, it is not a problem. It simply makes some further requests faster that were previously too slow.
Consider also the cost that multithreading has to the maintainability of your application. Threaded applications can be harder to debug, for example.
I hope this answers your question at least somewhat.
Joseph Albahari 在此处总结得很好：
Joseph Albahari summarized it very well here:
使用线程的原因之一是将大型 CPU 密集型任务拆分到多个 CPU/核心上，以更快地完成。另一种方法是让扩展任务异步执行，以便前台在运行时可以保持响应。
你的例子似乎集中在第二个。虽然这可能是一个很好的理由，但如果您可以使用异步 I/O，这通常是更好的选择（例如，几乎任何使用套接字的东西都可以/将会更好地异步使用套接字）。异步 I/O 更容易取消，并且通常也具有较低的 CPU 开销。
One reason to use threads is to split large, CPU-bound tasks across a number of CPUs/cores, to finish faster. Another is to let an extended task execute asynchronously, so the foreground can remain responsive while it runs.
Your examples seem to be concentrating on the second of these. While it can be a good reason, if you can use asynchronous I/O instead, that's usually preferable (e.g., almost anything using sockets can/will be better off using the socket(s) asynchronously). Asynchronous I/O is easier to cancel, and it'll usually have lower CPU overhead as well.
当需要不同的执行路径时，可以使用线程。这会导致（如果正确完成）应用程序响应更快和/或更快，但也会导致更复杂的代码和调试。
在简单的 CRUD 场景中可能没那么有用，但也许您的 UI 正在使用缓慢的 Web 服务。如果您的代码与 UI 线程绑定，则服务调用之间的 UI 将会无响应。
在这种情况下，使用 System.Threading.Threads 可能有点矫枉过正，因为您不需要太多控制。使用 BackgrounWorker 可能是更好的选择。
线程是很难掌握的东西，但是如果正确使用，好处是巨大的，性能是最常见的。
You can use threads when you need different execution paths. This leads(when done correctly) to more responsive and/or faster applications but also leads to more complex code and debugging.
In a simple CRUD scenario maybe is not that useful, but maybe your UI is consuming a slow web service. If you your code is tied to your UI thread you will have unresponsive UI between the service calls.
In that case, using System.Threading.Threads maybe be overkill because you don't need so much control. Using a BackgrounWorker maybe a better choice.
Threading is something difficult to master, but the benefits when used correctly are huge, performance is the most common.
不知何故，你自己已经回答了你的问题。每当执行耗时的操作时使用线程是正确的选择。当你想让事情变得更快时，你也应该这样做。例如，您想要处理一定数量的文件 - 每个文件可以由不同的线程处理。
通过使用线程，您可以更好地利用多核/处理器机器的能力。
在应用程序的后台监视一些数据。
这样的场景有几十种。
Somehow you have answered your question by yourself. Using threads whenever you execute time consuming operations is right choice. Also you should it in situations when you want to make things faster. For example you want to process some amount of files - each file can be processed by different thread.
By using threads you can better utilize power of multi-core/processor machines.
Monitoring some data in background of your application.
There are dozens of such scenarios.
意识到我的评论可能足以作为答案......
我喜欢从资源角度查看多线程场景。换句话说，UI（图形）、网络、磁盘 IO、CPU（核心）、RAM 等。我发现这至少有助于决定在何处使用一般意义上的多线程。
其背后的原因很简单，我可以利用特定线程（例如磁盘 IO）上的一种资源，同时使用另一个线程使用不同的资源完成其他任务。
Realising my comment might suffice as an answer ...
I like to view multi-threading scenarios from a resource perspective. In other words, UI (graphics), networking, disk IO, CPU (cores), RAM etc. I find that helps when deciding where to use multi-threading in the general sense at least.
The reasoning behind this is simply that I can take advantage of one resource on a specific thread (eg. Disk IO) while at the same time using another thread to accomplish something else using a different resource.