Un código es thread-safe si puede ser ejecutado por varios hilos de ejecución simultáneamente de manera segura. Esto significa que la ejecución de un hilo no corrompe los datos ni interfiere indebidamente con los procesos que se ejecutan en paralelo.
Un código se puede hacer thread-safe mediante diferentes aproximaciones. La más conocida es el uso del modificador synchronized, que básicamente impide que más de un hilo ejecute simultáneamente un segmento de código específico. Pero esta no es la única técnica; el uso de la palabra clave final, volatile, variables de clases inmutables o de objetos sin estado también son técnicas útiles para asegurar la correcta ejecución en entornos de múltiples hilos.
Así que ya sabéis, no hagáis como aquel consultor que, en medio de una reunión de dirección, dijo que un código no era thread-safe solo porque, tras echarle un vistazo, le pareció que había pocos synchronized.
Gracias por el artículo. Creo que el título de la entrada debería ser «happens-before». Creo que «happens-before» implica «thread-safe» Supongo que sí. Pero que algo sea «thread-safe» no tiene por qué implicar que tenga una relación «happens-before». Se me ocurre usar objetos Lock.
Siempre es un debate que tengo conmigo mismo a la hora de aclarar estos conceptos porque es fácil mezclarlos
Tengo que rectificar un comentario mío anterior, cuando dije que objetos Lock no implican *happens-before». El capítulo 16 del libro de Concurrencia en práctica, de Brian Goetz dice explícitamente que sí. Por tanto, error mío. Ahora me quedo ala duda en saber la diferencia entre happens-before y thread-safe.
Hola, considera la inmutabilidad de una clase. Es thread safe, porque al no haber modificaciones en el estado del objeto, múltiples hilos de ejecución pueden acceder sin preocuparse por la concurrencia. Asegurar el orden de la ejecución de las instrucciones es muy importante en multitarea, pero no todo el código thread safe está relacionado con el happens before.