我是一名Java程序员，刚进入企业界。最近我用Groovy和Java开发了一个应用程序。在我编写的所有代码中，都使用了相当多的静态元素。高级技术人员要求我减少使用的静态数据的数量。我在谷歌上搜索过相同的内容，我发现许多程序员都相当反对使用静态变量。
我发现静态变量使用起来更方便。而且我假定它们也是有效的(如果我错了请纠正我)，因为如果我必须在一个类中对一个函数进行10,000次调用，我将很高兴使方法静态，并在其上使用直接的class . methodcall()，而不是用10,000个类实例使内存混乱，对吗?
此外，静态减少了对代码其他部分的相互依赖。他们可以作为完美的国家持有者。除此之外，我还发现一些语言(如Smalltalk和Scala)广泛地实现了静态。那么为什么程序员普遍反对静态(尤其是在Java世界中)呢?
PS:如果我对静态数据的假设是错误的，请纠正我。
当前回答
我的美元。这些答案中有几个混淆了这个问题，而不是说“静态是坏的”，我认为更好的是谈论范围和实例。
我想说的是，静态变量是一个“类”变量——它表示一个值，该值在该类的所有实例中共享。通常情况下，它也应该以这种方式确定作用域(对类及其实例进行保护或私有)。
如果您计划在它周围放置类级行为，并将其暴露给其他代码，那么单例可能是未来支持更改的更好解决方案(正如@Jessica所建议的那样)。这是因为您可以在实例/单例级别使用无法在类级别使用的接口——特别是继承。
关于为什么我认为其他答案中的某些方面不是问题的核心……
静态数据不是“全局的”。在Java中，作用域与静态/实例是分开控制的。
并发性对于静态方法的危险并不比实例方法小。它仍然是需要保护的州。当然，你可能有1000个实例，每个实例变量只有一个静态变量，但如果访问它们的代码不是以线程安全的方式编写的，你仍然会被搞砸——只是你可能需要更长的时间才能意识到这一点。
管理生命周期是一个有趣的论点，但我认为它不那么重要。我不明白为什么管理一对类方法(如init()/clear())比创建和销毁一个单例实例更难。事实上，有些人可能会说，由于GC的存在，单例更复杂一些。
PS，就Smalltalk而言，它的许多方言确实有类变量，但在Smalltalk中，类实际上是元类的实例，所以它们实际上是元类实例上的变量。尽管如此，我还是会运用同样的经验法则。如果它们被用于跨实例的共享状态，那么ok。如果它们支持公共功能，你应该考虑单例。唉，我真的很想念Smalltalk....
其他回答
我发现静态变量使用起来更方便。而且我认为它们也很有效(如果我错了请纠正我)，因为如果我必须在一个类中对一个函数进行10,000次调用，我很乐意将方法设置为静态的，并在其上使用直接的class. methodcall()，而不是用10,000个类实例来混乱内存，对吗?
我明白你的想法，但一个简单的单例模式将做同样的事情，而不必实例化10,000个对象。
可以使用静态方法，但只能用于与对象域相关且不需要或使用对象的内部属性的函数。
ex:
public class WaterContainer {
private int size;
private int brand;
...etc
public static int convertToGallon(int liters)...
public static int convertToLiters(int gallon)...
}
静态变量本身并没有什么问题。只是Java语法有问题。每个Java类实际上定义了两个结构——一个封装静态变量的单例对象和一个实例。在同一个源代码块中定义这两种代码是非常糟糕的，会导致代码难以阅读。Scala做得很好。
在我看来，你是在问静态变量，但你也在你的例子中指出了静态方法。
静态变量并不是邪恶的——它们被采用为全局变量，就像大多数情况下与最终修饰符结合的常量一样，但正如它所说的，不要过度使用它们。
静态方法又名实用方法。使用它们通常不是一个坏的做法，但主要的问题是它们可能阻碍测试。
作为一个伟大的java项目的例子，使用了大量的静态和做它的正确方式，请看看Play!框架。在SO中也有关于它的讨论。
与静态导入相结合的静态变量/方法也被广泛应用于方便java中声明性编程的库中，如:make it easy或Hamcrest。如果没有大量的静态变量和方法，这是不可能的。
所以静态变量(和方法)很好，但要明智地使用它们!
有人可能会建议，在使用静态变量的大多数情况下，您确实希望使用单例模式。
全局状态的问题在于，有时在简单的上下文中作为全局是有意义的，但在实际的上下文中需要更加灵活，这就是单例模式变得有用的地方。
总结在Java中使用静态方法的几个基本优点和缺点:
优点:
全局可访问，即不与任何特定的对象实例绑定。 每个JVM一个实例。 可以通过类名访问(不需要对象)。 包含一个适用于所有实例的值。 在JVM启动时加载，并在JVM关闭时死亡。 它们不会修改Object的状态。
缺点:
Static members are always part of memory whether they are in use or not. You can not control creation and destruction of static variable. Usefully they have been created at program loading and destroyed when program unload (or when JVM shuts down). You can make statics thread safe using synchronize but you need some extra efforts. If one thread change value of a static variable that can possibly break functionality of other threads. You must know “static“ before using it. You cannot override static methods. Serialization doesn't work well with them. They don't participate in runtime polymorphism. There is a memory issue (to some extent but not much I guess) if a large number of static variables/methods are used. Because they will not be Garbage Collected until program ends. Static methods are hard to test too.
