可以在枚举上使用==吗？

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

JLS 8.9枚举枚举类型除了由其枚举常量定义的实例之外，没有其他实例。尝试显式实例化枚举类型是一个编译时错误。Enum中的最后一个clone方法确保永远无法克隆枚举常量，序列化机制的特殊处理确保永远不会由于反序列化而创建重复实例。禁止枚举类型的反射实例化。这四点共同确保了枚举类型的实例不存在于枚举常量定义的实例之外。因为每个枚举常量只有一个实例，所以在比较两个对象引用时，如果已知其中至少一个引用了枚举常量，则允许使用==运算符代替equals方法。（Enum中的equals方法是一个最终方法，它只在其参数上调用super.equals并返回结果，从而执行身份比较。）

乔什·布洛克（Josh Bloch）建议，如果您坚持使用单例模式，最好的实现方法是使用单个元素枚举（请参阅：有效的Java第二版，第3项：使用私有构造函数或枚举类型强制执行单例属性；另请参阅singleton中的线程安全）

==和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上使用==的参数如下：

它起作用了。速度更快。运行时更安全。编译时更安全。

两者在技术上都是正确的。如果查看.equals（）的源代码，它只需遵循==。

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

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

除了这里已经讨论过的其他原因之外，还有一个原因，那就是你可能会在没有意识到的情况下引入一个bug。假设你有一个完全相同的enums，但在不同的包中（这并不常见，但可能会发生）：

第一个枚举：

package first.pckg

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

第二个枚举：

package second.pckg

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

然后假设您在item.category中使用了类似next的equals，即first.pckg.category，但您导入了第二个enum（second.pckkg.category），而不是第一个enum，而没有意识到它：

import second.pckg.Category;
...

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

因此，尽管item.getCategory（）是JAZZ，但由于是一个不同的枚举，所以您将始终得到false。这可能有点难以理解。

因此，如果改用运算符==，将出现编译错误：

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

import second.pckg.Category; 
...

Category.JAZZ == item.getCategory() 

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

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

另一方面，如果出于任何原因使用不同的方法（普通类实例）替换enum，那么使用==会使您受到攻击。（待定）

我想补充多基因润滑剂的答案：

我个人更喜欢equals（）。但它缺少类型兼容性检查。我认为这是一个重要的限制。

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

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

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

我还建议为enum添加一个未定义的值。

下面是一个粗略的时间测试，以比较两者：

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());
    }   

}

一次评论一个国际单项体育联合会。以下是上面两个比较的分解字节码：

 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

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

我对两个国际单项体育联合会一次进行了几次测试。“==”速度稍快。