Конкурентная изменяемость

AtomicInt/AtomicLong

Первые два — это простые числовые типы: AtomicInt и AtomicLong. Они позволяют иметь общее Int или Long, которое можно читать и изменять из нескольких потоков.

object AtomicDataCounter {
    val count = AtomicInt(3)
  
    fun addOne() {
        count.increment()
    }
}

Приведенный выше пример представляет собой глобальное object, которое по умолчанию заморожено в Kotlin/Native. Однако в этом случае вы можете изменять значение count. Важно отметить, что вы можете изменить значение count из любого потока.

AtomicReference

AtomicReference хранит экземпляр объекта, и вы можете изменить этот экземпляр объекта. Объект, который вы помещаете в AtomicReference, должен быть заморожен, но вы можете изменить значение, которое AtomicReference содержит. Например, следующее не будет работать в Kotlin/Native:

data class SomeData(val i: Int)

object GlobalData {
    var sd = SomeData(0)

    fun storeNewValue(i: Int) {
        sd = SomeData(i) //Doesn't work
    }
}

Согласно правилам глобального состояния, глобальные object значения замораживаются в Kotlin/Native, поэтому попытка изменить sd завершится ошибкой. Вы можете реализовать это с помощью AtomicReference:

data class SomeData(val i: Int)

object GlobalData {
    val sd = AtomicReference(SomeData(0).freeze())

    fun storeNewValue(i: Int) {
        sd.value = SomeData(i).freeze()
    }
}

Сам AtomicReference заморожен, что позволяет ему существовать внутри замороженного объекта. Данные в экземпляре AtomicReference явно заморожены в приведенном выше коде. Однако в кроссплатформенных библиотеках данные будут заморожены автоматически. Если вы используете среду выполнения Kotlin/Native, вы должны явно вызвать freeze().

AtomicReference может быть очень полезным, когда вам нужно обмениваться состоянием. Однако следует учитывать некоторые недостатки.

Доступ к значениям и их изменение в AtomicReference очень дорого обходятся с точки зрения производительности по сравнению с стандартным изменяемым состоянием. Если производительность является проблемой, вы можете рассмотреть другой подход, связанный с изолированным состоянием потоков.

Также существует потенциальная проблема с утечками памяти, которая будет решена в будущем. В ситуациях, когда объект, хранящийся в AtomicReference, имеет циклические ссылки, он может утечь память, если вы не очистите его явно:

• Если у вас есть состояние, которое может иметь циклические ссылки и нуждается в освобождении, вы должны использовать тип nullable в AtomicReference и явно установить его в null, когда вы закончите с ним.

• Если вы храните AtomicReference в глобальном объекте, который никогда не выходит из области видимости, это не имеет значения (потому что память никогда не нужно освобождать в течение жизни процесса).

class Container(a:A) {
    val atom = AtomicReference<A?>(a.freeze())

    /**
     * Call when you're done with Container
     */
    fun clear(){
        atom.value = null
    }
}

Наконец, также существует проблема с согласованностью. Установка/получение значений в AtomicReference само по себе является атомным, но если ваша логика требует более длинной цепочки исключения потоков, вам нужно будет реализовать это самостоятельно. Например, если у вас есть список значений в AtomicReference и вы хотите сначала просканировать их перед добавлением нового, вам потребуется некоторая форма управления конкурентностью, которую AtomicReference не предоставляет.

Следующее не защитит от дублирования значений в списке, если оно вызывается из нескольких потоков:

object MyListCache {
    val atomicList = AtomicReference(listOf<String>().freeze())
    fun addEntry(s:String){
        val l = atomicList.value
        val newList = mutableListOf<String>()
        newList.addAll(l)
        if(!newList.contains(s)){
            newList.add(s)
        }
        atomicList.value = newList.freeze()
    }
}

Вам необходимо реализовать некоторую форму блокировки или логики «проверки и установки» для обеспечения правильной конкурентности.

AtomicReference по сравнению с изолированным состоянием потоков

Для простых значений AtomicReference будет, вероятно, более простым вариантом. В случаях с большими состояниями и потенциально значительными изменениями состояния использование изолированного состояния потоков может быть лучшим выбором. Основным штрафом за производительность является фактическое переключение между потоками. Но в тестах производительности с коллекциями, например, изолированное состояние потока значительно превосходит изменяемое состояние, реализованное с помощью AtomicReference.

Изолированное состояние потоков также избегает проблем с согласованностью, которые есть у AtomicReference. Поскольку все операции происходят в потоке состояния и поскольку вы планируете работу, вы можете выполнять операции с несколькими шагами и гарантировать согласованность без управления исключениями потоков. Изоляция потоков — это конструктивная особенность правил состояния Kotlin/Native, и изоляция изменяемых состояний работает с этими правилами.

Изолированное состояние потоков также более гибкое, поскольку вы можете сделать изменяемые состояния конкурентными. Вы можете использовать любой тип изменяемого состояния, а не создавать сложные конкурентные реализации.