Estado mutable compartido: Mutex, atómicos y confinamiento

El malentendido más peligroso sobre corrutinas es que un dispatcher de un solo hilo vuelve seguro al estado compartido. No lo hace. Las corrutinas se entrelazan en los **puntos de suspensión**, y cualquier código con la forma «leé un valor, suspendé, escribilo de vuelta» puede tener a todas las demás corrutinas corriendo en el hueco. `val current = stock; delay(1); stock = current - 1` va a sobrevender en `Dispatchers.Main`, en `runTest`, en un solo hilo, de forma determinista. Lo que rompe las operaciones compuestas es la concurrencia, no el paralelismo, y las corrutinas te dan muchísima concurrencia.

El modo de fallo tiene nombre — la **actualización perdida** — y una firma distintiva. Cinco corrutinas leen un stock de tres, todas calculan `3 - 1`, todas escriben `2`. Cinco ventas, tres unidades, y un conteo final de dos: un estado aritméticamente imposible, que es la versión educada. La mayoría de las actualizaciones perdidas no se ven imposibles; simplemente subcuentan una métrica en silencio o aplican un descuento dos veces, y nada alerta porque nunca se lanza una excepción.

La primera herramienta es `Mutex`. `mutex.withLock { … }` es el lock nativo de corrutinas: **suspende** en vez de bloquear un hilo, así que es seguro en un event loop donde un `ReentrantLock` aparcaría un hilo de Netty y sería una caída de verdad. Es `lock()` más `try/finally { unlock() }`, así que un cuerpo que lanza no puede filtrar el lock. Dos propiedades vale memorizar: **no es reentrante** — llamar a una función con `withLock` desde adentro de otro `withLock` del mismo mutex deadlockea para siempre, sin excepción ni timeout — y protege solo lo que está *adentro* del bloque, así que un lock sobre la escritura pero no sobre la lectura es exactamente el bug del que partiste.

La segunda herramienta es un **atómico**: `AtomicInteger`, `AtomicReference` o el `atomicfu` de Kotlin. Son perfectos para un *único* compare-and-set — `counter.incrementAndGet()` es correcto, sin locks y barato. Solos no sirven para «leer, decidir y después escribir», porque la decisión ocurre fuera de la operación atómica. La forma honesta es `updateAndGet { … }` (o un bucle de reintento con CAS), que re-ejecuta la transformación hasta ganar; cualquier cosa más larga que eso quiere un lock.

La tercera herramienta es el **confinamiento**, y suele ser la mejor. Dale al estado un único dueño — una corrutina que lee comandos de un `Channel` y es el único código que toca los datos — y mandale mensajes en vez de compartir una referencia. No hay lock que olvidar, ni sección crítica que hacer mal, y los invariantes viven en un lugar que podés leer de arriba abajo. Cuesta un salto de mensaje, y deja de ser cómodo cuando un llamador necesita una respuesta síncrona (que recuperás mandando un `CompletableDeferred` junto con el pedido). Este es el modelo de actores, y `kotlinx.coroutines` supo traer un builder `actor { }`; el patrón sobrevivió al builder y hoy se escribe con un `Channel` corriente.

La cuarta herramienta es no compartir nada. La mayoría del «estado compartido» en un servidor con scope por request no necesita compartirse: construí el resultado de forma inmutable, devolvelo, y dejá que el llamador combine. `coroutineScope { val a = async { … }; val b = async { … }; combinar(a.await(), b.await()) }` tiene dos operaciones concurrentes y cero estado mutable compartido, y no necesita sincronización de ningún tipo. Cuando te encontrás buscando un lock dentro de un handler de request, vale preguntarse si la variable necesita sobrevivir a la llamada.

Una palabra sobre `@Volatile`, porque es la respuesta equivocada que más se ofrece. `@Volatile` arregla la **visibilidad** — garantiza que una escritura de un hilo la vea otro — y no hace nada por la **atomicidad**. `@Volatile var count = 0; count++` sigue siendo una actualización perdida, porque `++` es una lectura, una suma y una escritura. Si la operación es compuesta, la volatilidad es irrelevante; si es una única escritura de un valor calculado aparte, la volatilidad es exactamente lo que necesitás.

La decisión, comprimida. Un contador, una operación → un atómico. Una operación compuesta corta sobre un estado → un `Mutex`. Un conjunto de estado relacionado con invariantes reales → confinalo detrás de un canal. Estado que no necesita sobrevivir al request → no lo compartas. Y elijas lo que elijas, poder decir *por qué* en una frase, porque «usamos un Mutex» no es una respuesta y «la lectura y la escritura tienen que ser un solo paso indivisible, así que ambas están dentro del lock» sí lo es.