Java 程序员必须掌握的 5 个注解！

在本文中，我们将看到5个Java编译器支持的注解，并了解其期望用途。顺便，我们将探索其创建背后的基本原理，围绕其用途的一些特质，以及正确应用的一些例子。虽然其中有些注解比其他注解更为常见，但非初学Java开发人员都应该消化了解每个注解。

@Override

@FunctionalInterface

@SuppressWarnings

@SafeVarargs

@Deprecated

首先，我们将深入研究Java中最常用的注解之一：@Override。

@Override

覆盖方法的实现或为抽象方法提供实现的能力是任何面向对象（OO）语言的核心。由于Java是OO语言，具有许多常见的面向对象的抽象机制，所以在非终极超类定义的非最终方法或接口中的任何方法（接口方法不能是最终的）都可以被子类覆盖。点击这里阅读 Java 10 新特性实战教程。

虽然开始时覆盖方法看起来很简单，但是如果执行不正确，则可能会引入许多微小的bug。例如，用覆盖类类型的单个参数覆盖Object#equals方法就是一种常见的错误：

public class Foo {
    public boolean equals(Foo foo) {
    // Check if the supplied object is equal to this object
    }
}

由于所有类都隐式地从Object类继承，Foo类的目的是覆盖Object#equals方法，因此Foo可被测试是否与Java中的任何其他对象相等。虽然我们的意图是正确的，但我们的实现则并非如此。

实际上，我们的实现根本不覆盖Object#equals方法。相反，我们提供了方法的重载：我们不是替换Object类提供的equals方法的实现，而是提供第二个方法来专门接受Foo对象，而不是Object对象。

我们的错误可以用简单实现来举例说明，该实现对所有的相等检查都返回true，但当提供的对象被视为Object（Java将执行的操作，例如在Java Collections Framework即JCF中）时，就永远不会调用它：

实质上，我们已经将我们已经覆盖方法的这一隐含的假设转变为由编译器进行的显性验证。如果我们的意图被错误地实现，那么Java编译器会发出一个错误——不允许我们不正确实现的代码被成功编译。通常，如果以下任一条件不满足，则Java编译器将针对使用@Override注解的方法发出错误（引用自Override注解文档）：

该方法确实会覆盖或实现在超类中声明的方法。

该方法的签名与在Object中声明的任何公共方法（即equals或hashCode方法）的签名覆盖等价（override-equivalent）。

因此，我们也可以使用此注解来确保子类方法实际上也覆盖超类中的非最终具体方法或抽象方法：

public abstract class Foo {
    public int doSomething() {
        return 1;
        }
    public abstract int doSomethingElse();
    }
public class Bar extends Foo {
    @Override
    public int doSomething() {
        return 10;
    }
    @Override
    public int doSomethingElse() {
         return 20;
    }
}
Foo bar = new Bar();
System.out.println(bar.doSomething());   // 10
System.out.println(bar.doSomethingElse());  // 20

@Override注解不仅不限于超类中的具体或抽象方法，而且还可用于确保接口的方法也被覆盖（从JDK 6开始）：

public interface Foo {
    public int doSomething();
}
public class Bar implements Foo {
    @Override
    public int doSomething() {
        return 10;
    }
}
Foo bar = new Bar();
System.out.println(bar.doSomething());    // 10

通常，覆盖非final类方法、抽象超类方法或接口方法的任何方法都可以使用@Override进行注解。有关有效覆盖的更多信息，请参阅《Overriding and Hiding》文档 以及《Java Language Specification (JLS)》的第9.6.4.4章节。

@FunctionalInterface

随着JDK 8中lambda表达式的引入，函数式接口在Java中变得越来越流行。这些特殊类型的接口可以用lambda表达式、方法引用或构造函数引用代替。根据@FunctionalInterface文档，函数式接口的定义如下：

一个函数式接口只有一个抽象方法。由于默认方法有一个实现，所以它们不是抽象的。

例如，以下接口被视为函数式接口：

重点要注意的是，抽象类，即使它们只包含一个抽象方法，也不是函数式接口。更多信息，请参阅首席Java语言架构师Brian Goetz编写的《Allow lambdas to implement abstract classes》。与@Override注解类似，Java编译器提供了@FunctionalInterface注解以确保接口确实是函数式接口。例如，我们可以将此注解添加到上面创建的接口中：

使用这个注解，我们可以确保我们不会错误地创建原本打算用作函数式接口的非函数式接口。需要注意的是，即使在@FunctionalInterface注解不存在的情况下，接口也可以用作函数式接口（可以替代为lambdas，方法引用和构造函数引用），正如我们前面的示例中所见的那样。这类似于@Override注解，即一个方法是可以被覆盖的，即使它不包含@Override注解。在这两种情况下，注解都是允许编译器执行期望意图的可选技术。

有关@FunctionalInterface注解的更多信息，请参阅@FunctionalInterface文档和《JLS》的第4.6.4.9章节。点击这里阅读 Java 10 新特性实战教程。

@SuppressWarnings

警告是所有编译器的重要组成部分，为开发人员提供的反馈——可能危险的行为或在未来的编译器版本中可能会出现的错误。例如，在Java中使用泛型类型而没有其关联的正式泛型参数（称为原始类型）会导致警告，就像使用不推荐使用的代码一样（请参阅下面的@Deprecated部分）。虽然这些警告很重要，但它们可能并不总是适用甚至并不总是正确的。例如，可能会有对不安全的类型转换发生警告的情况，但是基于使用它的上下文，我们可以保证它是安全的。

为了忽略某些上下文中的特定警告，JDK 5中引入了@SuppressWarnings注解。此注解接受一个或多个字符串参数——描述要忽略的警告名称。虽然这些警告的名称通常在编译器实现之间有所不同，但有3种警告在Java语言中是标准化的（因此在所有Java编译器实现中都很常见）：

unchecked：表示类型转换未经检查的警告（编译器无法保证类型转换是安全的），导致发生的可能原因有访问原始类型的成员（参见《JLS》4.8章节）、窄参考转换或不安全的向下转换（参见《JLS》5.1.6章节）、未经检查的类型转换（参见《JLS》5.1.9章节）、使用带有可变参数的泛型参数（参见《JLS》8.4.1章节和下面的@SafeVarargs部分）、使用无效的协变返回类型（参见《JLS》8.4.8.3章节）、不确定的参数评估（参见《JLS》15.12.4.2章节），未经检查的方法引用类型的转换（参见《JLS》15.13.2章节）、或未经检查的lambda类型的对话（参见《JLS》15.27.3章节）。

deprecation：表示使用了已弃用的方法、类、类型等的警告（参见《JLS》9.6.4.6章节和下面的@Deprecated部分）。

removal：表示使用了最终废弃的方法、类、类型等的警告（参见《JLS》9.6.4.6章节和下面的@Deprecated部分）。

为了忽略特定的警告，可以将@SuppressedWarning注解与抑制警告（以字符串数组的形式提供）的一个或多个名字添加到发生警告的上下文中：

@SafeVarargs

可变参数在Java中是一种很有用的技术手段，但在与泛型参数一起使用时，它们也可能会导致一些严重的问题。由于泛型在Java中是非特定的，所以具有泛型类型的变量的实际（实现）类型不能在运行时被断定。由于无法做出此判断，因此变量可能会存储非其实际类型的引用到类型，如以下代码片段所示（摘自《Java Generics FAQs》）：

如果执行此代码片段，那么将导致ClassCastException，因为在调用站点传递的第一个Number参数不能转换为String（类似于独立堆污染示例中抛出的ClassCastException）。通常，可能会出现以下情况：编译器没有足够的信息来正确确定通用可变参数的确切类型，这会导致堆污染，这种污染可以通过允许内部可变参数数组从方法中转义来传播，如下面摘自《Effective Java》第3版 pp.147的例子：

有关@SafeVarargs注解的更多信息，请参阅@SafeVarargs文档，《JLS》9.6.4.7章节以及《Effective Java》第3版中的Item32。点击这里阅读 Java 10 新特性实战教程。

@Deprecated

在开发代码时，有时候代码会变得过时和不应该再被使用。在这些情况下，通常会有个替补的更适合手头的任务，且虽然现存的对过时代码的调用可能会保留，但是所有新的调用都应该使用替换方法。这个过时的代码被称为不推荐使用的代码。在某些紧急情况下，不建议使用的代码可能会被删除，应该在未来的框架或库版本从其代码库中删除弃用的代码之前立即转换为替换代码。

为了支持不推荐使用的代码的文档，Java包含@Deprecated注解，它会将一些构造函数、域、局部变量、方法、软件包、模块、参数或类型标记为已弃用。如果弃用的元素（构造函数，域，局部变量等）被使用了，则编译器发出警告。例如，我们可以创建一个弃用的类并按如下所示使用它：

通常，每当使用@Deprecated注解的元素时，都会引发警告，除了用于以下五种情况：

声明本身就被声明为是弃用的（即递归调用）。

声明被注解禁止弃用警告（即@SuppressWarnings(“deprecation”）注解，如上所述，应用于使用弃用元素的上下文。

使用和声明都在同一个最外面的类中（即，如果类调用其本身的弃用方法）。

用在import声明中，该声明导入通常不赞成使用的类型或构件（即，在将已弃用的类导入另一个类时）。

exports或opens指令内。

正如前面所说的，在某些情况下，当不推荐使用的元素将被删除，则调用代码应立即删除不推荐使用的元素（称为terminally deprecated code）。在这种情况下，可以使用forRemoval参数提供的@Deprecated注解，如下所示：

JavaDoc工具将生成以下文档：

有关@Deprecated注解的更多信息，请参阅@Deprecated文档和《JLS》9.6.4.6章节。

结尾

自JDK 5引入注解以来，注解一直是Java不可缺少的一部分。虽然有些注解比其他注解更受欢迎，但本文中介绍的这5种注解是新手级别以上的开发人员都应该理解和掌握的：

@Override

@FunctionalInterface

@SuppressWarnings

@SafeVarargs

@Deprecated

虽然每种方法都有其独特的用途，但所有这些注解使得Java应用程序更具可读性，并允许编译器对我们的代码执行一些其他隐含的假设。随着Java语言的不断发展，这些经过实践验证的注解可能服务多年，帮助确保更多的应用程序按开发人员的意图行事。