比较 Java 枚举成员：== 还是 equals()？

Question

我知道 Java 枚举被编译为具有私有构造函数和一堆公共静态成员的类。当比较给定枚举的两个成员时，我总是使用 .equals()，例如

public useEnums(SomeEnum a)
{
    if(a.equals(SomeEnum.SOME_ENUM_VALUE))
    {
        ...
    }
    ...
}

但是，我刚刚遇到一些使用 equals 运算符 == 的代码of .equals()：

public useEnums2(SomeEnum a)
{
    if(a == SomeEnum.SOME_ENUM_VALUE)
    {
        ...
    }
    ...
}

我应该使用哪一个运算符？

Answer 1

两者在技术上都是正确的。如果您查看 .equals() 的源代码，您会发现它只是遵循 ==。

然而，我使用 == ，因为这将是空安全的。

Answer 2

== 可以用在 enum 上吗？

是的：枚举具有严格的实例控制，允许您使用 == 来比较实例。这是语言规范提供的保证（由我强调）：

JLS 8.9 枚举

枚举类型除了由其枚举常量定义的实例之外没有其他实例。

尝试显式实例化枚举类型是一个编译时错误。 Enum 中的 final clone 方法保证了 enum 常量永远不会被克隆，序列化机制的特殊处理保证了永远不会出现重复的实例作为反序列化的结果而创建。禁止枚举类型的反射实例化。这四件事共同确保 enum 类型的实例不存在于 enum 常量定义的实例之外。

由于每个enum常量只有一个实例，允许使用==运算符代替equals 方法（如果已知其中至少一个对象引用引用enum 常量）。 （Enum 中的 equals 方法是一个 final 方法，它仅在其参数上调用 super.equals 并返回结果，从而执行身份比较。）




这种保证足够强大，Josh Bloch 建议，如果您坚持使用单例模式，实现它的最佳方法是使用单元素enum （请参阅：Effective Java 第二版，第 3 项：使用私有构造函数或枚举类型强制执行单例属性；还有 Singleton 中的线程安全）

---

== 和 equals 之间有什么区别？

提醒一下，需要指出的是，通常 == 并不是 equals 的可行替代方案。然而，当它是时（例如使用 enum），需要考虑两个重要的区别：

== 永远不会抛出 NullPointerException

enum Color { BLACK, WHITE };

Color nothing = null;
if (nothing == Color.BLACK);      // runs fine
if (nothing.equals(Color.BLACK)); // throws NullPointerException

= = 在编译时接受类型兼容性检查

enum Color { BLACK, WHITE };
enum Chiral { LEFT, RIGHT };

if (Color.BLACK.equals(Chiral.LEFT)); // compiles fine
if (Color.BLACK == Chiral.LEFT);      // DOESN'T COMPILE!!! Incompatible types!

---

在适用时是否应该使用 ==？

Bloch 特别提到，对其实例具有适当控制的不可变类可以向其客户端保证 == 可用。特别提到enum来举例说明。

第 1 项：考虑静态工厂方法而不是构造函数

[...]它允许不可变类保证不存在两个相等的实例：a.equals(b)当且仅当a==b代码>.如果类做出此保证，则其客户端可以使用 == 运算符而不是 equals(Object) 方法，这可能会提高性能。枚举类型提供了这种保证。

总而言之，在 enum 上使用 == 的论点是：

• 它有效。
• 速度更快了。
• 运行时更安全。
• 编译时更安全。

Answer 3

使用 == 比较两个枚举值是可行的，因为每个枚举常量只有一个对象。

顺便说一句，如果您像这样编写 equals() ，实际上不需要使用 == 来编写空安全代码：

public useEnums(final SomeEnum a) {
    if (SomeEnum.SOME_ENUM_VALUE.equals(a)) {
        …
    }
    …
}

这是最佳实践称为从左侧比较常量，您绝对应该遵循。

Answer 4

正如其他人所说， == 和 .equals() 在大多数情况下都有效。您没有比较其他人指出的完全不同类型的对象的编译时确定性是有效且有益的，但是 FindBugs 也会发现比较两种不同编译时类型的对象的特定类型的错误（并且可能由Eclipse/IntelliJ 编译时检查），因此 Java 编译器发现它并不会增加太多额外的安全性。

然而：

1. 事实上 == 在我的脑海里从来不会抛出 NPE，这是 == 的一个缺点。几乎不需要将 enum 类型设置为 null，因为您可能想要通过 null 表达的任何额外状态都可以是作为附加实例添加到 enum 中。如果它意外地为 null，我宁愿有一个 NPE，也不愿 == 默默地评估为 false。因此我不同意运行时更安全的观点；最好养成永远不要让 enum 值为 @Nullable 的习惯。
2. 关于==更快的论点也是虚假的。在大多数情况下，您将在编译时类型为枚举类的变量上调用 .equals() ，在这些情况下，编译器可以知道这与 ==< /code> （因为 enum 的 equals() 方法无法被重写）并且可以优化函数调用。我不确定编译器目前是否这样做，但如果没有，并且结果证明这是 Java 整体的性能问题，那么我宁愿修复编译器，也不愿让 100,000 名 Java 程序员改变他们的编程风格以适应特定编译器版本的性能特征。
3. 枚举是对象。对于所有其他对象类型，标准比较是 .equals()，而不是 ==。我认为对 enums 进行例外处理是危险的，因为您最终可能会意外地将对象与 == 而不是 equals() 进行比较，特别是如果您将 enum 重构为非枚举类。在进行此类重构的情况下，上面的它有效观点是错误的。为了让自己相信 == 的使用是正确的，您需要检查相关值是 enum 还是基元；如果它是一个非enum类，它会是错误的，但很容易错过，因为代码仍然可以编译。使用 .equals() 的唯一错误情况是所讨论的值是基元；在这种情况下，代码将无法编译，因此更难错过。因此，.equals() 更容易被识别为正确的，并且对于未来的重构来说更安全。

我实际上认为 Java 语言应该在对象上定义 == 来调用左侧值的 .equals() ，并为对象标识引入一个单独的运算符，但这不是 Java 的定义方式。

总之，我仍然认为这些论点赞成对 enum 类型使用 .equals() 。

Answer 5

我更喜欢使用 == 而不是 equals：

除了这里已经讨论的其他原因之外，其他原因是您可能会在没有意识到的情况下引入错误。假设您有一个完全相同的枚举，但位于单独的包中（这并不常见，但可能会发生）：

First enum:

package first.pckg

public enum Category {
    JAZZ,
    ROCK,
    POP,
    POP_ROCK
}

Second enum:

package second.pckg

public enum Category {
    JAZZ,
    ROCK,
    POP,
    POP_ROCK
}

然后假设您使用等于 item.category 中的 next，即 first.pckg.Category，但您导入第二个枚举 (second.pckg.Category)，而不是首先没有意识到：

import second.pckg.Category;
...

Category.JAZZ.equals(item.getCategory())

所以你总是会得到 false 由于是一个不同的枚举，尽管你期望 true 因为 item.getCategory() 是 JAZZ。而且可能有点难以看到。

因此，如果您使用运算符 == ，则会出现编译错误：

运算符 == 不能应用于“second.pckg.Category”、“first.pckg.Category”

import second.pckg.Category; 
...

Category.JAZZ == item.getCategory() 

Answer 6

tl;dr

另一种选择是 Objects.equals 实用方法。

Objects.equals( thisEnum , thatEnum )

Objects.equals 用于空安全

等于运算符 == 而不是 .equals()

我应该使用哪一个运算符？

第三个选项是静态 equals 方法在 对象 实用程序类添加到 Java 7 及更高版本。

示例

以下是使用 Month 枚举。

boolean areEqual = Objects.equals( Month.FEBRUARY , Month.JUNE ) ;  // Returns `false`.

优点

我发现这种方法有几个好处：

• 零安全
  • 均为空 ➙ true
  • 为 null ➙ false
  • 没有抛出 NullPointerException

  


  


• 紧凑、可读

工作

原理 对象.等于？

亲自查看，来自 OpenJDK 的 ="noreferrer">Java 10 源代码：

return 
    ( a == b ) 
    || 
    ( 
        a != null 
        && 
        a.equals( b )
    )
;

Answer 7

Sonar 规则之一是枚举值应与“==”进行比较。原因如下：

使用 equals() 测试枚举值的相等性是完全有效的，因为枚举是一个对象，并且每个 Java 开发人员都知道 == 不应该用于比较对象的内容。同时，在枚举上使用==：

• 提供与 equals() 相同的预期比较（内容）

• 比 equals() 更空安全

• 提供编译时（静态）检查而不是运行时检查

出于这些原因，应优先使用 == 而不是 equals()。

最后但并非最不重要的一点是，枚举上的 == 可以说比 equals() 更具可读性（更简洁）。

Answer 8

这是一个比较两者的粗略时序测试：

import java.util.Date;

public class EnumCompareSpeedTest {

    static enum TestEnum {ONE, TWO, THREE }

    public static void main(String [] args) {

        Date before = new Date();
        int c = 0;

        for(int y=0;y<5;++y) {
            for(int x=0;x<Integer.MAX_VALUE;++x) {
                if(TestEnum.ONE.equals(TestEnum.TWO)) {++c;}
                if(TestEnum.ONE == TestEnum.TWO){++c;}              
            }
        }

        System.out.println(new Date().getTime() - before.getTime());
    }   

}

一次注释掉一个 IF。以下是上面反汇编字节码中的两个比较：

 21  getstatic EnumCompareSpeedTest$TestEnum.ONE : EnumCompareSpeedTest.TestEnum [19]
 24  getstatic EnumCompareSpeedTest$TestEnum.TWO : EnumCompareSpeedTest.TestEnum [25]
 27  invokevirtual EnumCompareSpeedTest$TestEnum.equals(java.lang.Object) : boolean [28]
 30  ifeq 36

 36  getstatic EnumCompareSpeedTest$TestEnum.ONE : EnumCompareSpeedTest.TestEnum [19]
 39  getstatic EnumCompareSpeedTest$TestEnum.TWO : EnumCompareSpeedTest.TestEnum [25]
 42  if_acmpne 48

第一个（等于）执行虚拟调用并测试堆栈中的返回布尔值。第二个 (==) 直接比较堆栈中的对象地址。在第一种情况下，活动较多。

我多次使用两个 IF 运行此测试，每次一个。 “==”稍微快一点。

Answer 9

对于枚举来说，两者都是正确的！

Answer 10

使用 == 以外的任何内容来比较枚举常量都是无意义的。这就像比较class对象与 equals – 不要这样做！

然而，Sun JDK 6u10 及更早版本中存在一个严重的错误 (BugId 6277781)由于历史原因，这可能很有趣。此错误阻止了在反序列化枚举上正确使用 ==，尽管这可以说是一种极端情况。

Answer 11

枚举是一种类，它为 public static final field 声明的每个枚举常量返回一个实例（如单例）（不可变），以便可以使用 == 运算符检查它们的相等性而不是使用 equals() 方法

Answer 12

只需添加一件事即可添加到所有其他优秀答案中。当您使用简单的 lambda 时，我更喜欢 equals 而不是 ==，因为您可以使用方法引用。

考虑以下 lambda：

Stream.of(SomeEnum.A, SomeEnum.B).anyMatch(e -> e == SomeEnum.B);
Stream.of(SomeEnum.A, SomeEnum.B).anyMatch(e -> e.equals(SomeEnum.B));

后者可以转换为：

Stream.of(SomeEnum.A, SomeEnum.B).anyMatch(SomeEnum.B::equals));

Answer 13

枚举可以轻松地与 == 一起使用的原因是因为每个定义的实例也是一个单例。所以使用 == 进行身份比较总是有效的。

但是使用 == 因为它与枚举一起使用意味着您的所有代码都与该枚举的使用紧密耦合。

例如：枚举可以实现接口。假设您当前正在使用实现 Interface1 的枚举。如果稍后有人更改它或引入一个新类 Impl1 作为同一接口的实现。然后，如果您开始使用 Impl1 的实例，由于之前使用了 ==，您将需要更改和测试大量代码。

因此，最好遵循被认为是良好做法的做法，除非有任何合理的收益。

Answer 14

我想补充一下polygenelubricants的答案：

我个人更喜欢equals()。但它忽略了类型兼容性检查。我认为这是一个重要的限制。

要在编译时进行类型兼容性检查，请在枚举中声明并使用自定义函数。

public boolean isEquals(enumVariable) // compare constant from left
public static boolean areEqual(enumVariable, enumVariable2) // compare two variable

这样，您就可以获得两种解决方案的所有优点：NPE 保护、易于阅读的代码以及编译时的类型兼容性检查。

我还建议为枚举添加 UNDEFINED 值。

Answer 15

简而言之，两者各有利弊。

一方面，如其他答案中所述，使用 == 有优势。

另一方面，如果您出于某种原因用不同的方法（普通类实例）替换枚举，那么使用 == 就会让您烦恼。 （BTDT。）