我是一名Java程序员，刚进入企业界。最近我用Groovy和Java开发了一个应用程序。在我编写的所有代码中，都使用了相当多的静态元素。高级技术人员要求我减少使用的静态数据的数量。我在谷歌上搜索过相同的内容，我发现许多程序员都相当反对使用静态变量。
我发现静态变量使用起来更方便。而且我假定它们也是有效的(如果我错了请纠正我)，因为如果我必须在一个类中对一个函数进行10,000次调用，我将很高兴使方法静态，并在其上使用直接的class . methodcall()，而不是用10,000个类实例使内存混乱，对吗?
此外，静态减少了对代码其他部分的相互依赖。他们可以作为完美的国家持有者。除此之外，我还发现一些语言(如Smalltalk和Scala)广泛地实现了静态。那么为什么程序员普遍反对静态(尤其是在Java世界中)呢?
PS:如果我对静态数据的假设是错误的，请纠正我。
当前回答
不。全球国家本身并不邪恶。但我们必须看看你的代码，看看你是否正确使用了它。一个新手很有可能滥用全局状态;就像他会滥用每一种语言特性一样。
全局状态是绝对必要的。我们不能回避全球国家。我们无法避免对全球状态进行推理。-如果我们关心我们的应用程序语义。
那些为了摆脱全局状态而试图摆脱全局状态的人，最终不可避免地会得到一个更复杂的系统——全局状态仍然存在，巧妙地/愚蠢地伪装在许多层间接之下;在解开所有的间接之后，我们仍然需要推理全局状态。
就像Spring的人在xml中大量声明全局状态，并认为它在某种程度上更优越。
@Jon Skeet如果我创建一个对象的新实例，现在你有两件事要考虑——对象内部的状态，以及承载对象的环境的状态。
其他回答
我发现静态变量使用起来更方便。而且我认为它们也很有效(如果我错了请纠正我)，因为如果我必须在一个类中对一个函数进行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)...
}
以上所有答案都说明了为什么静态方法很糟糕。它们是邪恶的原因是因为它给人一种错误的印象，即你在编写面向对象的代码，而事实上你并不是。 这简直是邪恶。
这里有很多很好的答案，
记忆: 静态变量只要类加载器存在(通常直到VM死亡)就存在，但这只是在大块对象/引用存储为静态的情况下。
模块化: 考虑IOC、依赖注入、代理等概念。所有这些都完全反对紧密耦合/静态实现。
其他缺点:线程安全性，可测试性
邪恶是一个主观的术语。
你不能从创建和破坏的角度来控制静态。他们按照程序的要求生活装卸。
由于静态对象存在于一个空间中，所有希望使用它们的线程都必须通过您必须管理的访问控制。这意味着程序更加耦合，这种变化更难想象和管理(就像J Skeet说的那样)。这导致了隔离变更影响的问题，从而影响了如何管理测试。
这是我对他们的两个主要问题。
一切(可以:)都有它的目的，如果你有一堆线程，需要共享/缓存数据和所有可访问的内存(所以你不分裂成上下文在一个JVM)静态是最好的选择->当然你可以强制只有一个实例，但为什么? 我发现这个帖子里的一些评论是邪恶的，不是静态的;)
