我是一名Java程序员，刚进入企业界。最近我用Groovy和Java开发了一个应用程序。在我编写的所有代码中，都使用了相当多的静态元素。高级技术人员要求我减少使用的静态数据的数量。我在谷歌上搜索过相同的内容，我发现许多程序员都相当反对使用静态变量。
我发现静态变量使用起来更方便。而且我假定它们也是有效的(如果我错了请纠正我)，因为如果我必须在一个类中对一个函数进行10,000次调用，我将很高兴使方法静态，并在其上使用直接的class . methodcall()，而不是用10,000个类实例使内存混乱，对吗?
此外，静态减少了对代码其他部分的相互依赖。他们可以作为完美的国家持有者。除此之外，我还发现一些语言(如Smalltalk和Scala)广泛地实现了静态。那么为什么程序员普遍反对静态(尤其是在Java世界中)呢?
PS:如果我对静态数据的假设是错误的，请纠正我。
当前回答
以上所有答案都说明了为什么静态方法很糟糕。它们是邪恶的原因是因为它给人一种错误的印象，即你在编写面向对象的代码，而事实上你并不是。 这简直是邪恶。
其他回答
我玩过很多静力学，我可以给你一个稍微不同的答案——或者可能是稍微不同的看待它的方式吗?
当我在一个类中使用静态(成员和方法)时，我最终开始注意到我的类实际上是两个分担责任的类——“静态”部分很像单例，而非静态部分(普通类)。据我所知，你可以通过为一个类选择所有静态类，为另一个类选择所有非静态类来完全分离这两个类。
当我在一个类中有一个静态集合，其中包含类的实例和一些静态方法来管理集合时，这种情况经常发生。一旦你思考一下，很明显你的类不是在做“一件事”，它是一个集合，做一些完全不同的事情。
现在，让我们稍微重构一下这个问题:如果你把你的类分成一个类，其中所有的东西都是静态的，而另一个类只是一个“普通类”，然后忘记“普通类”，那么你的问题就变成了纯静态类vs单例，这是在这里详细讨论的(可能还有其他十几个问题)。
在我看来，这与性能无关，而是与设计有关。我不认为使用静态方法和使用静态变量是错误的(但我猜你实际上是在谈论方法调用)。
它只是关于如何分离逻辑并给它一个好的位置。有时这证明使用静态方法是正确的，java.lang.Math就是一个很好的例子。我认为，当您将大多数类命名为XxxUtil或Xxxhelper时，您最好重新考虑您的设计。
静态变量表示全局状态。这很难推理，也很难测试:如果我创建了一个对象的新实例，我就可以在测试中推理它的新状态。如果我使用使用静态变量的代码，它可以处于任何状态-任何东西都可以修改它。
我还可以继续讲很久，但更重要的概念是，事物的范围越窄，就越容易进行推理。我们擅长思考小事，但如果没有模块化，就很难推断出百万行系统的状态。顺便说一下，这适用于各种各样的东西——不仅仅是静态变量。
假设您有一个拥有许多用户的应用程序，并且您已经定义了一个静态函数，该函数将状态保存在一个静态变量中，那么每个用户都将修改其他用户的状态。
我只是对回答中的一些观点进行了总结。如果你发现任何错误，请随时改正。
伸缩性:每个JVM只有一个静态变量实例。假设我们正在开发一个图书馆管理系统，我们决定将book的名称作为一个静态变量，因为每本书只有一个。但是如果系统增长了，我们使用了多个jvm，那么我们就没有办法知道我们在处理哪本书了?
线程安全:在多线程环境中使用实例变量和静态变量都需要控制。但对于实例变量，它不需要保护，除非它在线程之间显式地共享，但对于静态变量，它总是由进程中的所有线程共享。
测试:虽然可测试的设计并不等于好的设计，但我们很少会看到一个好的设计是不可测试的。由于静态变量代表全局状态，因此测试它们非常困难。
关于状态的推理:如果我创建一个类的新实例，那么我们可以推理这个实例的状态，但如果它有静态变量，那么它可以处于任何状态。为什么?因为静态变量可能已经被一些不同的实例修改过，因为静态变量是跨实例共享的。
序列化:序列化也不能很好地与它们一起工作。
创建和销毁:静态变量的创建和销毁是无法控制的。通常它们在程序加载和卸载时被创建和销毁。这意味着它们不利于内存管理，还会在启动时增加初始化时间。
但如果我们真的需要它们呢?
但有时我们可能真的需要它们。如果我们真的觉得需要在应用程序中共享许多静态变量，那么一种选择是使用单例设计模式，它将拥有所有这些变量。或者我们可以创建一些对象，它有这些静态变量，可以被传递。
同样，如果静态变量被标记为final，它就变成了一个常量，赋给它一次的值就不能改变了。这意味着它将把我们从由于其可变性而面临的所有问题中拯救出来。
