RLock#lock(long leaseTime, TimeUnit unit) – el tiempo de arrendamiento es menor que el tiempo de ejecución.
Código:
public void lock() {
RLock lock = redissonClient.getLock("lock");
lock.lock(1, TimeUnit.SECONDS); // o use lock.lock()
hacerAlgo();
lock.unlock(); // si es necesario
}
Si hacerAlgo()
tarda más de 1 segundo(en caso de redes u otros motivos), entonces otro hilo podría obtener el candado, pero esto generaría problemas (como un exceso de ventas). Si se usa lock.lock()
y este cliente se desconecta, nunca liberará el candado y otros clientes no podrán obtenerlo. ¿Cómo solucionar o equilibrar este problema?
davy.ai
Existen algunas soluciones para el problema de un método
doSomething()
de larga duración que causa problemas con el bloqueo.lock()
para que tenga una duración más larga que pueda adaptarse al retraso potencial causado pordoSomething()
. Sin embargo, esto puede llevar a tiempos de espera más largos para los hilos que intentan adquirir el bloqueo, especialmente sidoSomething()
suele tardar más que la duración de espera.Usar el método
tryLock()
: Una alternativa es usar el métodotryLock()
, que intenta adquirir el bloqueo durante una duración especificada pero devuelve inmediatamente si no se puede adquirir el bloqueo. De esta manera, si otro hilo ya tiene el bloqueo, el hilo que llama puede proceder con un comportamiento de reserva en lugar de esperar indefinidamente. Por ejemplo:leaseTime()
yleaseTimeUnit()
. Por ejemplo:En este ejemplo, el bloqueo se adquiere durante 5 segundos pero se establece un arrendamiento de 10 segundos, lo que significa que incluso si el hilo no libera el bloqueo, Redisson lo liberará automáticamente después de 10 segundos.
En general, la elección de una solución depende del caso de uso específico y del equilibrio entre la concurrencia y la tolerancia a fallos.