我现在正在建立一个API，将被一个网络服务使用。
我在想，如果我使用大量的静态方法构建我的API，可能会遇到什么性能问题。
最初的想法是建立作为服务的专家对象。
In a single user environment this approach was great! But I will soon need to port this to a multi/concurrent user environment.
我可能会遇到什么性能问题与这种架构？
最好的问候
编辑：
静态方法没有静态变量并且没有副作用。它们只是执行一个普通的例程，在其中一切都被实例化。（例如变量和对象）
并发性没有特定的影响。相同的规则依然适用：同时更改共享数据是不好的。如果您有实例方法，但它们不会更改任何东西，那么您就没问题了。
总体设计有所不同 - 静态方法几乎总是应该是线程安全的（即您应该使它们线程安全），而实例方法通常不必是（尽管您应该记录您的类的线程安全性）。
你不必担心静态方法中的本地变量问题。每个线程都有自己的堆栈，每次调用方法都会在堆栈上创建本地变量的单独副本。例如，MS在其应用程序块中提供的SqlHelper方法使用了这种技术。
主要问题是静态变量。我几乎从未使用过静态变量，我没有这个需要。
我不会过多关注性能问题（Knuth），我会更关注测试性和在多线程环境中管理状态的问题，主要是为了减少编码和维护的复杂性，这可能比偶发的性能问题更严重地拖低项目进度。
你不能嘲笑静态方法，因此使用基于静态方法的API的代码相对于不可测试。这并不是你在问什么，但请考虑将来使用你的API的人。
你应该将线程之间共享数据的点减少到绝对最小。这会减少线程问题的机会。你可能会在这样做时失去一些效率，但在编码和维护方面会获得更多好处。想象一下，如果所有页面都是静态的，编写和测试ASP.NET应用程序会有多么困难。这会变成一场噩梦。随着你的API随着时间增加功能，你可能会发现自己走上这条路。
此外，使用一个合适的 DI 框架 (我喜欢 Unity，可能是 P&P 最好的东西之一)。
