我是一名Java程序员，刚进入企业界。最近我用Groovy和Java开发了一个应用程序。在我编写的所有代码中，都使用了相当多的静态元素。高级技术人员要求我减少使用的静态数据的数量。我在谷歌上搜索过相同的内容，我发现许多程序员都相当反对使用静态变量。
我发现静态变量使用起来更方便。而且我假定它们也是有效的(如果我错了请纠正我)，因为如果我必须在一个类中对一个函数进行10,000次调用，我将很高兴使方法静态，并在其上使用直接的class . methodcall()，而不是用10,000个类实例使内存混乱，对吗?
此外，静态减少了对代码其他部分的相互依赖。他们可以作为完美的国家持有者。除此之外，我还发现一些语言(如Smalltalk和Scala)广泛地实现了静态。那么为什么程序员普遍反对静态(尤其是在Java世界中)呢?
PS:如果我对静态数据的假设是错误的，请纠正我。
当前回答
这里有很多很好的答案，
记忆: 静态变量只要类加载器存在(通常直到VM死亡)就存在，但这只是在大块对象/引用存储为静态的情况下。
模块化: 考虑IOC、依赖注入、代理等概念。所有这些都完全反对紧密耦合/静态实现。
其他缺点:线程安全性，可测试性
其他回答
不。全球国家本身并不邪恶。但我们必须看看你的代码，看看你是否正确使用了它。一个新手很有可能滥用全局状态;就像他会滥用每一种语言特性一样。
全局状态是绝对必要的。我们不能回避全球国家。我们无法避免对全球状态进行推理。-如果我们关心我们的应用程序语义。
那些为了摆脱全局状态而试图摆脱全局状态的人，最终不可避免地会得到一个更复杂的系统——全局状态仍然存在，巧妙地/愚蠢地伪装在许多层间接之下;在解开所有的间接之后，我们仍然需要推理全局状态。
就像Spring的人在xml中大量声明全局状态，并认为它在某种程度上更优越。
@Jon Skeet如果我创建一个对象的新实例，现在你有两件事要考虑——对象内部的状态，以及承载对象的环境的状态。
Static fields are de facto GC roots (see the How Garbage Collection Works section earlier in this chapter), which means they are never garbage-collected! For convenience alone, static fields and collections are often used to hold caches or share state across threads. Mutable static fields need to be cleaned up explicitly. If the developer does not consider every possibility (a near certainty), the cleanup will not take place, resulting in a memory leak. This sort of careless programming means that static fields and collections have become the most common cause of memory leaks!
简而言之，永远不要使用可变静态字段——只使用常量。如果您认为需要可变静态字段，请再三考虑!总有更合适的方法。
我的美元。这些答案中有几个混淆了这个问题，而不是说“静态是坏的”，我认为更好的是谈论范围和实例。
我想说的是，静态变量是一个“类”变量——它表示一个值，该值在该类的所有实例中共享。通常情况下，它也应该以这种方式确定作用域(对类及其实例进行保护或私有)。
如果您计划在它周围放置类级行为，并将其暴露给其他代码，那么单例可能是未来支持更改的更好解决方案(正如@Jessica所建议的那样)。这是因为您可以在实例/单例级别使用无法在类级别使用的接口——特别是继承。
关于为什么我认为其他答案中的某些方面不是问题的核心……
静态数据不是“全局的”。在Java中，作用域与静态/实例是分开控制的。
并发性对于静态方法的危险并不比实例方法小。它仍然是需要保护的州。当然，你可能有1000个实例，每个实例变量只有一个静态变量，但如果访问它们的代码不是以线程安全的方式编写的，你仍然会被搞砸——只是你可能需要更长的时间才能意识到这一点。
管理生命周期是一个有趣的论点，但我认为它不那么重要。我不明白为什么管理一对类方法(如init()/clear())比创建和销毁一个单例实例更难。事实上，有些人可能会说，由于GC的存在，单例更复杂一些。
PS，就Smalltalk而言，它的许多方言确实有类变量，但在Smalltalk中，类实际上是元类的实例，所以它们实际上是元类实例上的变量。尽管如此，我还是会运用同样的经验法则。如果它们被用于跨实例的共享状态，那么ok。如果它们支持公共功能，你应该考虑单例。唉，我真的很想念Smalltalk....
静态变量表示全局状态。这很难推理，也很难测试:如果我创建了一个对象的新实例，我就可以在测试中推理它的新状态。如果我使用使用静态变量的代码，它可以处于任何状态-任何东西都可以修改它。
我还可以继续讲很久，但更重要的概念是，事物的范围越窄，就越容易进行推理。我们擅长思考小事，但如果没有模块化，就很难推断出百万行系统的状态。顺便说一下，这适用于各种各样的东西——不仅仅是静态变量。
以上所有答案都说明了为什么静态方法很糟糕。它们是邪恶的原因是因为它给人一种错误的印象，即你在编写面向对象的代码，而事实上你并不是。 这简直是邪恶。
