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