Rendimiento, leaks y los errores que solo aparecen bajo carga

El primer malentendido, y el más caro, es que `suspend` significa concurrente. No lo significa: una función suspendible corre secuencialmente, exactamente como una normal, y `listOf(a, b, c).map { fetch(it) }` hace tres llamadas una tras otra. La concurrencia es opcional y siempre visible — `async` + `awaitAll`, `launch` dentro de un `coroutineScope`, o `flatMapMerge` sobre un Flow. Cuando un handler que debería tardar 100 ms tarda 300, lo primero a revisar es si tres awaits independientes se escribieron como tres sentencias secuenciales.

El segundo es que una corrutina no es gratis. Es muchísimo más barata que un hilo — una corrutina suspendida es un objeto chico en el heap, así que cien mil de ellas no son nada donde cien mil hilos son imposibles — pero cada una igual carga un `Job`, un contexto y objetos de continuación. Lanzar una por elemento de una colección grande para hacer trabajo trivial es más lento que un bucle común; la ganancia viene de *esperar* barato, no de computar barato. Las corrutinas hacen escalar el trabajo ligado a I/O; no hacen nada por el trabajo ligado a CPU salvo dejarte distribuirlo explícitamente.

El tercero, y el que tira producción abajo, es bloquear el dispatcher equivocado. `Dispatchers.Default` está dimensionado según tu cantidad de CPUs, y el event loop de Netty es aproximadamente un hilo por núcleo: un solo `Thread.sleep`, una llamada JDBC, un request de `RestTemplate` o un `File.readText` en uno de esos hilos elimina una fracción significativa de toda tu capacidad mientras dure. Bajo carga no es lento, es un atasco. La salida de emergencia correcta es `withContext(Dispatchers.IO) { … }` — un pool elástico grande hecho justo para esto — y el destino correcto es un driver no bloqueante para no necesitar la salida de emergencia.

`Dispatchers.IO` no es ilimitado, y tratarlo como vertedero es su propio modo de fallo. Por defecto tiene 64 hilos (o la cantidad de CPUs si es mayor), y un subsistema que lo satura mata de hambre a todas las demás llamadas bloqueantes del proceso. `Dispatchers.IO.limitedParallelism(n)` recorta una vista acotada para un subsistema — un cliente heredado, un generador de reportes, un job de exportación — así una dependencia lenta no puede consumir todo el pool. Es un cambio de dos palabras con el radio de acción de un mamparo.

Los leaks en código de corrutinas casi siempre tienen una de dos formas. La primera es `GlobalScope`: no tiene un `Job` que nadie posea, así que nada cancela nunca a sus hijos, y una corrutina lanzada ahí sobrevive al request, a la pantalla o al objeto que la arrancó. La segunda es un scope que creaste y nunca cancelaste — un campo `CoroutineScope(...)` en un componente sin `close()`. Ambos se encuentran igual: cada `launch` debería poder rastrearse a un scope cuya vida podés nombrar en voz alta, y si no podés nombrarla, es un leak.

`runBlocking` merece su propia advertencia. Puentea código bloqueante a código suspendible aparcando el hilo llamador hasta que el cuerpo completa — lo cual es correcto en una función `main` o en un test, y un bug en cualquier lugar dentro de un request de servidor. En un hilo de event loop bloquea el loop; llamado desde dentro de otra corrutina bloquea un hilo del pool y puede deadlockear directamente si el cuerpo necesita ese mismo dispatcher acotado para avanzar. Si encontrás `runBlocking` en un handler, el arreglo no es tunearlo, es hacer `suspend` al llamador.

Vale conocer dos costos menores. **Fan-out sin límite**: `list.map { async { call(it) } }.awaitAll()` sobre una lista de diez mil elementos dispara diez mil requests simultáneos, que es una denegación de servicio que escribiste vos — acotalo con `Semaphore(k)` o `flatMapMerge(concurrency = k)`. Y **buffering sin límite**: `Channel.UNLIMITED`, `buffer(Int.MAX_VALUE)` o un replay de `MutableSharedFlow` que crece sin parar convierten un desajuste productor/consumidor de una desaceleración en un error de memoria, que es estrictamente peor porque el back-pressure te habría avisado que algo andaba mal.

Medí antes de tunear. El reloj virtual de `runTest` convierte «¿este pipeline es secuencial?» en un número exacto, así que la pregunta secuencial-versus-buffered se responde en un test y no en producción. Agregá `-Dkotlinx.coroutines.debug` para tener nombres de corrutina en los thread dumps, y nombrá tus corrutinas para que esos dumps signifiquen algo. Y cuando un handler está lento, revisá los tres sospechosos habituales en orden: awaits secuenciales que deberían ser concurrentes, una llamada bloqueante en un dispatcher chico, y un fan-out sin límite chocando contra un rate limit — en la práctica casi siempre es uno de esos tres.