Bloquear es el pecado: pools hambrientos y cómo evitarlos

La primera vez que alguien escribe una llamada bloqueante dentro de una corrutina no pasa nada malo, y ese es justamente el problema. El código funciona, las pruebas pasan, la revisión no dice nada y el defecto queda sembrado esperando a que la concurrencia real supere un umbral que nadie ha calculado. Entonces, un martes cualquiera, la latencia se multiplica por veinte sin que ninguna métrica de procesador, memoria o red muestre saturación, porque el recurso que se agotó no es ninguno de esos sino algo que no se estaba midiendo: los hilos disponibles para reanudar continuaciones. La suspensión existe precisamente para no consumir ese recurso mientras se espera, y una llamada bloqueante lo consume igualmente, anulando la única propiedad que hacía barata a toda la maquinaria. Esta lección trata ese fallo con la seriedad que merece, porque no es un defecto de rendimiento sino un defecto de disponibilidad.

La aritmética de la inanición

Una suspensión libera el hilo: la continuación se guarda como objeto, el trabajador vuelve a la cola y recoge otra tarea. Un bloqueo hace lo contrario: el hilo entra en espera dentro del sistema operativo con la pila de la corrutina encima y no puede recoger nada más hasta que la espera termine. Sobre un pool con tantos hilos como núcleos, esa diferencia se traduce en una fracción exacta. En una máquina de ocho núcleos, una llamada bloqueante ocupa un octavo de toda la capacidad de cómputo del proceso durante el tiempo que dure; ocho llamadas simultáneas la ocupan entera y ninguna otra corrutina progresa, ni siquiera las que solo necesitaban un microsegundo de procesador.

// Cada una de estas corrutinas secuestra un hilo del pool de computo
repeat(8) {
    launch(Dispatchers.Default) {
        Thread.sleep(5_000)      // bloquea: el hilo no puede hacer nada mas
    }
}

// La siguiente no se ejecutara hasta que alguna de las anteriores termine
launch(Dispatchers.Default) { println("tarea trivial") }

El caso patológico se alcanza cuando el trabajo bloqueado depende de trabajo que necesita el mismo pool para completarse. Ahí no hay lentitud sino interbloqueo: los hilos ocupados esperan un resultado que solo podría producir un hilo que ya no existe. Ocurre con más facilidad de la que parece cuando se combinan pools de un solo hilo, esperas sobre resultados diferidos y llamadas bloqueantes anidadas, y es especialmente cruel porque el volcado de hilos muestra trabajadores dormidos y una máquina completamente ociosa.

flowchart TD
A[Corrutina con llamada bloqueante] --> B[Hilo trabajador ocupado]
B --> C[Cola de tareas pendientes crece]
C --> D{Quedan hilos libres}
D -->|si| E[Latencia degradada]
D -->|no| F[Inanicion total del pool]
F --> G{El trabajo esperado necesita el pool}
G -->|no| H[Se recupera al terminar la espera]
G -->|si| I[Interbloqueo permanente]

La comparación con la suspensión aclara por qué la diferencia es cualitativa y no de grado. Suspender guarda el estado de la corrutina en un objeto del montículo, de unos pocos cientos de bytes, y libera un recurso caro. Bloquear retiene ese recurso caro y además mantiene viva una pila de un megabyte reservada por el sistema. Cien mil corrutinas suspendidas caben sin esfuerzo en un proceso normal; cien mil hilos bloqueados no caben en ninguno.

Conviene tener presente que el pool de espera no es inmune, solo más tolerante. Su cuota por defecto es mucho mayor, así que absorbe un número de bloqueos que el pool de cómputo no absorbería, pero sigue siendo finita y comparte trabajadores con el otro. Bloquear allí es aceptable por diseño; bloquear allí sin acotar el paralelismo por recurso convierte una cola externa en una cola interna invisible.

Detectarlo antes que producción

Ninguna de estas técnicas sustituye a las demás porque cada una actúa en un momento distinto del ciclo de vida. La instrumentación actúa en desarrollo y convierte el defecto en un fallo antes de que se integre; el modo de depuración actúa durante la investigación y hace legible lo que ocurrió; el volcado y la métrica de cola actúan en producción y son lo único disponible cuando el incidente ya está en curso. Un equipo maduro tiene las cuatro activas en el entorno que corresponde a cada una.

La métrica de la última tarjeta merece implementarse en cualquier sistema serio porque es barata y detecta el problema desde el ángulo correcto. Consiste en lanzar periódicamente una corrutina que no hace nada, medir cuánto tarda desde que se encola hasta que empieza y publicar ese valor. Si el pool está sano, el número vive en las decenas de microsegundos. Si alguien bloquea, se dispara a cientos de milisegundos mucho antes de que la latencia de usuario se degrade lo bastante como para generar una alerta.

suspend fun latenciaDeCola(despacho: CoroutineDispatcher): Long = coroutineScope {
    val inicio = System.nanoTime()
    withContext(despacho) { /* no hace nada a proposito */ }
    (System.nanoTime() - inicio) / 1_000
}

runBlocking y sus tres usos legítimos

La función construye un puente en la dirección contraria a la habitual: crea una corrutina y bloquea el hilo actual hasta que termina, procesando mientras tanto las tareas de su propio despachador de eventos. Esa descripción ya contiene la advertencia, porque bloquear el hilo actual es exactamente lo que el resto de la lección desaconseja. Sus usos defendibles son tres y ninguno más.

El primero es el punto de entrada de un programa, donde el hilo principal no tiene nada mejor que hacer que esperar. El segundo es la implementación de una interfaz bloqueante que no controlas, cuando tu código interno es suspendido y debes exponerlo con una firma síncrona en la frontera exacta del sistema. El tercero son ciertas pruebas antiguas, aunque hoy la herramienta correcta es el constructor de pruebas de la propia librería, que además controla el tiempo virtual y detecta corrutinas huérfanas.

fun main() = runBlocking {
    servidor.arrancar()
    esperarSenalDeParada()
}

// Frontera con una interfaz ajena que exige una firma sincrona
class AdaptadorLegado(private val ambito: CoroutineScope) : ProcesadorSincrono {
    override fun procesar(entrada: Entrada): Salida = runBlocking {
        servicioSuspendido.procesar(entrada)
    }
}

Merece la pena entender por qué el interbloqueo con un solo hilo es inmediato y no probabilístico. La función bloquea el hilo actual y procesa entretanto las tareas encoladas en su propio despachador de eventos, no en el del dispatcher exterior. Si la corrutina interior necesita ese dispatcher exterior para progresar, y ese dispatcher tiene un único hilo que es precisamente el que está bloqueado, no queda nadie que pueda ejecutar la tarea que desbloquearía la espera. El ciclo se cierra en la primera ejecución y no depende de la carga ni del azar.

val unico = Dispatchers.Default.limitedParallelism(1)

// Interbloqueo garantizado: el hilo unico esta bloqueado esperandose a si mismo
suspend fun trampa() = withContext(unico) {
    runBlocking { withContext(unico) { println("nunca llega") } }
}

Adaptar una API bloqueante con disciplina

Cuando la biblioteca que hay al otro lado no ofrece versión suspendida, la adaptación correcta tiene tres partes y las tres son necesarias. La primera es aislar la llamada en un dispatcher de espera acotado al tamaño del recurso real, no al genérico, para que el número de bloqueos simultáneos sea una decisión explícita. La segunda es exponer una función suspendida cuyo contrato sea seguro desde cualquier sitio, de modo que ningún llamante herede el requisito. La tercera, y la que más se olvida, es respetar la cancelación: una llamada bloqueante no se entera de que la corrutina fue cancelada, así que hay que interrumpirla o cerrar el recurso desde fuera.

class ClienteHeredado(private val impl: ApiBloqueante) {
    private val despacho = Dispatchers.IO.limitedParallelism(8)

    suspend fun consultar(clave: String): Registro = withContext(despacho) {
        runInterruptible { impl.consultarBloqueante(clave) }
    }
}

El tamaño del paralelismo no es un número decorativo y merece justificarse por escrito junto a la declaración. Si al otro lado hay un pool de ocho conexiones, permitir dieciséis llamadas simultáneas no dobla el rendimiento: pone ocho peticiones a esperar dentro del cliente, donde no hay métricas, en lugar de esperar en la cola del dispatcher, donde sí las hay. Si al otro lado hay una API con un límite de peticiones por segundo, el número debe derivarse de ese límite y de la latencia media. En ambos casos el criterio es el mismo: el dispatcher debe ser el punto donde se materializa la escasez del recurso externo, no un embudo colocado por costumbre.

La función que aparece en el ejemplo anterior es la pieza clave y suele desconocerse: ejecuta el bloque de forma que la cancelación de la corrutina se traduzca en una interrupción del hilo, que es el único mecanismo que las bibliotecas bloqueantes de la plataforma entienden. Sin ella, cancelar la corrutina marca el trabajo como cancelado y devuelve el control al llamante, pero el hilo sigue secuestrado hasta que la llamada original termine por su cuenta, con lo que la cancelación deja de acotar el consumo de recursos y se convierte en una ficción contable.