Static variables are generally considered bad because they represent global state and are therefore much more difficult to reason about. In particular, they break the assumptions of object-oriented programming. In object-oriented programming, each object has its own state, represented by instance (non-static) variables. Static variables represent state across instances which can be much more difficult to unit test. This is mainly because it is more difficult to isolate changes to static variables to a single test.

也就是说，区分常规静态变量(通常被认为是不好的)和最终静态变量(AKA常量;还不错)。

如果我必须在一个类中对一个函数进行10,000次调用，我会 很高兴使方法静态和使用直接 使用class.methodCall()来代替内存中10,000的混乱 类的实例，对吧?

您必须平衡将数据封装到具有状态的对象中的需求，以及简单地计算某些数据上的函数的结果的需求。

此外，静态减少了对代码其他部分的相互依赖。

封装也是如此。在大型应用程序中，静态方法往往会产生意大利面条式的代码，并且不容易进行重构或测试。

其他答案也为反对过度使用静态数据提供了很好的理由。

一切(可以:)都有它的目的，如果你有一堆线程，需要共享/缓存数据和所有可访问的内存(所以你不分裂成上下文在一个JVM)静态是最好的选择->当然你可以强制只有一个实例，但为什么? 我发现这个帖子里的一些评论是邪恶的，不是静态的;)

静态变量最重要的是会造成数据安全性问题(任何时间更改，任何人都可以更改，直接访问而不需要对象等)。

欲了解更多信息，请阅读这篇文章 谢谢。

静态变量表示全局状态。这很难推理，也很难测试:如果我创建了一个对象的新实例，我就可以在测试中推理它的新状态。如果我使用使用静态变量的代码，它可以处于任何状态-任何东西都可以修改它。

我还可以继续讲很久，但更重要的概念是，事物的范围越窄，就越容易进行推理。我们擅长思考小事，但如果没有模块化，就很难推断出百万行系统的状态。顺便说一下，这适用于各种各样的东西——不仅仅是静态变量。

我的美元。这些答案中有几个混淆了这个问题，而不是说“静态是坏的”，我认为更好的是谈论范围和实例。

我想说的是，静态变量是一个“类”变量——它表示一个值，该值在该类的所有实例中共享。通常情况下，它也应该以这种方式确定作用域(对类及其实例进行保护或私有)。

如果您计划在它周围放置类级行为，并将其暴露给其他代码，那么单例可能是未来支持更改的更好解决方案(正如@Jessica所建议的那样)。这是因为您可以在实例/单例级别使用无法在类级别使用的接口——特别是继承。

关于为什么我认为其他答案中的某些方面不是问题的核心……

静态数据不是“全局的”。在Java中，作用域与静态/实例是分开控制的。

并发性对于静态方法的危险并不比实例方法小。它仍然是需要保护的州。当然，你可能有1000个实例，每个实例变量只有一个静态变量，但如果访问它们的代码不是以线程安全的方式编写的，你仍然会被搞砸——只是你可能需要更长的时间才能意识到这一点。

管理生命周期是一个有趣的论点，但我认为它不那么重要。我不明白为什么管理一对类方法(如init()/clear())比创建和销毁一个单例实例更难。事实上，有些人可能会说，由于GC的存在，单例更复杂一些。

PS，就Smalltalk而言，它的许多方言确实有类变量，但在Smalltalk中，类实际上是元类的实例，所以它们实际上是元类实例上的变量。尽管如此，我还是会运用同样的经验法则。如果它们被用于跨实例的共享状态，那么ok。如果它们支持公共功能，你应该考虑单例。唉，我真的很想念Smalltalk....