它所做的另一件事是，当读取代码时，它会更明显地改变父类的行为。这有助于调试。

此外，在Joshua Block的著作《Effective Java》(第二版)中，第36项详细介绍了注释的好处。

仅用于方法声明。 指示带注释的方法 声明覆盖声明 在超类型。

如果持续使用，它可以保护您免受大量恶意漏洞的侵害。

使用@Override注释来避免这些错误: (在以下代码中发现错误:)

public class Bigram {
    private final char first;
    private final char second;
    public Bigram(char first, char second) {
        this.first  = first;
        this.second = second;
    }
    public boolean equals(Bigram b) {
        return b.first == first && b.second == second;
    }
    public int hashCode() {
        return 31 * first + second;
    }

    public static void main(String[] args) {
        Set<Bigram> s = new HashSet<Bigram>();
        for (int i = 0; i < 10; i++)
            for (char ch = 'a'; ch <= 'z'; ch++)
                s.add(new Bigram(ch, ch));
        System.out.println(s.size());
    }
}

来源:Effective Java

我认为它在编译时提醒大家，该方法的目的是重写父方法。举个例子:

protected boolean displaySensitiveInformation() {
  return false;
}

您将经常看到类似上述方法的内容，它覆盖基类中的方法。这是该类的一个重要实现细节——我们不希望显示敏感信息。

假设这个方法在父类中被更改为

protected boolean displaySensitiveInformation(Context context) {
  return true;
}

此更改不会导致任何编译时错误或警告-但它完全改变了子类的预期行为。

回答您的问题:如果在超类中缺少具有相同签名的方法，则表明存在错误，则应该使用@Override注释。

我认为最好在允许的情况下编写@override。它有助于编码。然而，需要注意的是，对于ecipse Helios，无论是sdk 5还是6，都允许为实现的接口方法使用@override注释。对于Galileo，无论是5还是6，@override注释都不允许。

接口实现上的@Override是不一致的，因为在java中没有“覆盖接口”这样的事情。

@Override on interface implementation is useless since in practise it catches no bugs that the compilation wouldn't catch anyway. There is only one, far fetched scenario where override on implementers actually does something: If you implement an interface, and the interface REMOVES methods, you will be notified on compile time that you should remove the unused implementations. Notice that if the new version of the interface has NEW or CHANGED methods you'll obviously get a compile error anyways as you're not implementing the new stuff.

在1.6中不应该允许接口实现@Override，而不幸的是，eclipse选择自动插入注释作为默认行为，我们得到了大量杂乱的源文件。在阅读1.6代码时，您无法从@Override注释中看出一个方法实际上覆盖了超类中的一个方法，还是仅仅实现了一个接口。

在重写超类中的方法时使用@Override是可以的。

最好将它用于打算重写的每个方法，以及Java 6+，用于打算作为接口实现的每个方法。

首先，它会在编译时捕获像“hashcode()”而不是“hashcode()”这样的拼写错误。当真正的原因是您的代码从未被调用时，调试为什么您的方法的结果似乎与您的代码不匹配可能会令人困惑。

同样，如果一个超类改变了一个方法签名，旧签名的重写就会被“孤立”，留下令人困惑的死代码。@Override注释将帮助您识别这些孤儿，以便对它们进行修改以匹配新签名。