假设您有一个拥有许多用户的应用程序，并且您已经定义了一个静态函数，该函数将状态保存在一个静态变量中，那么每个用户都将修改其他用户的状态。

我发现静态变量使用起来更方便。而且我认为它们也很有效(如果我错了请纠正我)，因为如果我必须在一个类中对一个函数进行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)...

}

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

静态变量本身并没有什么问题。只是Java语法有问题。每个Java类实际上定义了两个结构——一个封装静态变量的单例对象和一个实例。在同一个源代码块中定义这两种代码是非常糟糕的，会导致代码难以阅读。Scala做得很好。

Its not very object oriented: One reason statics might be considered "evil" by some people is they are contrary the object-oriented paradigm. In particular, it violates the principle that data is encapsulated in objects (that can be extended, information hiding, etc). Statics, in the way you are describing using them, are essentially to use them as a global variable to avoid dealing with issues like scope. However, global variables is one of the defining characteristics of procedural or imperative programming paradigm, not a characteristic of "good" object oriented code. This is not to say the procedural paradigm is bad, but I get the impression your supervisor expects you to be writing "good object oriented code" and you're really wanting to write "good procedural code".

在Java中，当您开始使用静态时，有许多并不总是立即明显的陷阱。例如，如果在同一个VM中运行两个程序副本，它们会共享静态变量的值并混淆彼此的状态吗?或者当你扩展类时会发生什么，你能重写静态成员吗?您的虚拟机内存不足，因为您有疯狂的静态数据，并且内存不能为其他需要的实例对象回收?

Object Lifetime: Additionally, statics have a lifetime that matches the entire runtime of the program. This means, even once you're done using your class, the memory from all those static variables cannot be garbage collected. If, for example, instead, you made your variables non-static, and in your main() function you made a single instance of your class, and then asked your class to execute a particular function 10,000 times, once those 10,000 calls were done, and you delete your references to the single instance, all your static variables could be garbage collected and reused.

防止某些重复使用: 此外，静态方法不能用于实现接口，因此静态方法会阻止某些面向对象的特性的可用性。

Other Options: If efficiency is your primary concern, there might be other better ways to solve the speed problem than considering only the advantage of invocation being usually faster than creation. Consider whether the transient or volatile modifiers are needed anywhere. To preserve the ability to be inlined, a method could be marked as final instead of static. Method parameters and other variables can be marked final to permit certain compiler optimiazations based on assumptions about what can change those variables. An instance object could be reused multiple times rather than creating a new instance each time. There may be compliler optimization switches that should be turned on for the app in general. Perhaps, the design should be set up so that the 10,000 runs can be multi-threaded and take advantage of multi-processor cores. If portablity isn't a concern, maybe a native method would get you better speed than your statics do.

If for some reason you do not want multiple copies of an object, the singleton design pattern, has advantages over static objects, such as thread-safety (presuming your singleton is coded well), permitting lazy-initialization, guaranteeing the object has been properly initialized when it is used, sub-classing, advantages in testing and refactoring your code, not to mention, if at some point you change your mind about only wanting one instance of an object it is MUCH easier to remove the code to prevent duplicate instances than it is to refactor all your static variable code to use instance variables. I've had to do that before, its not fun, and you end up having to edit a lot more classes, which increases your risk of introducing new bugs...so much better to set things up "right" the first time, even if it seems like it has its disadvantages. For me, the re-work required should you decide down the road you need multiple copies of something is probably one of most compelling reasons to use statics as infrequently as possible. And thus I would also disagree with your statement that statics reduce inter-dependencies, I think you will end up with code that is more coupled if you have lots of statics that can be directly accessed, rather than an object that "knows how to do something" on itself.

假设您有一个拥有许多用户的应用程序，并且您已经定义了一个静态函数，该函数将状态保存在一个静态变量中，那么每个用户都将修改其他用户的状态。