什么时候用多线程？什么时候在应用程序中使用线程？比如简单的CRUD操作，使用smtp，调用web服务，如果服务器面临带宽问题，可能需要一些时间等。说实话，我不知道如何判断是否需要使用线程（我知道它必须是当我们除了一个操作之外的所有操作都需要一些时间才能完成的时候）。这可能是一个“菜鸟”问题，但如果您能与我分享您的线程体验，那就太好了。谢谢我在您的问题中添加了C#和.NET标签，因为您在标题中提到了C#。如果不准确，请随意删除标签。有许多不同风格的多线程。例如，有回调函数的异步操作。.NET4引入了ParallelLinq库。您将使用的多线程风格，或者您是否使用任何风格，取决于您想要完成的任务。并行执行（例如Linq通常会尝试执行的操作）利用多个处理器内核来执行不需要等待彼此数据的指令。在Linq之外有许多此类算法的来源，例如。但是，并行执行可能不适合您，或者它可能不适合您的应用程序。更传统的多线程利用System.Thread提供的.NET库（在本例中）中的System.Thread。请记住，在线程上启动进程时会产生一些开销，因此只有在这样做的好处超过此开销时才使用线程。一般来说，只有当线程下运行的任务有很长的间隙时，你才想使用这种类型的单处理器多线程，此时处理器可以做其他事情。例如，来自硬盘的I/O（因此来自使用硬盘的数据库系统）比内存访问慢很多数量级。作为另一个例子，网络访问也可能很慢。多线程可以允许另一个进程在等待这些慢速（与处理器相比）操作完成时运行。我使用的传统多线程的另一个例子是在会话中第一次访问特定ASP.NET页面时缓存一些值。我启动了一个线程，这样用户就不必在与页面交互之前等待缓存完成。我还指定了在用户请求另一个页面之前缓存未完成时的行为，这样即使缓存未完成也没有问题。它只是让一些请求更快。还要考虑多线程对应用程序可维护性的影响。例如，线程应用程序可能更难调试。我希望至少在某种程度上回答你的问题。当您需要不同的执行路径时，您可以使用线程。这会导致（如果正确完成）响应更快和/或更快的应用程序，但也会导致更复杂的代码和调试。在一个简单的CRUD场景中，可能没有那么有用，但您的UI可能正在使用缓慢的Web服务。如果您的代码绑定到您的UI线程，那么您将无法在服务调用之间响应UI。在这种情况下，使用System.Threading.Threads可能有点矫枉过正，因为您不需要那么多控制权。使用BackgrounWorker可能是更好的选择。线程很难掌握，但如果正确使用，好处是巨大的，性能是最常见的。JosephAlbahari在这里总结得很好：使用线程的一个原因是将大型CPU绑定任务拆分到大量CPU/内核上以更快地完成。另一个是让扩展任务异步执行，这样前台在运行时可以保持响应。您的示例似乎侧重于其中的第二个。虽然这可能是一个很好的理由，但如果您可以使用异步I/O，那通常是可取的（例如，几乎所有使用套接字的东西都可以/最好异步使用套接字）。异步I/O更容易取消，通常也能降低CPU开销。你自己以某种方式回答了你的问题。在执行耗时操作时，使用线程是正确的选择。如果您想加快速度，也应该这样做。例如，您要处理一些文件——每个文件都可以由不同的线程处理。通过使用线程，您可以更好地利用多核/处理器机器的功能。在应用后台监控一些数据。这样的场景有几十种。意识到我的评论可能足以作为答案......我喜欢从资源的角度来看多线程场景。换句话说，UI（图形）、网络、磁盘IO、CPU（内核）、RAM等。我觉得至少在决定在一般意义上使用多线程方面有帮助。这背后的原因很简单，我可以在特定线程上使用一种资源（例如磁盘IO），同时使用另一个线程使用不同资源执行其他任务。以上就是C#学习教程：什么时候用多线程？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
