Java enumは、プライベートコンストラクターとパブリックスタティックメンバーの束を持つクラスにコンパイルされることを知っています。与えられた列挙型の2つのメンバーを比較するとき、私は常に使用しました.equals()、例えば

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

しかし、私==は.equals（）の代わりに等号演算子を使用するいくつかのコードに出くわしました：

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

どの演算子を使用する必要がありますか？

どちらも技術的に正しいです。のソースコードを見ると、.equals()単に==。

==ただし、nullセーフになるため、を使用します。

==上で使用できますenumか？

はい：列挙型には、インスタンスの==比較に使用できる厳密なインスタンスコントロールがあります。これは言語仕様によって提供される保証です（私が強調）：

JLS 8.9列挙型

列挙型には、その列挙定数で定義されたもの以外のインスタンスはありません。

enum型を明示的にインスタンス化しようとすると、コンパイル時エラーになります。のfinal cloneメソッドEnumは、enum定数が複製されないようにし、シリアル化メカニズムによる特別な処理により、逆シリアル化の結果として重複インスタンスが作成されないようにします。列挙型の反射的なインスタンス化は禁止されています。これらの4つの要素enumにより、enum定数で定義されたインスタンスを超えて型のインスタンスが存在しないことが保証されます。

各enum定数のインスタンスは1つしかないため、2つのオブジェクト参照を比較するときに、少なくとも1つが定数を参照することがわかっている場合は、メソッドの代わりに演算子を使用できます==equalsenum。（のequalsメソッドEnumは、final単にsuper.equalsその引数を呼び出して結果を返すため、同一性比較を実行するメソッドです。）

この保証は十分に強力で、Josh Blochが推奨しています。シングルトンパターンの使用を主張する場合、それを実装する最善の方法は、単一要素を使用することですenum（効果的なJava 2nd Edition、アイテム3：シングルトンプロパティをプライベートコンストラクタまたは列挙型、また、シングルトンで安全スレッド）

違いは何ですか==とはequals？

注意として、==は一般に、の実行可能な代替ではないことを言う必要がありますequals。ただし（の場合などenum）は、考慮すべき2つの重要な違いがあります。

== 投げない 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：コンストラクターの代わりに静的ファクトリーメソッドを検討する

[...]不変クラスは、2つの等しいインスタンスが存在しないことを保証a.equals(b)できa==bます。クラスがこのことを保証する場合、そのクライアント==はequals(Object)メソッドの代わりに演算子を使用でき、パフォーマンスが向上する可能性があります。列挙型はこの保証を提供します。

要約すると、==on を使用するための引数enumは次のとおりです。

• できます。
• より速いです。
• 実行時に安全です。
• コンパイル時に安全です。

使用する ==2つのenum値を比較するためにすると、各enum定数に対して1つのオブジェクトしかないため、機能します。

余談ですが、実際に次のよう==に記述すれば、nullセーフコードを記述するためにを使用する必要はありませんequals()。

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

これは、左から定数を比較と呼ばれるベストプラクティスであり、必ず従う必要があります。

他の人が言ったように、両方==と.equals()ほとんどの場合で動作します。他の人が指摘した完全に異なるタイプのオブジェクトを比較していないというコンパイル時の確実性は有効かつ有益ですが、2つの異なるコンパイル時タイプのオブジェクトを比較する特定の種類のバグは、FindBugs（そしておそらくEclipse / IntelliJコンパイル時検査）、Javaコンパイラがそれを検出しても、それほど多くの安全性が追加されるわけではありません。

しかしながら：

1. ==私の心の中でNPE を決して投げないという事実は、の欠点です==。を介して表現したい追加の状態を追加のインスタンスとしてに追加できるため、enum型をにする必要はほとんどありません。予想外の場合は、静かにfalseと評価するのではなく、NPE を使用します。したがって、実行時の意見では安全であることに同意しません。値を決してさせない習慣に入るのが良いですnullnullenumnull==enum@Nullableです。
2. 引数==で速くはまた、偽です。ほとんどの場合.equals()、コンパイル時の型が列挙型クラスである変数を呼び出します。これらの場合、コンパイラーはこれが==（enumのequals()メソッドをオーバーライドできないため）と同じであることを認識し、関数呼び出しを最適化できます。離れて。コンパイラが現在これを行っているかどうかはわかりませんが、そうでなく、全体的にJavaのパフォーマンスの問題であることが判明した場合は、10万人のJavaプログラマがプログラミングスタイルを適切に変更するのではなく、コンパイラを修正します。特定のコンパイラバージョンのパフォーマンス特性。
3. enumsオブジェクトです。他のすべてのオブジェクトタイプでは、標準の比較はであり.equals()、ではありません==。特にを非列挙クラスにリファクタリングする場合は、enums誤ってObjectをでは==なくと比較してしまう可能性があるため、例外を設けることは危険だと思います。そのようなリファクタリングの場合、上からのIt works pointは間違っています。の使用が正しいことを納得させるには、問題の値がかプリミティブかを確認する必要があります。それが非でequals()enum==enumenumクラス間違いですが、コードはまだコンパイルされるため、見落としがちです。の使用の唯一のケース.equals()問題の値がプリミティブである場合は間違っています。その場合、コードはコンパイルされないため、見落とすことがはるかに難しくなります。したがって、.equals()正しいと識別するのははるかに簡単で、将来のリファクタリングに対して安全です。

私は実際、Java言語は左側の値で.equals（）を呼び出すために==オブジェクトを定義し、オブジェクトIDに別の演算子を導入する必要があると思いますが、それはJavaの定義方法ではありません。

要約すると、私はまだ議論が型に使用すること.equals()を支持していると思いenumます。

私==はequals次の代わりに使用することを好みます：

ここで既に説明した他の理由に加えて、気づかないうちにバグを導入する可能性があるという理由もあります。まったく同じですが、個別のパッケージにあるこの列挙型があるとします（一般的ではありませんが、発生する可能性があります）。

最初の列挙：

package first.pckg

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

2番目の列挙：

package second.pckg

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

そして、あなたは次のように等号を使用すると仮定item.categoryしているfirst.pckg.Categoryが、あなたは、第二の列挙型を（インポートsecond.pckg.Category、それを実現することなく最初の代わりに）：

import second.pckg.Category;
...

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

あなたはオールウェイズを取得するので、falseあなたは本当の理由は、期待が異なる列挙型があるためitem.getCategory()ですJAZZ。そして、それを見るのは少し難しいかもしれません。

したがって、代わりに演算子==を使用すると、コンパイルエラーが発生します。

演算子==は、「second.pckg.Category」、「first.pckg.Category」には適用できません

import second.pckg.Category; 
...

Category.JAZZ == item.getCategory() 

2つを比較する大まかなタイミングテストを次に示します。

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を1つずつコメント化します。以下は、逆アセンブルされたバイトコードでの上記の2つの比較です。

 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

最初の（等しい）は仮想呼び出しを実行し、スタックからの戻りブール値をテストします。2番目（==）は、スタックから直接オブジェクトのアドレスを比較します。最初のケースでは、より多くの活動があります。

このテストは、一度に両方のIFで数回実行しました。「==」はこれまでよりもわずかに高速です。

列挙型の場合、どちらも正しく正しいです!!

tl; dr

別のオプションは、Objects.equalsユーティリティメソッドです。

Objects.equals( thisEnum , thatEnum )

Objects.equals ヌル安全のため

.equals（）の代わりに演算子==に等しい

どの演算子を使用する必要がありますか？

3番目のオプションはequals、Objects Java 7以降に追加ユーティリティクラスです。

例

これは、 Month列挙型ます。

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

利点

この方法にはいくつかの利点があります。

• ヌルセーフティ
  • 両方null➙ true
  • null ith false
  • 投げる危険なし NullPointerException
• コンパクトで読みやすい

使い方

によって使用されるロジックは何ですか Objects.equalsですか？

自分自身を参照してくださいJavaの10のソースコードのOpenJDKの：

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

==列挙定数を比較する以外に何かを使用することはナンセンスです。それはオブジェクトを比較するclassequalsようなものです –しないでください！

ただし、Sun JDK 6u10以前には、歴史的な理由から興味深いかもしれない厄介なバグ（BugId 6277781）がありました。このバグにより==、デシリアライズされた列挙型を適切に使用できなくなりました。

列挙型は、public static final field（不変）によって宣言された列挙定数ごとに1つのインスタンス（シングルトンなど）を返すクラスであり、==演算子を使用してequals()メソッドを使用するのではなく、それらの等価性をチェックできます

enumが==で簡単に機能する理由は、定義された各インスタンスもシングルトンであるためです。したがって、==を使用したID比較は常に機能します。

ただし、==を使用すると、列挙型で機能するため、すべてのコードがその列挙型の使用と密接に結合されます。

例：Enumはインターフェースを実装できます。現在、Interface1を実装する列挙型を使用しているとします。後で、誰かがそれを変更するか、同じインターフェースの実装として新しいクラスImpl1を導入します。次に、Impl1のインスタンスの使用を開始すると、==の以前の使用のために、変更およびテストする多くのコードが必要になります。

したがって、正当な理由がない限り、良い方法と見なされる方法に従うことが最善です。

ソナールールの1つはEnum values should be compared with "=="です。その理由は次のとおりです。

equals()enumはObjectであり、すべてのJava開発者が==Objectのコンテンツの比較に使用すべきではないことを知っているため、enum値との等価性のテストは完全に有効です。同時に、==列挙型で使用：

• 同じ期待される比較（コンテンツ）を提供します equals()

• よりもnullセーフです equals()

• 実行時チェックではなくコンパイル時（静的）チェックを提供します

これらの理由から、の使用を==に優先する必要がありますequals()。

最後に==重要なことですが、on enumはと比べて間違いなく読みやすく（冗長ではありません）ですequals()。

つまり、どちらにも長所と短所があります。

一方==で、他の回答で説明されているように、を使用することには利点があります。

一方、何らかの理由で列挙型を別のアプローチ（通常のクラスインスタンス）に置き換えた場合、使用したこと==が問題になります。（BTDT。）

私はpolygenelubricantsの答えを補完したいと思います：

個人的にはequals（）を好みます。ただし、型の互換性チェックは必要です。これは重要な制限だと思います。

コンパイル時に型の互換性チェックを行うには、列挙型でカスタム関数を宣言して使用します。

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

これにより、NPE保護、コードの読みやすさ、コンパイル時の型互換性チェックなど、両方のソリューションの利点がすべて得られます。

列挙型にUNDEFINED値を追加することもお勧めします。