Я много раз использовал AtomicLong, но я никогда не должен был использовать AtomicReference
Кажется, что AtomicReference делает любого (я скопировал этот код с другого stackoverflow вопроса):
public synchronized boolean compareAndSet(List<Object> oldValue, List<Object> newValue) {
if (this.someList == oldValue) {
// someList could be changed by another thread after that compare,
// and before this set
this.someList = newValue;
return true;
}
return false;
}
Или
public synchronized boolean compareAndSet(List<Object> oldValue, List<Object> newValue) {
if (this.someList == oldValue || this.someList.equals(oldValue)) {
// someList could be changed by another thread after that compare,
// and before this set
this.someList = newValue;
return true;
}
return false;
}
Предположите, что this.someList отмечен энергозависимый.
Я не уверен действительно, какой это - потому что javadoc и код для того класса не ясны, используется ли .equals.
Наблюдение, как вышеупомянутые методы не точно, что трудно записать кому-либо когда-либо использовало AtomicReference?
Это ссылка , вот что сравнивается. В документации четко указано, что это сравнение идентичности, даже с использованием операции ==
в ее описании.
Я очень часто использую AtomicReference
и другие атомарные классы. Профилирование показывает, что они работают лучше, чем эквивалентные методы, использующие синхронизацию. Например, операция get ()
для AtomicReference
требует только выборки из основной памяти, в то время как аналогичная операция с использованием synchronized
должна сначала очистить все кэшированные значения. потоками в основную память, а затем выполнить его выборку.
Классы AtomicXXX
предоставляют доступ к встроенной поддержке операций сравнения и замены (CAS). Если базовая система поддерживает это, CAS будет быстрее, чем любая схема, созданная с синхронизированными
блоками в чистой Java.