静态方法、变量、块或嵌套类属于整个类而不是对象。

Java中的方法用于公开对象/类的行为。在这里，由于方法是静态的(即静态方法仅用于表示类的行为)，改变/覆盖整个类的行为将违反面向对象编程的基本支柱之一，即高内聚。(记住构造函数在Java中是一种特殊的方法。)

高内聚性——一个类应该只有一个角色。例如:car类应该只生成汽车对象，而不生成自行车、卡车、飞机等。但是Car类可能有一些只属于它自己的特性(行为)。

因此，在设计java编程语言时。语言设计者认为，只有通过使方法本质上是静态的，才能允许开发人员保留类的某些行为。

下面的代码尝试覆盖静态方法，但不会遇到任何编译错误。

public class Vehicle {
static int VIN;

public static int getVehileNumber() {
    return VIN;
}}

class Car extends Vehicle {
static int carNumber;

public static int getVehileNumber() {
    return carNumber;
}}

这是因为，在这里我们没有重写一个方法，而只是重新声明它。Java允许重新声明一个方法(静态/非静态)。

从Car类的getVehileNumber()方法中删除静态关键字将导致编译错误，因为，我们正在尝试改变只属于Vehicle类的静态方法的功能。

此外，如果getVehileNumber()被声明为final，那么代码将无法编译，因为final关键字限制程序员重新声明方法。

public static final int getVehileNumber() {
return VIN;     }

总的来说，这取决于软件设计人员在哪里使用静态方法。 我个人更喜欢使用静态方法来执行某些操作，而不需要创建类的任何实例。第二，对外界隐藏一个类的行为。

重写依赖于类的实例。多态性的意义在于，您可以子类化一个类，而实现这些子类的对象对于父类中定义的相同方法将具有不同的行为(并且在子类中被重写)。静态方法不与类的任何实例相关联，因此这个概念不适用。

There were two considerations driving Java's design that impacted this. One was a concern with performance: there had been a lot of criticism of Smalltalk about it being too slow (garbage collection and polymorphic calls being part of that) and Java's creators were determined to avoid that. Another was the decision that the target audience for Java was C++ developers. Making static methods work the way they do had the benefit of familiarity for C++ programmers and was also very fast, because there's no need to wait until runtime to figure out which method to call.

通过重写，可以实现动态多态。 当您说覆盖静态方法时，您试图使用的词语是矛盾的。

静态表示-编译时，重写用于动态多态性。 两者在性质上是相反的，因此不能同时使用。

动态多态行为发生在程序员使用对象并访问实例方法时。JRE将根据您使用的对象类型映射不同类的不同实例方法。

当你说覆盖静态方法时，我们将使用类名访问静态方法，它将在编译时被链接，因此没有在运行时将方法与静态方法链接的概念。因此，术语“重写”静态方法本身没有任何意义。

注意:即使你用一个对象访问一个类方法，java编译器仍然有足够的智能来发现它，并会做静态链接。

I like and double Jay's comment (https://stackoverflow.com/a/2223803/1517187). I agree that this is the bad design of Java. Many other languages support overriding static methods, as we see in previous comments. I feel Jay has also come to Java from Delphi like me. Delphi (Object Pascal) was one of the languages implementing OOP before Java and one of the first languages used for commercial application development. It is obvious that many people had experience with that language since it was in the past the only language to write commercial GUI products. And - yes, we could in Delphi override static methods. Actually, static methods in Delphi are called "class methods", while Delphi had the different concept of "Delphi static methods" which were methods with early binding. To override methods you had to use late binding, declare "virtual" directive. So it was very convenient and intuitive and I would expect this in Java.

Well... the answer is NO if you think from the perspective of how an overriden method should behave in Java. But, you don't get any compiler error if you try to override a static method. That means, if you try to override, Java doesn't stop you doing that; but you certainly don't get the same effect as you get for non-static methods. Overriding in Java simply means that the particular method would be called based on the run time type of the object and not on the compile time type of it (which is the case with overriden static methods). Okay... any guesses for the reason why do they behave strangely? Because they are class methods and hence access to them is always resolved during compile time only using the compile time type information. Accessing them using object references is just an extra liberty given by the designers of Java and we should certainly not think of stopping that practice only when they restrict it :-)

示例:让我们试着看看如果我们尝试重写一个静态方法会发生什么:-

class SuperClass {
// ......
public static void staticMethod() {
    System.out.println("SuperClass: inside staticMethod");
}
// ......
}

public class SubClass extends SuperClass {
// ......
// overriding the static method
public static void staticMethod() {
    System.out.println("SubClass: inside staticMethod");
}

// ......
public static void main(String[] args) {
    // ......
    SuperClass superClassWithSuperCons = new SuperClass();
    SuperClass superClassWithSubCons = new SubClass();
    SubClass subClassWithSubCons = new SubClass();

    superClassWithSuperCons.staticMethod();
    superClassWithSubCons.staticMethod();
    subClassWithSubCons.staticMethod();
    // ...
}
}

输出: SuperClass:在staticMethod内部 SuperClass:在staticMethod内部 子类:staticMethod内部

注意输出的第二行。如果staticMethod被重写，这一行应该与第三行相同，因为我们在运行时类型的对象上调用'staticMethod()'作为'子类'而不是'超类'。这证实了静态方法总是只使用它们的编译时类型信息进行解析。

一般来说，允许“重写”静态方法是没有意义的，因为没有好的方法来确定在运行时调用哪个方法。以Employee为例，如果我们调用regularemploee . getbonusmultiplier()——应该执行哪个方法?

以Java为例，人们可以想象这样一种语言定义:只要静态方法是通过对象实例调用的，就可以“覆盖”它们。然而，这样做只是重新实现常规的类方法，在没有真正带来任何好处的情况下为语言增加冗余。