El Modelo de Memoria de Java (JMM) garantiza que una vez que un constructor se completa, las escrituras a los campos final se vuelven visibles para cualquier hilo que lea la referencia del objeto, siempre que esa referencia no se haya escapado durante la construcción. Si la referencia this se filtra prematuramente—pasándola a otro hilo o almacenándola en una colección estática antes de que el constructor retorne—la relación happens-before entre la escritura del constructor al campo final y la lectura del otro hilo se interrumpe. En consecuencia, el hilo que observa puede ver el valor predeterminado (cero, falso o nulo) en lugar del valor construido, rompiendo la aparente inmutabilidad. La publicación segura requiere que ninguna referencia al objeto en construcción se escape hasta que la construcción termine, asegurando que la acción de congelación en los campos final ocurra antes de que cualquier hilo pueda cargar la referencia.
Nos encontramos con esto en un sistema de trading de alta frecuencia donde las instancias de Service se registraban en un ConcurrentHashMap global durante sus constructores para facilitar la búsqueda. La clase definía un final long instrumentId, inicializado desde un parámetro del constructor, sin embargo, los hilos de monitoreo leían esporádicamente cero cuando consultaban el registro inmediatamente después de la creación.
Una solución propuesta fue declarar instrumentId como volatile en lugar de final, con la esperanza de forzar visibilidad inmediata a través de los núcleos. Este enfoque garantizaba atomicidad y visibilidad, pero sacrificaba el contrato de inmutabilidad e incurría en un costo de barrera de memoria completo en cada lectura, degradando innecesariamente el rendimiento para un valor que nunca cambiaba después de la construcción y complicando el razonamiento sobre el estado del objeto.
Otra sugerencia involucraba sincronizar todos los accesos al registro con bloques synchronized que encapsulaban la lógica del constructor, teorizando que el bloqueo vaciaría las cachés de memoria. Si bien esto prevenía condiciones de carrera, introducía una fuerte contención en el bloqueo del registro global, convirtiendo una estructura concurrente en un cuellos de botella serial y violando estrictos requisitos de latencia para la ingestión de datos del mercado.
Elegimos un patrón de fábrica que desacoplaba la instanciación del registro. El constructor permaneció privado, el método de fábrica invocó new Service(id) por completo, y solo después publicó la referencia completamente formada en el ConcurrentHashMap. Esto aprovechó la semántica de congelación de campo final del JMM sin sobrecarga de sincronización, asegurando que instrumentId fuera visible inmediatamente al ser recuperado.
El cambio eliminó las anomalías de visibilidad cero y restauró la latencia esperada a escala de microsegundos para la búsqueda de servicios, mientras preservaba la intención de diseño inmutable.
¿Por qué final no garantiza la visibilidad si simplemente publico la referencia a través de una colección segura para hilos como ConcurrentHashMap?
La relación happens-before proporcionada por las operaciones put y get de ConcurrentHashMap establece un orden entre los cambios en el estado interno del mapa, no entre las escrituras del constructor y la publicación del mapa. Si this se escapa durante la construcción, la escritura en el campo final ocurre en un hilo mientras que la publicación del mapa sucede de forma concurrente, careciendo de la relación happens-before necesaria para evitar la reordenación de instrucciones. Por lo tanto, el hilo de lectura puede observar la referencia a través del mapa antes de que las escrituras del constructor se vacíen en la memoria principal, viendo el valor predeterminado.
¿Puedo solucionar esto haciendo que el campo del registro sea volatile en lugar de los campos del objeto?
Marcar la referencia del registro como volatile solo asegura que los cambios en la variable del registro sean visibles, no el estado interno de los objetos que contiene. Dado que el problema es el momento de las escrituras de los campos del objeto en relación con la referencia volviéndose visible, volatile en el contenedor no establece el orden necesario entre el constructor y el consumidor del objeto. Aún se observarían instancias parcialmente construidas.
¿Usar synchronized dentro del constructor previene la publicación insegura?
Colocar synchronized en el constructor o usarlo para proteger el registro evita que otros hilos entren en la sección crítica de forma concurrente, pero no evita que la referencia this se escape si el método de registro filtra la referencia a un hilo que opera fuera de ese bloqueo. El JMM requiere específicamente que ninguna referencia al objeto se escape antes de que el constructor termine para que se mantenga la semántica del campo final; la sincronización sin el orden de publicación adecuado no puede restaurar esa garantía.