launch frente a async: efecto o valor

Toda biblioteca de concurrencia acaba ofreciendo dos formas de arrancar trabajo, y la razón es que hay dos preguntas distintas detrás. A veces lo que se quiere es que algo ocurra y basta con saber que ocurrirá; otras veces lo que se quiere es un dato que todavía no existe y que se necesitará más adelante. Kotlin llama a esas dos formas launch y async, y su gran acierto pedagógico y su gran trampa son la misma cosa: las escribe con una sintaxis casi idéntica. Un carácter de diferencia en el nombre separa un constructor que devuelve un Job y trata el fallo como un problema que hay que anunciar de otro que devuelve un Deferred y trata el fallo como parte del resultado que hay que entregar a quien lo reclame. Confundirlos no produce un error de compilación sino un comportamiento distinto ante los errores, que es la categoría de defecto que más tarda en aparecer y más cuesta reproducir.

Dos constructores, dos contratos

El constructor launch declara que hay algo que hacer y que el resultado de hacerlo no es un dato sino un efecto sobre el mundo: escribir en disco, enviar un evento, actualizar una vista. Devuelve un Job, que sirve para esperar y para cancelar, y nada más, porque no hay valor que ofrecer. El constructor async declara que hay un cálculo cuyo resultado se necesitará, y devuelve un Deferred que es un Job con un valor prometido encima.

suspend fun cargarPerfil(id: Id): Perfil = coroutineScope {
    val usuario = async { api.usuario(id) }        // quiero el dato
    val ajustes = async { api.ajustes(id) }        // quiero el dato
    launch { metricas.registrar("perfil", id) }    // solo quiero el efecto

    Perfil(usuario.await(), ajustes.await())
}

Esta llamada dispara las tres corrutinas casi a la vez y no retorna hasta que las tres han terminado, incluida la de métricas aunque su resultado no se use en ninguna parte. Nótese que la elección entre uno y otro no es una cuestión de rendimiento sino de honestidad de la firma: quien lee la línea de métricas sabe de inmediato que su valor no importa, y quien lee las dos primeras sabe que sin ellas no hay perfil.

Deferred no es una promesa clásica

Un Deferred representa un valor futuro, igual que una promesa, pero hay tres diferencias que cambian su forma de usarse. La primera es que hereda de Job, de modo que está registrado en el árbol y se cancela con él; una promesa clásica no tiene padre ni forma estándar de cancelarse. La segunda es que su lectura se hace con una función suspend y no con una devolución de llamada, lo que permite escribir la continuación como código secuencial ordinario en lugar de encadenar transformaciones. Y la tercera es que se puede leer más de una vez sin recalcular nada, porque el valor queda memorizado en el objeto.

val precio: Deferred<Dinero> = async { calcularPrecio() }

val a = precio.await()   // suspende hasta que este listo
val b = precio.await()   // devuelve el mismo valor al instante

La cancelación de un Deferred merece una nota. Cancelarlo cancela el cálculo, y cualquier await pendiente o posterior lanzará una CancellationException en quien esperaba. No hay valor de consuelo ni estado indeterminado: o el valor existe, o existe una excepción que explica por qué no existe.

Ambos constructores admiten además un modo de arranque diferido, en el que la corrutina se crea pero no empieza hasta que alguien la reclama. Es el único caso en que un Deferred se parece de verdad a un cálculo perezoso, y su utilidad se limita a situaciones en las que se preparan varias alternativas y solo se necesitará una.

val caro = async(start = CoroutineStart.LAZY) { calculoCostoso() }

if (haceFalta) {
    usar(caro.await())      // solo aqui empieza a ejecutarse
} else {
    caro.cancel()           // nunca llego a arrancar
}

Conviene usarlo con parsimonia, porque introduce una asimetría peligrosa: la corrutina diferida es hija del ámbito desde que se crea, de modo que el bloque no retornará hasta que ella termine, y si nadie la arranca ni la cancela el ámbito entero se queda esperando a algo que jamás va a ocurrir. El arranque diferido es la única forma de provocar un bloqueo permanente en un ámbito estructurado que por lo demás está bien escrito.

flowchart TD
A[Constructor de corrutina] --> B[launch devuelve Job]
A --> C[async devuelve Deferred]
B --> D[El fallo sube al padre de inmediato]
C --> E[El fallo se guarda en el resultado]
E --> F[Se relanza cuando alguien llama a await]
D --> G[Cancela hermanos y ambito]

Por qué las excepciones se comportan al revés

Esta es la diferencia que de verdad importa y no es un capricho de la biblioteca: se deduce del contrato de cada constructor. Como el resultado de launch no se consulta nunca, si su excepción no se anunciara de inmediato se perdería para siempre; por eso una corrutina lanzada con launch propaga el fallo hacia arriba en cuanto ocurre, cancelando a sus hermanos y llegando en última instancia al manejador de excepciones del ámbito o al del hilo. Como el resultado de async sí se consulta, la excepción es parte de ese resultado y se entrega en el mismo lugar y en el mismo momento en que se habría entregado el valor, es decir, dentro del await.

// Con launch: el fallo estalla donde ocurre, no donde se espera
scope.launch {
    error("boom")            // llega al manejador del ambito
}

// Con async: el fallo espera en el resultado
val d = scope.async { error("boom") }
try {
    d.await()                // aqui, y solo aqui, se relanza
} catch (e: IllegalStateException) {
    manejar(e)
}

Aquí aparece la sutileza que engaña a casi todo el mundo. En un async hijo de un ámbito estructurado, envolver el await en un try captura la excepción, sí, pero no impide que el fallo haya subido también al padre por la vía estructural y haya cancelado a los hermanos. Es decir, capturar el error en el punto de espera no lo desactiva como fallo del árbol. La única forma de que un async falle sin arrastrar a nadie es que su padre sea un supervisor, que es justo el tema de la última lección de este nivel.

Paralelizar de verdad

Los dos errores más comunes al usar async no tienen que ver con excepciones sino con no obtener el paralelismo que se creía haber escrito. El primero es esperar demasiado pronto: si se invoca await inmediatamente después de crear cada tarea, las llamadas se serializan y el código es más complicado que la versión secuencial sin ser más rápido.

// Secuencial disfrazado: cada await bloquea el arranque del siguiente
val a = async { primero() }.await()
val b = async { segundo() }.await()

// Paralelo real: primero se arranca todo, despues se espera
val ta = async { primero() }
val tb = async { segundo() }
val resultado = combinar(ta.await(), tb.await())

El segundo error es más grave y consiste en lanzar el async en un ámbito que no es el de la operación en curso, típicamente un ámbito guardado en una propiedad de la clase. El código funciona, pero la tarea deja de pertenecer a la llamada: no se cancela cuando la llamada se cancela y su fallo se propaga a un árbol que no tiene nada que ver. La regla es que las tareas auxiliares de una operación deben nacer del ámbito local de esa operación, creado con coroutineScope.

Cuando el número de tareas no se conoce de antemano porque proviene de una colección, la forma correcta es construir la lista de tareas primero y esperarla después con awaitAll, que además tiene una propiedad valiosa: si alguna falla, relanza el primer fallo sin esperar al resto en lugar de ir descubriendo los errores de uno en uno.

suspend fun cargarTodos(ids: List<Id>): List<Perfil> = coroutineScope {
    ids.map { id -> async { api.perfil(id) } }.awaitAll()
}

Queda una advertencia sobre este idioma que se olvida con frecuencia: paralelizar una colección de tamaño desconocido significa abrir tantas peticiones simultáneas como elementos tenga, lo que puede agotar un pozo de conexiones o provocar que el servicio remoto empiece a rechazar. La estructura del árbol garantiza la corrección del flujo, no la prudencia con los recursos; limitar la concurrencia sigue siendo responsabilidad de quien escribe, normalmente con un semáforo o troceando la colección.