我正在编写一个对我的 GUI 进行多次修改的应用程序，尽管两个点永远不会访问 GUI 线程的同一部分。该应用程序本身是完全线程安全的，并且很容易理解和理解原因（我有一个修改 GUI 的调用程序，其余修改外部类对象，这些对象又被 GUI 控制线程抓取 - 避免锁定。 )
我想知道的是，我应该走多远？我的意思是，每次我添加一个线程都是因为我的 GUI 变得无响应，但我是一名软件测试人员，所以这可能与我无法等待半秒钟来刷新 GUI 有关。
那么，对于小型应用程序来说，多少线程才是合理的数量呢？我应该将自己限制在一定数量吗？还是我应该发疯，让我的 GUI 变得流畅，并且我喜欢......我想这里真正的问题，有答案的问题，是这样的：
尽可能使用多线程是否有效，或者使用过多线程是否有害，或者是否应该仔细平衡以产生高效但有效的应用程序？
谢谢
清楚地理解异步编程和线程之间的区别很重要。Windows 窗体应用程序在单线程单元中运行，但它们仍然可以通过在 Windows 消息队列上调度任务来执行异步操作。因此，操作可以异步执行，而不一定需要线程。线程并不总是（也许不经常）处理异步的最佳方式。
你应该有多少线程？棘手。启动线程是一项相对昂贵的操作，它也需要相当多的内存，每个线程大约 1 Mb 来存储线程的堆栈和其他内务处理。有一种观点认为，线程数量超过可用于运行它们的 CPU 数量是没有意义的，最好的情况是每个 CPU 内核一个线程。不仅如此，还会导致不必要的上下文切换和内存使用。很容易找到使用许多线程占用 0% CPU 的程序示例 - 例如，在我现在的系统上，Windows Explorer 使用 69 个线程完全没有做任何事情。当我只有双核 CPU 时，很难想象为什么 Explorer 需要 69 个线程。由于您不知道您的程序在运行时将有多少个内核可用，或者系统上的其他程序会做什么，那么你就无法做出任何假设。答案总是“视情况而定”。
.NET Framework 提供了一种称为线程池的东西，它使您不必担心要创建多少线程，因为线程池会处理所有这些。最好从任务的角度来考虑，通过任务队列提交到线程池。线程池从队列中获取任务并在资源可用时执行它们。这使您可以维护响应式 UI，而不必担心管理线程。理论上。.NET 将为运行它的系统优化线程池。
Jeff Richter 在他的书CLR via C#中有一些很好的信息。
您应该查看MVC 模型。我知道 C# 中 Windows 的常用框架并没有强制执行这一点，但如果您可以将数据与展示区分开，修改它会变得容易得多。
同样对于线程数......我倾向于尽可能避免它们，但这并不总是可能的。它会导致各种同步问题、竞争条件和死锁，这些问题很难弄清楚和正确调试。