我有一个C＃winform应用程序。它有许多不同功能的形式。这些表单包装到WCF服务。例如
form1持续调用serviceMethod1并更新结果
form2持续调用serviceMethod2并更新结果
调用是在每个表单的不同线程中进行的，但由于我们有很多表单，因此最终会有太多线程。这很糟糕，为什么？鉴于我的情况，有没有办法避免这种情况？
此致
答案 0 :(得分：4)
你在谈论多少个主题？如果你有很多线程，你会因为上下文切换而失去一点性能 - 但实际上我不希望这会成为一个重大的问题，直到你有很多它们。
一种替代方法是使用Timer（听起来像System.Timers.Timer或System.Threading.Timer最合适） - 安排定期进行每次服务调用，并且计时器将使用线程池来触发调用。我怀疑，虽然你说你“连续”调用这些服务，但你实际上是指你经常这样做 - 这正是计时器有用的情况。
答案 1 :(得分：1)
坦率地回答这个问题：这完全取决于操作系统和应用程序设计，但这个问题可能表明程序设计存在缺陷。
详情： 您希望了解目标体系结构/操作系统上线程的分配要求，以及保持线程相对繁忙/避免轮询，并在您确实拥有大量线程时正确配置优先级。 “很多”线程可能是8（或更少，如果忙），或者如果他们的工作量相对较少，则为100+，最终取决于您的需求和设计。
作为一些测试/对象/操作的测试，我使用了100多个，有时超过1000个工作线程。没有爆炸发生，但我从来没有真正的需要那些操作 在运送应用程序中并行（除非上述程序在非常特殊的情况下使用）将实际实现放入某个集中式任务管理器更有意义。如果您有时间关键/实时应用程序，那么这些任务在另一个线程上可能是最好的。如果它们是短暂的，请考虑一个线程池..好吧，有很多方法可以攻击很多问题类......
答案 2 :(得分：1)
在Visual Studio中，添加Web引用时，可以选中“生成异步操作”以生成异步代理。
答案 3 :(得分：0)
虽然线程花费大部分时间等待服务器响应 - 但即使数百个线程也不太可能降低性能（CPU方式）。否则，在先前的更新完成时使用线程池并对“请求和更新表单”任务进行排队。
更重要的问题可能是加载具有太多同时请求的服务。
答案 4 :(得分：0)
作为一般规则，通过拥有比CPU内核更多的线程，您将无法获得任何收益。一般规则有例外，但我怀疑它们适用于您的情况。
从操作系统的角度来看，线程不再是以前的轻量级东西，而是几乎与完整流程一样昂贵。正确实现线程同步不是一项简单的任务，调试多线程应用程序比单线程应用程序要困难得多。
答案 5 :(得分：0)
使用绿色线程，这不是问题。绿色线程是一种虚拟线程，这是Java和C＃通常会得到的。
许多应用程序中线程的好处不是要处理更多的数字，而是要允许很多事情同时具有良好的响应性，因此拥有大量线程对于某些事情非常有用，并且不会总是有任何实际成本。