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

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 явно заморожены в приведенном выше коде. Однако, в кроссплатформенных библиотеках данные будут замораживаться автоматически. Если вы используете AtomicReference runtime 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, и изоляция изменяемых состояний работает с этими правилами.

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