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

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 , имеет циклические ссылки, может произойти утечка памяти, если вы не очистите его явно:

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

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