关键字super只是在超类中调用方法的一种方法。 在Java教程中:https://docs.oracle.com/javase/tutorial/java/IandI/super.html

如果您的方法覆盖了它的父类的方法之一，您可以通过使用关键字super调用被覆盖的方法。

不要相信这是一个超对象的引用!!不，它只是在超类中调用方法的关键字。

这里有一个例子:

class Animal {
    public void doSth() {
        System.out.println(this);   // It's a Cat! Not an animal!
        System.out.println("Animal do sth.");
    }
}

class Cat extends Animal {
    public void doSth() {
        System.out.println(this);
        System.out.println("Cat do sth.");
        super.doSth();
    }
}

当你调用cat.doSth()时，类Animal中的方法doSth()将打印这个，它是一只猫。

除了其他人提出的非常好的观点之外，我认为还有另一个原因:如果超类没有超类怎么办?

因为每个类都自然地扩展(至少)Object，所以super.whatever()总是引用超类中的一个方法。但是如果你的类只扩展Object呢?超级指的是什么?该如何处理该行为-编译器错误，空指针，等等?

我认为不允许这样做的主要原因是它违反了封装，但这可能也是一个小原因。

我猜，因为它不常用。我能看到使用它的唯一原因是，如果您的直接父文件覆盖了某些功能，而您试图将其恢复到原始文件。

在我看来，这似乎是违反OO原则的，因为类的直接父类应该比祖父类更接近你的类。

我认为乔恩·斯基特有正确答案。我只是想补充一点，你可以通过强制转换从超类的超类中访问阴影变量:

interface I { int x = 0; }
class T1 implements I { int x = 1; }
class T2 extends T1 { int x = 2; }
class T3 extends T2 {
        int x = 3;
        void test() {
                System.out.println("x=\t\t"          + x);
                System.out.println("super.x=\t\t"    + super.x);
                System.out.println("((T2)this).x=\t" + ((T2)this).x);
                System.out.println("((T1)this).x=\t" + ((T1)this).x);
                System.out.println("((I)this).x=\t"  + ((I)this).x);
        }
}

class Test {
        public static void main(String[] args) {
                new T3().test();
        }
}

它产生输出:

x=              3
super.x=        2
((T2)this).x=   2
((T1)this).x=   1
((I)this).x=    0

(例子来自JLS)

但是，这对方法调用不起作用，因为方法调用是基于对象的运行时类型确定的。

我会把超级。如果可能的话，超级方法主体放在另一个方法中

class SuperSuperClass {
    public String toString() {
        return DescribeMe();
    }

    protected String DescribeMe() {
        return "I am super super";
    }
}

class SuperClass extends SuperSuperClass {
    public String toString() {
        return "I am super";
    }
}

class ChildClass extends SuperClass {
    public String toString() {
        return DescribeMe();
    }
}

或者如果你不能改变超超类，你可以试试这个:

class SuperSuperClass {
    public String toString() {
        return "I am super super";
    }
}

class SuperClass extends SuperSuperClass {
    public String toString() {
        return DescribeMe(super.toString());
    }

    protected String DescribeMe(string fromSuper) {
        return "I am super";
    }
}

class ChildClass extends SuperClass {
    protected String DescribeMe(string fromSuper) {
        return fromSuper;
    }
}

在这两种情况下，

new ChildClass().toString();

结果变成“我超级超级”

我曾经遇到过这样的情况，即体系结构是在一个公共CustomBaseClass中构建公共功能，该CustomBaseClass代表几个派生类实现。 但是，我们需要规避特定派生类的特定方法的通用逻辑。在这种情况下，我们必须使用super.super.methodX实现。

我们通过在CustomBaseClass中引入一个布尔成员来实现这一点，该成员可用于有选择地推迟自定义实现，并在需要时让位于默认框架实现。

        ...
        FrameworkBaseClass (....) extends...
        {
           methodA(...){...}
           methodB(...){...}
        ...
           methodX(...)
        ...
           methodN(...){...}

        }
        /* CustomBaseClass overrides default framework functionality for benefit of several derived classes.*/
        CustomBaseClass(...) extends FrameworkBaseClass 
        {
        private boolean skipMethodX=false; 
        /* implement accessors isSkipMethodX() and setSkipMethodX(boolean)*/

           methodA(...){...}
           methodB(...){...}
        ...
           methodN(...){...}

           methodX(...){
                  if (isSkipMethodX()) {
                       setSKipMethodX(false);
                       super.methodX(...);
                       return;
                       }
                   ... //common method logic
            }
        }

        DerivedClass1(...) extends CustomBaseClass
        DerivedClass2(...) extends CustomBaseClass 
        ...
        DerivedClassN(...) extends CustomBaseClass...

        DerivedClassX(...) extends CustomBaseClass...
        {
           methodX(...){
                  super.setSKipMethodX(true);
                  super.methodX(...);
                       }
        }

然而，在框架和应用程序中遵循良好的架构原则，我们可以通过使用hasA方法而不是isA方法轻松避免这种情况。但在任何时候，期待设计良好的架构都是不现实的，因此需要摆脱坚实的设计原则，引入像这样的技巧。 这只是我的意见……