Wiem, że wyliczenia Java są kompilowane do klas z prywatnymi konstruktorami i grupą publicznych członków statycznych. Porównując dwóch członków danego wyliczenia, zawsze używałem .equals()np

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

Jednak właśnie natknąłem się na kod, który używa operatora równości ==zamiast .equals ():

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

Którego operatora powinienem używać?

Oba są technicznie poprawne. Jeśli spojrzysz na kod źródłowy .equals(), po prostu odracza się na ==.

Używam ==jednak, ponieważ będzie to bezpieczne.

Może ==być używany na enum?

Tak: wyliczenia mają ścisłą kontrolę instancji, która umożliwia ==porównywanie instancji. Oto gwarancja zawarta w specyfikacji języka (moje wyróżnienie):

JLS 8.9 Wyliczenia

Typ wyliczeniowy nie ma innych wystąpień niż te zdefiniowane przez jego stałe wyliczeniowe.

Błędem podczas kompilacji jest próba jawnego utworzenia wystąpienia typu wyliczeniowego. Ta final clonemetoda Enumzapewnia, że enumstałe nigdy nie będą klonowane, a specjalne traktowanie przez mechanizm serializacji gwarantuje, że w wyniku deserializacji nigdy nie zostaną utworzone zduplikowane instancje. Instancja refleksyjna typów wyliczeniowych jest zabroniona. Razem te cztery rzeczy zapewniają, że nie enumistnieją żadne instancje typu poza tymi zdefiniowanymi przez enumstałe.

Ponieważ istnieje tylko jedna instancja każdej enumstałej, dopuszczalne jest użycie ==operatora zamiast equalsmetody podczas porównywania dwóch odniesień do obiektów, jeśli wiadomo, że co najmniej jeden z nich odnosi się do enumstałej . ( equalsMetoda in Enumjest finalmetodą, która po prostu wywołuje super.equalsargument i zwraca wynik, tym samym porównując tożsamość.)

Ta gwarancja jest na tyle silna, że ​​Josh Bloch zaleca, aby upierać się przy używaniu wzorca singletonu, najlepszym sposobem na jego wdrożenie jest użycie jednego elementu enum(patrz: Skuteczna Java 2. wydanie, pozycja 3: Egzekwowanie właściwości singletonu za pomocą prywatny konstruktor lub typ enum ; także bezpieczeństwo wątków w Singleton )

Jakie są różnice między ==i equals?

Dla przypomnienia należy powiedzieć, że ogólnie ==NIE jest realną alternatywą dla equals. Gdy jednak tak jest (np. Z enum), należy wziąć pod uwagę dwie ważne różnice:

== nigdy nie rzuca NullPointerException

enum Color { BLACK, WHITE };

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

== podlega kontroli zgodności typu w czasie kompilacji

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!

Czy ==należy stosować, jeśli dotyczy?

Bloch wspomina w szczególności, że niezmienne klasy, które mają odpowiednią kontrolę nad swoimi instancjami, mogą zagwarantować ==użyteczność ich klientom . enumjest konkretnie wspomniany jako przykład.

Punkt 1: Rozważ statyczne metody fabryczne zamiast konstruktorów

[...] pozwala niezmiennej klasie dać gwarancję, że nie istnieją dwa równe przypadki: a.equals(b)wtedy i tylko wtedy a==b. Jeśli klasa zapewni tę gwarancję, wówczas jej klienci mogą użyć ==operatora zamiast equals(Object)metody, co może spowodować lepszą wydajność. Typy Enum zapewniają tę gwarancję.

Podsumowując, argumenty za korzystanie ==na enumto:

• To działa.
• Jest szybsze.
• Jest bezpieczniejszy w czasie wykonywania.
• Jest bezpieczniejszy w czasie kompilacji.

Używanie ==do porównywania dwóch wartości wyliczeniowych działa, ponieważ dla każdej stałej wyliczeniowej jest tylko jeden obiekt.

Na marginesie, w rzeczywistości nie ma potrzeby ==pisania kodu o wartości zerowej, jeśli piszesz coś equals()takiego:

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

Jest to najlepsza praktyka znana jako Porównaj stałe z lewej , którą zdecydowanie powinieneś stosować.

Jak mówili inni, zarówno ==i .equals()praca w większości przypadków. Pewność czasu kompilacji, że nie porównujesz całkowicie różnych typów obiektów, na które wskazali inni, jest ważna i korzystna, jednak szczególny rodzaj błędu porównywania obiektów dwóch różnych typów czasu kompilacji znalazłby również FindBugs (i prawdopodobnie Inspekcja czasu kompilacji Eclipse / IntelliJ), więc znalezienie kompilatora Java nie zapewnia tak dużego bezpieczeństwa.

Jednak:

1. Fakt, że ==nie rzuca NPE w moim umyśle jest wadą z ==. Prawie nigdy nie powinna istnieć potrzeba istnienia enumtypów null, ponieważ każdy dodatkowy stan, który możesz chcieć wyrazić, nullmoże zostać dodany do enumdodatkowej instancji. Jeśli jest to nieoczekiwanie null, wolałbym mieć NPE niż ==dyskretną ocenę na fałsz. Dlatego nie zgadzam się z tym, że jest bezpieczniejsza w czasie wykonywania ; lepiej jest przyzwyczaić się do tego, aby nigdy nie pozwalać na to, by enumwartości były @Nullable.
2. Argument, który ==jest szybszy, jest również fałszywy. W większości przypadków będzie zadzwonić .equals()na zmienną, której typ kompilacji czas jest klasa enum, aw tych przypadkach kompilator może wiedzieć, że to jest taki sam jak ==(ponieważ enum„s equals()metoda nie może być zmienione) i można zoptymalizować wywołanie funkcji z dala. Nie jestem pewien, czy kompilator obecnie to robi, ale jeśli tak nie jest i okazuje się, że jest to ogólnie problem z wydajnością w Javie, wolę naprawić kompilator niż pozwolić 100 000 programistów Java zmienić swój styl programowania, aby pasował cechy wydajności konkretnej wersji kompilatora.
3. enumssą obiektami. Dla wszystkich innych typów obiektów standardowe porównanie .equals()nie jest ==. Wydaje mi się, że tworzenie wyjątków jest niebezpieczne, enumsponieważ ==zamiast tego equals()możesz przypadkowo porównać obiekty , szczególnie jeśli enumprzekształcisz an w klasę nie-enum. W przypadku takiego refaktoryzacji to działa punkt z góry jest błędny. Aby przekonać się, że użycie ==jest poprawne, musisz sprawdzić, czy dana wartość jest albo enumprymitywna; gdyby nie była to enumklasa, byłoby źle, ale łatwo ją przeoczyć, ponieważ kod nadal się kompilował. Jedyny przypadek, w którym użycie.equals()błędem byłoby, gdyby dane wartości były prymitywne; w takim przypadku kod nie zostałby skompilowany, więc o wiele trudniej go przeoczyć. W związku z tym .equals()jest o wiele łatwiejszy do zidentyfikowania jako poprawny i bezpieczniejszy w stosunku do przyszłych refaktoryzacji.

Właściwie uważam, że język Java powinien zdefiniować == na Objects, aby wywołać .equals () na wartości po lewej stronie i wprowadzić osobny operator dla tożsamości obiektu, ale nie tak zdefiniowano Javę.

Podsumowując, nadal uważam, że argumenty są na rzecz korzystania .equals()z enumtypów.

Wolę używać ==zamiast equals:

Innym powodem, oprócz innych omówionych tutaj, jest to, że możesz wprowadzić błąd, nie zdając sobie z tego sprawy. Załóżmy, że masz wyliczenia, które są dokładnie takie same, ale w oddzielnych pakakach (nie jest to powszechne, ale może się zdarzyć):

Pierwsze wyliczenie :

package first.pckg

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

Drugie wyliczenie:

package second.pckg

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

Następnie załóżmy, że korzystać z równych jak następny w item.categoryktórym jest first.pckg.Categoryjednak importować drugą enum ( second.pckg.Category) zamiast pierwszy nie wiedząc o tym:

import second.pckg.Category;
...

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

Więc zawsze otrzymacie falsenależność, to jest inny wyliczenie, chociaż można oczekiwać, że to prawda, ponieważ item.getCategory()jest JAZZ. I może to być trochę trudne do zobaczenia.

Jeśli więc zamiast tego użyjesz operatora ==, wystąpi błąd kompilacji:

operator == nie można zastosować do „second.pckg.Category”, „first.pckg.Category”

import second.pckg.Category; 
...

Category.JAZZ == item.getCategory() 

Oto przybliżony test czasowy, aby porównać dwa:

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

}

Komentuj IFs pojedynczo. Oto dwa porównania z góry w zdemontowanym kodzie bajtowym:

 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

Pierwszy (równy) wykonuje wirtualne wywołanie i testuje wartość logiczną ze stosu. Drugi (==) porównuje adresy obiektów bezpośrednio ze stosu. W pierwszym przypadku jest więcej aktywności.

Przeprowadziłem ten test kilka razy z obydwoma IF po jednym na raz. „==” jest zawsze nieco szybszy.

W przypadku wyliczenia oba są poprawne i słuszne !!

tl; dr

Inną opcją jest Objects.equalsmetoda użyteczności.

Objects.equals( thisEnum , thatEnum )

Objects.equals dla zerowego bezpieczeństwa

równa się operator == zamiast .equals ()

Którego operatora powinienem używać?

Trzecią opcją jest equalsmetoda statyczna znaleziona w Objectsklasie narzędzia dodanej do Java 7 i nowszych.

Przykład

Oto przykład użycia Monthwyliczenia.

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

Korzyści

Znajduję kilka zalet tej metody:

• Brak bezpieczeństwa
  • Oba null ➙ true
  • Albo null ➙ false
  • Bez ryzyka rzucenia NullPointerException
• Kompaktowy, czytelny

Jak to działa

Jaka jest logika Objects.equals?

Przekonaj się sam, od kodu Java 10 źródłowego z OpenJDK :

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

Używanie czegokolwiek innego niż ==porównywanie stałych wyliczeniowych jest nonsensem. To jak porównywanie classobiektówequals - nie rób tego!

Wystąpił jednak paskudny błąd (BugId 6277781 ) w Sun JDK 6u10 i wcześniejszych, który może być interesujący z powodów historycznych. Ten błąd uniemożliwiał prawidłowe użycie ==zdezrializowanych wyliczeń, chociaż jest to prawdopodobnie nieco narożny przypadek.

Wyliczenia są klasami, które zwracają jedną instancję (jak singletony) dla każdej stałej wyliczenia zadeklarowanej przez public static final field(niezmienne), dzięki czemu ==operator może być używany do sprawdzania ich równości, zamiast przy użyciu equals()metody

Powodem, dla którego wyliczenia działają łatwo z ==, jest to, że każda zdefiniowana instancja jest także singletonem. Tak więc porównanie tożsamości za pomocą == zawsze będzie działać.

Ale użycie ==, ponieważ działa z wyliczeniami, oznacza, że ​​cały kod jest ściśle powiązany z użyciem tego wyliczenia.

Na przykład: Enums mogą implementować interfejs. Załóżmy, że obecnie używasz wyliczenia, które implementuje interfejs1. Jeśli później ktoś to zmieni lub wprowadzi nową klasę Impl1 jako implementację tego samego interfejsu. Następnie, jeśli zaczniesz używać instancji Impl1, będziesz mieć dużo kodu do zmiany i przetestowania z powodu wcześniejszego użycia ==.

Dlatego najlepiej postępować zgodnie z dobrą praktyką, chyba że istnieje jakikolwiek uzasadniony zysk.

Jedną z zasad Sonaru jest Enum values should be compared with "==". Powody są następujące:

Testowanie równości wartości wyliczeniowej z equals()jest całkowicie poprawne, ponieważ wyliczenie jest Obiektem i każdy programista Java wie, ==że nie należy go używać do porównywania zawartości obiektu. Jednocześnie za pomocą ==wyliczeń:

• zapewnia takie samo oczekiwane porównanie (treść) jak equals()

• jest bardziej bezpieczny niż equals()

• zapewnia sprawdzanie czasu kompilacji (statycznego) zamiast sprawdzania czasu wykonywania

Z tych powodów ==należy preferować użycie equals().

Wreszcie, ==wyliczenia na enum są prawdopodobnie bardziej czytelne (mniej gadatliwe) niż equals().

Krótko mówiąc, oba mają zalety i wady.

Z jednej strony ma zalety w użyciu == , jak opisano w innych odpowiedziach.

Z drugiej strony, jeśli z jakiegoś powodu zastąpisz wyliczenia innym podejściem (normalne instancje klasy), po użyciu ==cię ugryzie. (BTDT.)

Chcę uzupełnić odpowiedź wieloskładnikowe środki smarne:

Osobiście wolę equals (). Ale to sprawdza zgodność typu. Co uważam za ważne ograniczenie.

Aby sprawdzić zgodność typów w czasie kompilacji, zadeklaruj i użyj niestandardowej funkcji w swoim wyliczeniu.

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

Dzięki temu zyskujesz wszystkie zalety obu rozwiązań: ochronę NPE, łatwy do odczytania kod i kontrolę zgodności typów w czasie kompilacji.

Polecam również dodać wartość UNDEFINED dla wyliczenia.

==może rzucać, NullPointerExceptionjeśli typ pierwotny jest porównywany z wersją klasy. Na przykład:

private static Integer getInteger() {
    return null;
}

private static void foo() {
    int a = 10;

    // Following comparison throws a NPE, it calls equals() on the 
    // non-primitive integer which is itself null. 
    if(a == getInteger()) { 
        // Some code
    }
}