使用@Override注释可以在编译时防止常见的编程错误。它会抛出一个编译错误，如果你在一个方法上有注释，而你实际上没有重写超类方法。

最常见的情况是，当您更改基类中的一个方法以拥有一个不同的参数列表时，这是有用的。子类中用于覆盖超类方法的方法将不再这样做，因为方法签名已更改。这有时会导致奇怪和意外的行为，特别是在处理复杂的继承结构时。@Override注释可以防止这种情况。

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

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

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

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

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

protected boolean displaySensitiveInformation() {
  return false;
}

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

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

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

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

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

注释确实为编译器提供了关于代码的元数据，当我们重写基类的任何方法时，注释@Override用于继承的情况。它只是告诉编译器你正在重写方法。它可以避免一些常见的错误，如没有遵循正确的方法签名或在方法名称上出错等。所以使用@Override注释是一个很好的实践。

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