El Fin del Bloqueo Global: Concurrencia Granular en Grails con ConcurrentHashMap

Cuando desarrollamos sistemas de misión crítica, como la gestión de inventarios o pasarelas de pago, la integridad de los datos lo es todo. Un error común para evitar que dos usuarios modifiquen el mismo recurso simultáneamente es recurrir a soluciones drásticas: la sincronización global.

Etiquetar un método de servicio con bloqueos globales o usar palabras clave como `@Synchronized` o bloques `synchronized(this)` en Grails parece la salida rápida. Sin embargo, tiene un costo arquitectónico altísimo: destruye por completo el paralelismo y la concurrencia de la aplicación.

En este artículo analizaremos por qué el bloqueo global es un antipatrón para operaciones de alta demanda y cómo resolverlo implementando un Manejador de Candados Semánticos (Lock Manager) nativo en memoria con herramientas de la JVM.

El Reto Técnico

Durante un evento de ventas masivas de alta concurrencia, las métricas de rendimiento de nuestra API comenzaron a degradarse rápidamente. La latencia promedio de los endpoints de actualización de inventario subió de 150ms a más de 8 segundos en cuestión de minutos, provocando bloqueos por tiempo de espera en el cliente (Gateway Timeout) y quejas de los usuarios.

Al inspeccionar el comportamiento de los hilos en el servidor, descubrimos un cuello de botella artificial. Para evitar que dos ventas descontaran stock del mismo producto a la vez, se había implementado un bloqueo exclusivo global.

Si el Hilo A procesaba una venta para el Producto ID: 001:

• El Hilo B, que intentaba vender el Producto ID: 999 (completamente distinto e independiente), era obligado a esperar en cola hasta que el Hilo A terminara.

Bloquear a todos los usuarios de la plataforma por culpa de una operación en un producto específico satura el pool de hilos de Tomcat/Jetty. Lo que realmente buscamos es lograr concurrencia granular: que el bloqueo ocurra únicamente si dos o más peticiones compiten por el mismo recurso en específico (el mismo ID de producto).

La Arquitectura de la Solución

Para solucionar esta contención sin recurrir a bases de datos distribuidas ni alterar la infraestructura física, implementamos una arquitectura basada en un Manejador de Candados Semánticos (Lock Manager) a nivel de aplicación en memoria.

Esta estrategia descentraliza el cuello de botella mediante tres conceptos clave:

• Granularidad Semántica: Definimos claves únicas concatenando los identificadores de los recursos que compiten (por ejemplo, productoId y loteCodigo).
• Almacenamiento Concurrente: Mapeamos cada clave exclusiva a un candado de la JVM en un mapa concurrente seguro, garantizando lecturas y escrituras atómicas ultrarrápidas.
• Encolamiento de Hilos Local: Cuando un hilo intenta adquirir un candado ocupado, la ejecución de la JVM se suspende de manera controlada y encola proactivamente en memoria, liberando la base de datos hasta que el candado original se libere.

Balances y Limitaciones de Arquitectura

Para resolver cuellos de botella por concurrencia, un arquitecto debe evaluar el equilibrio entre complejidad, rendimiento e infraestructura disponible:

Para aplicaciones que operan bajo una infraestructura simplificada (una sola instancia activa o monolitos de alto rendimiento en la JVM), la opción en memoria utilizando componentes nativos de Java es, por mucho, la más eficiente y elegante.

La Solución: El Patrón Lock Manager en la JVM

Para lograr un bloqueo exclusivo por \”llave\” o \”segmento\”, podemos diseñar un servicio que administre candados dinámicos en memoria utilizando un `ConcurrentHashMap` y la utilidad `ReentrantLock` de Java.

1. El Administrador de Candados

Este componente se encarga de crear, proveer y destruir los candados bajo demanda de forma atómica usando lambdas en colecciones concurrentes.

import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.locks.ReentrantLock;

public class LockManager {
    private static class RefCountedLock {
        final ReentrantLock lock = new ReentrantLock();
        int refCount = 0;
    }

    private final ConcurrentHashMap<String, RefCountedLock> locks = new ConcurrentHashMap<>();

    public void lock(String key) {
        RefCountedLock refLock = locks.compute(key, (k, v) -> {
            if (v == null) {
                v = new RefCountedLock();
            }
            v.refCount++;
            return v;
        });

        refLock.lock.lock();
    }

    public void unlock(String key) {
        locks.computeIfPresent(key, (k, v) -> {
            // Validamos que el hilo actual posea el candado antes de liberarlo
            if (!v.lock.isHeldByCurrentThread()) {
                throw new IllegalMonitorStateException("El hilo actual no posee el candado para la clave: " + key);
            }
            v.lock.unlock(); // Liberamos el lock físico
            v.refCount--;
            return v.refCount == 0 ? null : v; // Si refCount llega a 0, se remueve automáticamente del mapa
        });
    }
}

flowchart TD
    A[Inicio: lockKey = productId + batchCode] --> B{¿Existe llave en Map?}
    B -- No --> C[Crear Lock y guardar en Map]
    B -- Sí --> D[Obtener Lock existente]
    C --> E[Llamar lock.lock]
    D --> E
    E --> F{¿Lock está libre?}
    F -- Sí --> G[Adquirir lock y ejecutar Sección Crítica]
    F -- No --> H[Suspender hilo y encolar en ReentrantLock]
    
    G --> I[try / finally]
    I --> J[finally: unlock key]
    J --> K[lock.unlock]
    K --> L{¿Hay hilos en espera?}
    L -- Sí --> M[Despertar siguiente hilo de la cola]
    L -- No --> N[Decrementar refCount]
    M --> O[Siguiente hilo entra a Sección Crítica]
    N --> P{¿refCount == 0?}
    P -- Sí --> Q[locks.remove key para evitar fugas de memoria]
    Q --> R[Fin]
    O --> R

2. Aplicación Práctica con Spring Framework en Java

En nuestro servicio de negocio, declaramos el componente como un `@Service` de Spring e inyectamos el `LockManager` mediante `@Autowired` (o por constructor). Es mandatorio utilizar la estructura `try-finally` para asegurar la liberación del candado en cualquier escenario de ejecución.

import org.springframework.stereotype.Service;
import org.springframework.beans.factory.annotation.Autowired;

@Service
public class InventoryService {

    private final LockManager lockManager;

    @Autowired
    public InventoryService(LockManager lockManager) {
        this.lockManager = lockManager;
    }

    public void processMovement(Long productId, String batchCode, Integer quantity) {
        // Definimos la granularidad del bloqueo: Producto + Lote
        String lockKey = productId + "_" + batchCode;

        // Adquirimos el candado específico para esta combinación
        lockManager.lock(lockKey);

        try {
            // ------------------------------------------------------------
            // SECCIÓN CRÍTICA: Lógica de negocio segura (thread-safe).
            // Ningún otro hilo de la JVM modificará este lote simultáneamente.
            // ------------------------------------------------------------
            
            // Ejemplo: Validación de stock, procesamiento y persistencia
            // inventoryRepository.updateStock(productId, batchCode, quantity);

        } finally {
            // El bloque finally garantiza la liberación para evitar deadlocks
            lockManager.unlock(lockKey);
        }
    }
}

Conclusión

Al migrar de un enfoque de sincronización global a un diseño de bloqueo semántico en memoria, transformamos un cuello de botella de cola lineal en una autopista de múltiples carriles en nuestra aplicación de Grails.

Si dos peticiones idénticas llegan simultáneamente para el mismo producto y lote, el motor de hilos de la JVM encolará de manera controlada la segunda petición hasta que la primera finalice su ejecución. Mientras tanto, el resto de los usuarios operando otros productos continuarán sin experimentar ninguna demora.

Optimizar la concurrencia no siempre requiere añadir más servidores o bases de datos distribuidas complejas; a veces, basta con aprovechar las estructuras de control que la JVM pone a nuestra disposición.