Можем ли мы иметь AtomicEnum в Java?

Question

Сегодня я увидел этот класс утилиты для AtomicEnum, но мне интересно, возможно ли иметь атомное перечисление, почему оно не включено в стандартные библиотеки Java? На самом деле у меня так много сомнений в том, что он может быть действительно атомарным и если этот класс полезности работает.

Класс AtomicEnum является this

1. Как можно исследовать, если он делает операцию атомарен?
2. Есть ли инструмент для просмотра скомпилированного кода и быть уверенным, что он действительно все только в одной машинной инструкции?
3. Возможно ли открыть его из кода?
4. Итак, если этот Atomic enum работает, у меня может быть атрибут AtomicEnum, и можно будет безопасно использовать его без волатильного ключевого слова и синхронизированных геттеров и сеттеров?

Answer 1

Сегодня я увидел этот вспомогательный класс для AtomicEnum, но мне интересно, если это возможно, чтобы иметь атомное перечисление, почему он не входит в стандартные библиотеки Java?

AtomicEnum класс, который вы связаны только оберточной класс AtomicReference, который дает одновременный доступ к любому Object.

Действительно, все, что вам нужно, если у вас есть несколько потоков, которые получают и устанавливают его одновременно. Ключевое слово volatile гарантирует, что обновления, сделанные одним потоком, будут видны другими потоками. Вам нужен AtomicReference, если вам нужно сделать тип метода compareAndSet(...) - атомно проверить, является ли поле конкретным значением и только затем его обновить.

Как проверить, выполняются ли операции атомарно?

AtomicReference является частью классов java.util.concurrent, которые хорошо протестированы.

Есть ли инструмент для просмотра скомпилированного кода и быть уверенным, что он действительно работает только в одной машинной инструкции?

Это не должно быть необходимо. Вы можете посмотреть источник AtomicReference, если хотите посмотреть, что он делает. К сожалению, настоящая магия находится в собственном коде sun.misc.Unsafe.

Возможно ли открыть его из кода?

Это не должно быть необходимо.

Итак, если это Атомное перечисление работает, у меня может быть атрибут AtomicEnum, и можно будет безопасно использовать его без летучих ключевых слов и синхронизированных геттеров и сеттеров?

Да, AtomicReference обертывания volatile V value, так что вы не должны делать это.

Answer 2

Это AtomicEnum - это просто тонкая обертка вокруг AtomicReference, что имеет смысл, так как значение n enum - это просто объект (ссылка).

Так еслиAtomicReference работает правильно (и я думаю, мы можем предположить, что), то AtomicEnum будет работать.

Answer 3

Доступ к ссылке является атомарным, но доступ к объекту не является. Таким образом, изменение значения ссылки будет правильно распространено во всех потоках, но изменение фактического объекта перечисления может и не быть.
Пример ...

enum Weekdays { 
    public int rank = 0; 
    MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY; 
} 

Случай 1:

AtomicEnum<Weekdays> today = Weekdays.TUESDAY; 

Каждый обмен нитка 'сегодня' будет иметь ссылку на Weekdays.TUESDAY

Случай 2:

today.rank = 3; 

Нет гарантии, что каждый поток будет иметь обновленный ранг. (ранг не является изменчивым. Каждый хранит отдельную копию объекта в кеше.)

Таким образом, доступ к ссылке является атомарным, но для объекта это не так.
Примечание:
1) Атомный доступ не означает выполнение в одной машинной инструкции. Но логически это можно так подумать. Хотя он неделим, он может содержать несколько инструкций.
2) Даже если такой инструмент существует, было бы сложно проверить его, поскольку процесс обновления почти непредсказуем. Таким образом, возможны ложные положительные результаты.

Надеюсь, это поможет.

Answer 4

Я думаю, что нет никакого смысла писать такой класс. На самом деле, если вы пишете такой класс, вам нужно пересмотреть вопрос об ответственности класса. ENUMs абсолютно потокобезопасны, поэтому я не уверен, почему кому-то нужен AtominEnum, или это просто какой-то класс, который является Atomic, а также использует некоторый enum, но затем называет его AtomicEnum очень запутанным, не очень хорошо подходит для разработки или соглашения об именах.