Lecciones

Esta lección trata de qué es un recurso compartido en aplicaciones multihilo, por qué surgen condiciones de carrera (race condition) y «actualizaciones perdidas», y cómo proteger los datos con synchronized. Veremos técnicas básicas de sincronización (métodos y bloques), hablaremos de herramientas modernas de java.util.concurrent ( Lock, ReentrantLock, Semaphore y otros), veremos ejemplos prácticos con el incremento de un contador y errores típicos (no atomicidad de i ++, objeto de bloqueo incorrecto, mitos sobre volatile).

Lección práctica sobre concurrencia: analizamos cómo funciona la palabra clave synchronized (bloques y métodos, el monitor del objeto y el bloqueo a nivel de clase ClassName.class), en qué se diferencia la visibilidad de los cambios mediante volatile de la atomicidad de las operaciones, por qué las banderas boolean conviene declararlas volatile, y por qué el incremento count ++ requiere sincronización. Veremos cuándo elegir synchronized y cuándo — volatile, y analizaremos errores típicos.

Comparación práctica de la sincronización clásica mediante synchronized con primitivas más flexibles del paquete java.util.concurrent.locks: ReentrantLock y ReadWriteLock. Veremos cómo gestionar los bloqueos de forma explícita ( lock()/ unlock(), tryLock() con tiempo de espera), cómo escalar la lectura con ReentrantReadWriteLock, qué es la «equidad» (modo fair), dónde es apropiada cada herramienta y qué errores aparecen con más frecuencia.

En esta lección veremos los primitivos clave de sincronización en Java: cómo proteger secciones críticas con synchronized y la clase ReentrantLock (métodos lock()/ unlock(), construcción try- finally), así como cómo limitar el paralelismo mediante Semaphore (métodos acquire()/ release()). Compararemos mutex y semáforo en una tabla, veremos casos prácticos (banco, servidor con límite de conexiones) y errores típicos que conducen a deadlock y a pérdidas de rendimiento.

Análisis práctico de errores frecuentes de concurrencia en Java: olvidar llamar a unlock()/ release() en ReentrantLock y Semaphore (se soluciona con try- finally), elegir un monitor incorrecto para synchronized, interbloqueos (deadlock) y el orden de adquisición de bloqueos, sincronización excesiva, así como los límites de aplicabilidad de volatile y la sustitución por AtomicInteger. Ejemplos, consejos y analogías claras — para que el código no «se quede bloqueado».