Answers:
每次您重写一种方法都有两个好处时使用它。这样做是为了使您能够利用编译器检查的优势，以确保您认为自己确实覆盖了某个方法。这样，如果您犯了拼写错误的方法名称或不正确匹配参数的常见错误，则会警告您方法实际上并未像您认为的那样覆盖。其次，它使您的代码更易于理解，因为当方法被覆盖时，它更加明显。
另外，在Java 1.6中，您可以使用它来标记方法何时实现接口以实现相同的好处。我认为最好有一个单独的注释（例如@Implements），但总比没有好。
我认为最有用的是作为编译时提醒，该方法的意图是重写父方法。举个例子：
protected boolean displaySensitiveInformation() {
return false;
}您会经常看到类似上述方法的内容，该方法会覆盖基类中的方法。这是此类的重要实现细节-我们不希望显示敏感信息。
假设将此方法在父类中更改为
protected boolean displaySensitiveInformation(Context context) {
return true;
}此更改不会导致任何编译时错误或警告-但它会完全更改子类的预期行为。
要回答您的问题：如果在超类中缺少具有相同签名的方法，则表明有bug，则应使用@Override批注。
这里有很多很好的答案，所以让我提供另一种看待它的方法...
编写代码时，不要过度杀伤力。键入@override不会花费任何费用，但是如果您拼写错误的方法名称或使签名略有错误，则可以节省大量资金。
这样考虑：在您浏览此处并键入此帖子时，您花费的时间几乎比一生中花费@override花费的时间多得多。但是它可以防止一个错误，从而节省您的时间。
Java会竭尽所能，确保您在编辑/编译时没有犯任何错误，这实际上是一种免费的方法，可以解决一整套错误，这些错误在综合测试之外是无法避免的。
您能否在Java中提出一种更好的机制，以确保当用户打算重写某个方法时，他确实做到了？
另一个很好的效果是，如果您不提供注释，它将在编译时警告您不小心覆盖了父方法-如果您不打算这样做，那么这可能很重要。
使用@Override注释可作为编译时保护措施，以防止常见的编程错误。如果您在实际上没有覆盖超类方法的方法上具有注释，则将引发编译错误。
最有用的情况是在基础类中将方法更改为具有不同的参数列表时。子类中用于覆盖超类方法的方法将不再这样做，因为方法签名已更改。这有时会导致奇怪和意外的行为，尤其是在处理复杂的继承结构时。该@Override注释保障反对这一点。
要利用编译器检查的优势，您应该始终使用Override注释。但是请不要忘记，当重写接口方法时，Java Compiler 1.5将不允许此注释。您仅可以使用它来覆盖类方法（是否抽象）。
某些IDE（例如Eclipse）甚至配置了Java 1.6运行时或更高版本，它们仍然符合Java 1.5，并且不允许如上所述使用@override。为了避免这种行为，您必须转到：项目属性-> Java编译器->选中“启用项目特定设置”->选择“编译器符合级别” = 6.0或更高。
如果基础是接口或类，每次我独立重写方法时，我都喜欢使用此批注。
这可以帮助您避免一些典型的错误，例如，当您以为您要覆盖事件处理程序时，什么也没看到。假设您要向某个UI组件添加事件侦听器：
someUIComponent.addMouseListener(new MouseAdapter(){
public void mouseEntered() {
...do something...
}
});上面的代码可以编译并运行，但是如果将鼠标移到someUIComponent内，则“执行某些操作”代码将记录运行情况，因为实际上您没有覆盖基本方法mouseEntered(MouseEvent ev)。您只需创建一个新的无参数方法mouseEntered()。代替该代码，如果您使用了@Override注释，则会看到编译错误，并且不会浪费时间思考为什么事件处理程序未运行。
接口实现上的@Override 是不一致的，因为在Java中没有“覆盖接口”之类的东西。
@Override在接口实现上是没有用的，因为在实践中它不会捕获编译无论如何都不会捕获的错误。只有一种牵强附会的情况，实现者的重写实际上会做一些事情：如果您实现一个接口，并且该接口使用REMOVES方法，则将在编译时通知您应删除未使用的实现。请注意，如果新版本的接口具有NEW或CHANGED方法，则显然您将获得编译错误，因为您没有实现新的东西。
在1.6中，绝对不应在接口实现程序上使用@Override，并且由于eclipse可悲地选择将注释自动插入为默认行为，因此，我们得到了很多混乱的源文件。在阅读1.6代码时，您无法从@Override批注中看到某个方法是否实际上覆盖了超类中的方法或仅实现了一个接口。
在实际重写超类中的方法时使用@Override很好。
如果您发现自己经常重写（非抽象）方法，则可能要看一下您的设计。当编译器否则无法捕获该错误时，这将非常有用。例如，尝试覆盖ThreadLocal中的initValue（），我已经完成了。
在实现接口方法（1.6+功能）时使用@Override对我来说有点矫kill过正。如果您有大量的方法，其中有些方法会被覆盖，而有些方法则不会，那么设计可能又很糟糕（如果您不知道，编辑器可能会显示哪个方法）。
实际上，对接口进行@Override很有帮助，因为如果更改接口，则会收到警告。
在实现接口方法时，使用@Override绝对没有任何意义。在这种情况下使用它没有优势-编译器已经捕获了您的错误，因此这只是不必要的混乱。
@Override时，在界面的方法去除在接口上会强迫你通知。
最好的方法是始终使用它（或让IDE为您填充它们）
@Override的用途是检测尚未在层次结构中报告的父类中的更改。没有它，您可以更改方法签名，而忘记更改其覆盖，使用@Override，编译器会为您捕获它。
拥有这样的安全网永远都是好事。
我到处都用它。关于标记方法的工作，我让Eclipse为我做，因此，这无需额外的工作。
我信奉持续重构...。因此，我将尽一切努力使它更加顺利。
如果持续使用，它将保护您免受各种恶意错误的侵害。
使用@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());
}
}资料来源：有效的Java
(b.first == first) && (b.second == second)，即使&&优先级低于==。
Object::equals是boolean equals(Object)，而被覆盖的方法equals是boolean equals(Bigram)，具有不同的方法签名，因此不会覆盖。将@Override添加到equals会检测到此错误。
似乎这里的智慧正在改变。今天，我安装了IntelliJ IDEA 9，并注意到它的“ 缺少@Override检查 ”现在不仅捕获实现的抽象方法，还捕获实现的接口方法。在我的雇主的代码库和我自己的项目中，我长期以来习惯只对前一种方法使用@Override －实现抽象方法。但是，重新考虑这种习惯，在两种情况下使用注释的好处就变得很明显。尽管更为冗长，但它确实可以防止接口方法名称更改的脆弱基类问题（不像C ++相关示例那样严重），在派生类中孤立了将要实现的方法。
当然，这种情况大都是夸张的。派生类将不再编译，现在缺少重命名的接口方法的实现，如今，人们可能会使用“ 重命名方法”重构操作来解决整个代码库。
鉴于无法将IDEA的检查配置为忽略已实现的接口方法，因此今天我将改变我的习惯和团队的代码审查标准。