很简单——当您想重写父类中出现的方法时，使用@Override注释来进行正确的重写。如果你没有正确地覆盖它，编译器会警告你。

我总是使用标签。它是一个简单的编译时标志，用于捕捉我可能犯的小错误。

它会捕获tostring()而不是tostring()

小事情有助于大项目。

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

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

使用@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

我每次都用。它提供了更多的信息，当我在一年后重新访问代码时，我可以快速弄清楚发生了什么，而我已经忘记了我第一次想的是什么。

这里有很多好的答案，所以让我提供另一种看待它的方式……

编码时没有多余的东西。输入@override不需要花费任何成本，但是如果您拼写错了方法名或签名稍有错误，节省的成本可能是巨大的。

可以这样想:在你浏览这里并输入这篇文章的时间里，你所花费的时间比你余生输入@override的时间还要多;但是它防止的一个错误可以节省你的时间。

Java尽其所能确保您在编辑/编译时不会犯任何错误，这是一种几乎免费的方法来解决整个类型的错误，这些错误在全面测试之外的任何其他方法都无法预防。

你能在Java中提出一种更好的机制来确保当用户想要重写一个方法时，他实际上做到了吗?

另一个巧妙的效果是，如果您不提供注释，它将在编译时警告您不小心覆盖了父方法——如果您不打算这样做，这可能会很重要。

在实现接口方法时使用@Override完全没有意义。在这种情况下使用它没有任何好处——编译器已经发现了你的错误，所以这只是不必要的混乱。