什么时候在应用程序中使用线程？例如，在简单的CRUD操作中，使用smtp，调用web服务，如果服务器面临带宽问题，可能需要一些时间等等。
说实话，我不知道如何确定我是否需要使用一个线程（我知道它必须是在我们除了操作需要花费一些时间之后）。
这可能是一个“noob”问题，但如果你与我分享你的线程经验会很棒。
由于
答案 0 :(得分：8)
我在您的问题中添加了C＃和.NET标记，因为您在标题中提到了C＃。如果不准确，请随意删除标签。
有多种不同的多线程风格。例如，存在具有回调函数的异步操作。 .NET 4引入了并行Linq库。您将使用的多线程样式，或者是否使用任何样式，取决于您要完成的任务。
并行执行，例如Linq通常会尝试做的事情，利用多个处理器内核执行不需要等待彼此数据的指令。在Linq之外有许多此类算法的来源，例如this。但是，并行执行可能不适合您，或者它不适合您的应用程序。
更传统的多线程利用了System.Thread提供的.NET库中的线程（在本例中）。请记住，在线程上启动进程时会有一些开销，因此只有在这样做的优点超过此开销时才使用线程。一般来说，当线程下运行的任务有很长的间隙时，您只希望使用这种类型的单处理器多线程，处理器可以在其中执行其他操作。例如，来自硬盘的I / O（以及因此来自使用一个的数据库系统）比内存访问慢很多个数量级。作为另一个例子，网络访问也可能很慢。多线程可以允许另一个进程在等待这些缓慢（与处理器相比）操作完成时运行。
我使用传统多线程的另一个例子是在会话中第一次访问特定的ASP.NET页面时缓存一些值。我开始一个线程，以便用户在与页面交互之前不必等待缓存完成。我还规定了在用户请求另一个页面之前未完成缓存的行为，这样，如果缓存没有完成，则不会出现问题。它只是让一些进一步的请求更快，而以前太慢了。
还要考虑多线程对应用程序可维护性的影响。例如，线程应用程序可能更难调试。
我希望至少在某种程度上回答你的问题。
答案 1 :(得分：1)
当您需要不同的执行路径时，可以使用线程。这导致（如果正确完成）更响应和/或更快的应用程序，但也会导致更复杂的代码和调试。
在一个简单的CRUD场景中，可能没那么有用，但是你的UI可能正在使用慢速的Web服务。如果您的代码与您的UI线程绑定，那么您将在服务调用之间没有响应的UI。
在这种情况下，使用System.Threading.Threads可能过度，因为你不需要那么多的控制。使用BackgrounWorker可能是更好的选择。
线程难以掌握，但正确使用时的好处是巨大的，性能是最常见的。
答案 2 :(得分：1)
约瑟夫·阿尔巴哈里总结得非常好here：
答案 3 :(得分：0)
使用线程的一个原因是在大量CPU /核心上拆分大型CPU绑定任务，以便更快地完成。另一个是让扩展任务异步执行，因此前台在运行时可以保持响应。
你的例子似乎集中在其中的第二个。虽然这可能是一个很好的理由，但如果你可以使用异步I / O，那通常是可取的（例如，几乎所有使用套接字的东西都可以/最好是异步使用套接字）。异步I / O更容易取消，并且通常也会降低CPU开销。
答案 4 :(得分：0)
不知何故，你自己已经回答了你的问题。在执行耗时的操作时使用线程是正确的选择。在你想要加快速度的情况下也应该这样做。例如，您想要处理一些文件 - 每个文件可以由不同的线程处理。
通过使用线程，您可以更好地利用多核/处理器机器的功能。
在应用程序的后台监控某些数据。
有很多这样的场景。
答案 5 :(得分：0)
实现我的评论可能足以作为答案...
我喜欢从资源角度查看多线程场景。换句话说，UI（图形），网络，磁盘IO，CPU（内核），RAM等等。我发现在确定至少在一般意义上使用多线程的位置时会有所帮助。
这背后的原因很简单，我可以利用特定线程上的一个资源（例如磁盘IO），同时使用另一个线程来使用不同的资源完成其他任务。