使用私有静态方法的优点

当创建一个具有内部私有方法的类（通常是为了减少代码重复）而又不需要使用任何实例字段时，将该方法声明为静态方法是否具有性能或内存优势？

例：

foreach (XmlElement element in xmlDoc.DocumentElement.SelectNodes("sample"))
{
    string first = GetInnerXml(element, ".//first");
    string second = GetInnerXml(element, ".//second");
    string third = GetInnerXml(element, ".//third");
}

...

private static string GetInnerXml(XmlElement element, string nodeName)
{
    return GetInnerXml(element, nodeName, null);
}

private static string GetInnerXml(XmlElement element, string nodeName, string defaultValue)
{
    XmlNode node = element.SelectSingleNode(nodeName);
    return node == null ? defaultValue : node.InnerXml;
}

将GetInnerXml（）方法声明为静态方法有什么好处？请没有意见回应，我有意见。

从FxCop规则页面上：

将方法标记为静态后，编译器将向这些成员发出非虚拟调用站点。发出非虚拟调用站点将阻止在运行时检查每个调用，以确保当前对象指针为非空。对于性能敏感的代码，这可以导致可衡量的性能提升。在某些情况下，无法访问当前对象实例表示正确性问题。

在编写类时，大多数方法分为两类：

• 使用/更改当前实例状态的方法。
• 不使用/更改当前对象状态的辅助方法，但可以帮助我计算其他地方需要的值。

静态方法很有用，因为仅通过查看其签名即可知道，调用它不会使用或修改当前实例的状态。

举个例子：

公共课图书馆
{
    私人静态书findBook（List <Book>书籍，字符串标题）
    {
        //代码在这里
    }
}

如果某个库的状态实例被搞砸了，而我试图找出原因，那么可以从其签名中排除findBook作为罪魁祸首。

我尝试与方法或函数的签名进行尽可能多的交流，这是实现此目的的绝佳方法。

对静态方法的调用会生成Microsoft中间语言（MSIL）的调用指令，而对实例方法的调用会生成callvirt指令，该指令还会检查空对象引用。但是，大多数情况下两者之间的性能差异并不明显。

src：MSDN- http : //msdn.microsoft.com/zh-CN/library/79b3xss3( v=vs.110) .aspx

是的，编译器不需要将隐式this指针传递给static方法。即使您没有在实例方法中使用它，它仍然会被传递。

由于没有传递此参数，因此速度会稍快一些（尽管调用该方法的性能成本可能比节省的成本高得多）。

我想说的是，对于私有静态方法而言，最好的原因是它意味着您不会偶然更改对象（因为没有此指针）。

这迫使您记住还必须声明该函数使用的所有类作用域成员都为静态成员，这应节省为每个实例创建这些项的内存。

我非常希望所有私有方法都是静态的，除非它们确实不是静态的。我更喜欢以下内容：

public class MyClass
{
    private readonly MyDependency _dependency;

    public MyClass(MyDependency dependency)
    {
        _dependency = dependency;
    }

    public int CalculateHardStuff()
    {
        var intermediate = StepOne(_dependency);
        return StepTwo(intermediate);
    }

    private static int StepOne(MyDependency dependency)
    {
        return dependency.GetFirst3Primes().Sum();
    }

    private static int StepTwo(int intermediate)
    {
        return (intermediate + 5)/4;
    }
}

public class MyDependency
{
    public IEnumerable<int> GetFirst3Primes()
    {
        yield return 2;
        yield return 3;
        yield return 5;
    }
}

所有访问实例字段的方法。为什么是这样？因为随着这种计算过程变得越来越复杂，并且该类最终使用15个私有帮助器方法，所以我真的希望能够将它们拉入一个新类，该新类以语义上有意义的方式封装步骤的子集。

当MyClass由于需要日志记录并且还需要通知Web服务而获得更多依赖关系时（请原谅示例），那么轻松查看哪些方法具有哪些依赖关系确实很有帮助。

诸如R＃之类的工具使您可以通过几次击键从一组私有静态方法中提取一个类。当所有私有帮助程序方法都与实例字段紧密耦合时，请尝试执行此操作，您会发现这很头疼。

如前所述，静态方法有很多优点。然而; 请记住，它们将在应用程序的生命周期内始终存在。我最近花了一天的时间来跟踪Windows Service中的内存泄漏...该泄漏是由实现IDisposable的类中的私有静态方法引起的，并且始终通过using语句进行调用。每次创建此类时，不幸的是，堆中为该类中的静态方法保留了内存，但是，当该类被处置时，静态方法的内存并未释放。这导致该服务的内存占用量在几天之内消耗了服务器的可用内存，并产生了可预测的结果。