Regla
Liberar bloquea incluso en excepción caminos. 
Cada bloqueo adquisición debe tener a garantizado
liberación, incluso cuando excepciones excepciones. 

Idiomas compatibles lenguajes:** Java, C, C++, PHP, JavaScript,
TypeScript, Go, Python

Introducción

Los bloqueos no liberados son una de las causas más comunes de deadlocks y cuelgues del sistema en aplicaciones Node.js en producción. Cuando se produce una excepción entre la adquisición y la liberación del bloqueo, éste permanece retenido indefinidamente. Otras operaciones asíncronas que esperan ese bloqueo se bloquean para siempre, causando fallos en cascada en todo el sistema. Un solo mutex sin liberar puede hacer caer una API entera porque el bucle de eventos se bloquea y las peticiones se acumulan. Esto ocurre con bibliotecas como async-mutex, mutexificaro cualquier implementación de bloqueo manual en la que la liberación no sea automática.

Por qué es importante

Estabilidad y disponibilidad del sistema: Los bloqueos no liberados provocan bloqueos que congelan las operaciones asíncronas en Node.js. En servidores Express o Fastify, esto agota los trabajadores disponibles, haciendo que la aplicación no pueda gestionar nuevas peticiones. La única forma de recuperarse es reiniciar el proceso, lo que provoca tiempo de inactividad. En las arquitecturas de microservicios, los bloqueos no liberados en un servicio pueden provocar fallos en cascada en los servicios dependientes a medida que se agotan los tiempos de espera de las respuestas.

Degradación del rendimiento: Antes de un bloqueo completo, los bloqueos no liberados causan graves problemas de rendimiento. Las operaciones asíncronas compiten por los recursos bloqueados, creando una cola de promesas pendientes que nunca se resuelven. La contención de bloqueos crea picos de latencia impredecibles que degradan la experiencia del usuario. A medida que aumenta el número de solicitudes concurrentes bajo carga, la contención se agrava exponencialmente.

Complejidad de depuración: Los bloqueos por bloqueos no liberados son notoriamente difíciles de depurar en aplicaciones Node.js en producción. Los síntomas parecen estar lejos de la causa raíz, los cuelgues de proceso muestran promesas pendientes pero no qué ruta de excepción falló para liberar el bloqueo. Reproducir la secuencia exacta de excepciones que desencadenaron el bloqueo es a menudo imposible en entornos de desarrollo.

Agotamiento de recursos: Más allá de los propios bloqueos, el fallo en la liberación de bloqueos a menudo se correlaciona con el fallo en la liberación de otros recursos como conexiones a bases de datos, clientes Redis o manejadores de archivos. Esto agrava el problema, creando múltiples fugas de recursos que hacen que los sistemas se caigan más rápido bajo carga.

Ejemplos de códigos

❌ No conforme:

const { Mutex } = require('async-mutex');
const accountMutex = new Mutex();

async function transferFunds(from, to, amount) {
    await accountMutex.acquire();

    if (from.balance < amount) {
        throw new Error('Insufficient funds');
    }

    from.balance -= amount;
    to.balance += amount;

    accountMutex.release();
}

Por qué es inseguro: Si se produce un error de insuficiencia de fondos, accountMutex.release() nunca se ejecuta y el mutex permanece bloqueado para siempre. Todas las llamadas posteriores a transferFondos() se colgará esperando el mutex, congelando todo el sistema de pago.

✅ Conforme:

const { Mutex } = require('async-mutex');
const accountMutex = new Mutex();

async function transferFunds(from, to, amount) {
    const release = await accountMutex.acquire();
    try {
        if (from.balance < amount) {
            throw new Error('Insufficient funds');
        }
        
        from.balance -= amount;
        to.balance += amount;
    } catch (error) {
        logger.error('Transfer failed', { 
            fromId: from.id, 
            toId: to.id, 
            amount,
            error: error.message 
        });
        throw error;
    } finally {
        release();
    }
}

Por qué es seguro: En captura registra el error con contexto antes de volver a lanzarlo, y el bloque finalmente garantiza que la función de liberación del mutex se ejecute tanto si la operación tiene éxito como si lanza un error, o si el error se vuelve a lanzar desde catch. El bloqueo siempre se libera, evitando bloqueos.

Conclusión

La liberación del bloqueo debe estar garantizada, no condicionada al éxito de la ejecución. Utilice try-finally en JavaScript o los bloques runExclusive() proporcionado por bibliotecas como async-mutex. Cada adquisición de bloqueo debe tener una ruta de liberación incondicional visible en el mismo bloque de código. Una gestión adecuada de los bloqueos no es opcional, es la diferencia entre un sistema estable y otro que se cuelga aleatoriamente bajo carga.