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

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 среды выполнения Kotlin/Native, вы должны явно вызвать freeze().

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

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

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

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

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