Bloqueo optimista frente a bloqueo pesimista: dos estrategias para analizar el control de concurrencia
Controlar y administrar el acceso a los recursos compartidos es un desafío importante en la programación concurrente. Para evitar problemas de consistencia de datos y condiciones de carrera, los desarrolladores usan varias estrategias de control de concurrencia. Este blog se centrará en el bloqueo optimista y el bloqueo pesimista, dos mecanismos de control de concurrencia de uso común.
¿Qué es el bloqueo optimista?
El bloqueo optimista es una estrategia de control de concurrencia que supone que, en la mayoría de los casos, el acceso a los recursos compartidos no entrará en conflicto. La idea central del bloqueo optimista no es bloquear antes de leer y modificar los recursos compartidos, sino asumir que otros subprocesos o procesos no interferirán con la operación actual. Si no hay conflictos, la operación continuará; de lo contrario, se revertirá y se volverá a intentar.
Una aplicación típica del bloqueo optimista es utilizar números de versión o marcas de tiempo para realizar un seguimiento del número de veces que se ha modificado un recurso compartido. Cuando se lee un recurso, se registra el número de versión actual o la marca de tiempo. Al modificar un recurso, comparará si el número de versión actual o la marca de tiempo es consistente con el valor registrado en el momento de la lectura. Si es consistente, significa que ningún otro subproceso ha modificado el recurso y la operación puede continuar; si es inconsistente, significa que el recurso se modificó y la operación debe volver a leerse y volverse a intentar.
Aquí hay un código de muestra que usa el bloqueo optimista:
import java.util.concurrent.atomic.AtomicInteger