Cerraste el módulo 7 con una frase incómoda: "tu portátil tiene ocho núcleos y BiblioTech usa uno". La aplicación recuerda, se configura sin recompilar, valida sus importaciones y no corrompe sus ficheros. Pero hace las cosas una detrás de otra, y por eso el menú se queda mudo durante una importación, los doscientos avisos tardan diez minutos y el procesador está parado mientras alguien decide qué opción teclear.

Esta lección no escribe todavía la solución: escribe el modelo mental sin el cual la solución es imposible de razonar. Vas a entender qué es exactamente un hilo, en qué se diferencia de un proceso, qué comparten dos hilos y qué no —el diagrama que explica literalmente la mitad de los errores de concurrencia que verás en tu carrera—, en qué se distinguen concurrencia y paralelismo, por qué el número correcto de hilos depende de si tu tarea gasta CPU o espera a un disco, y qué peligros aparecen en cuanto dos hilos tocan lo mismo.

Y terminarás con un programa de veinte líneas que falla de verdad: dos hilos que suman uno a un contador dos millones de veces y producen un resultado menor que dos millones, de forma reproducible. Ese programa es el gancho del módulo entero. Todo lo que viene después —synchronized, volatile, las variables atómicas, las colecciones concurrentes— existe para que ese número vuelva a ser el que debería.

Aviso de método. La concurrencia es el único tema de este curso donde leer no basta. Ejecuta los ejemplos. Ejecútalos varias veces. Los que fallan no fallan siempre, y ver el mismo programa dar dos resultados distintos en dos ejecuciones seguidas es la lección que ningún párrafo puede sustituir.

1. El problema real: BiblioTech espera
2. Proceso frente a hilo
3. Qué comparten y qué no comparten dos hilos
4. Concurrencia frente a paralelismo
5. Por qué se usan hilos: los tres motivos
6. Tareas limitadas por CPU y limitadas por E/S
7. El hilo principal y el hilo actual
8. Hilos demonio y cuándo termina la JVM
9. El coste real de un hilo
10. Los tres peligros: carrera, interbloqueo, inanición
11. El primer ejemplo que falla: el contador compartido
12. Errores Comunes y Consejos
13. Ejercicios

Antes de la teoría, los tres casos concretos que la justifican. Son tres situaciones reales del código que ya has escrito.

Caso A — la importación bloquea el menú. ImportadorCatalogo lee un fichero de cincuenta mil líneas, valida cada una y construye un Informe. Tarda ocho segundos. Durante esos ocho segundos, MenuBiblioTech no lee teclado, no pinta nada, no responde. El usuario no sabe si el programa está trabajando o se ha colgado, y no puede cancelar.

Caso B — los avisos se envían de uno en uno. ColaAvisos tiene doscientos préstamos vencidos. Enviar un aviso implica escribir un fichero de notificación y esperar a que el disco confirme. Supongamos 300 ms por aviso. Doscientos avisos son sesenta segundos de reloj, durante los cuales el procesador está prácticamente inactivo: está esperando al disco, no calculando.

Caso C — dos empleados a la vez. Hoy BiblioTech es de un solo usuario. Si mañana Marta Ruiz y Diego Alonso registraran préstamos simultáneamente sobre el mismo Catalogo, nada en el código impediría que uno pisara el trabajo del otro. No hay ni un synchronized en todo el proyecto porque hasta ahora no hacía falta.

Los tres casos tienen la misma raíz —un único flujo de ejecución— y tres soluciones distintas que este módulo desarrolla. El caso A necesita mover el trabajo a otro flujo. El caso B necesita varios flujos solapando esperas. El caso C necesita proteger lo compartido.

Cuando lanzas java BiblioTechApp, el sistema operativo crea un proceso: una unidad de ejecución con su propio espacio de memoria virtual, sus propios descriptores de fichero y su propia identidad de seguridad. Dentro de ese proceso, la JVM crea hilos: flujos de ejecución independientes que comparten toda esa memoria.

La diferencia esencial cabe en una frase: dos procesos no se ven la memoria; dos hilos del mismo proceso comparten toda la memoria del montón. De ahí se derivan todas las demás diferencias.

Las flechas continuas dentro del proceso A son acceso directo a memoria: el hilo importador puede escribir en el mismo objeto Catalogo que está leyendo el hilo main, sin pedir permiso a nadie y sin que el sistema operativo intervenga. La flecha discontinua entre procesos representa lo contrario: para que el editor de texto vea algo del proceso A hace falta un mecanismo explícito y caro.

Esa flecha continua es a la vez toda la potencia y todo el peligro del multihilo. Compartir memoria es lo que hace baratos los hilos, y es lo que hace que un contador pueda perder incrementos.

Nota histórica y práctica. El modelo de "un proceso por tarea" no está obsoleto: es exactamente lo que hacen los navegadores modernos con cada pestaña, precisamente por el aislamiento ante fallos. Cuando el aislamiento importa más que la comunicación barata, procesos. Cuando la comunicación importa más, hilos.

Este es el apartado más importante de la lección. Si interiorizas este diagrama, la mayoría de los errores de concurrencia dejan de ser magia negra y pasan a ser consecuencias previsibles.

Cada hilo de la JVM tiene su propia pila, su propio contador de programa y, en consecuencia, sus propias variables locales y parámetros. Todo lo demás —el montón, donde viven los objetos, y el área de estáticos— es compartido.

Traducido a código:

Las tres reglas que se deducen y que debes memorizar:

1. Las variables locales son seguras por construcción. Un int i declarado dentro de un método no puede tener una condición de carrera: cada hilo tiene el suyo. Esto es confinamiento en la pila y es la forma más barata de seguridad que existe.
2. Los campos de objeto y los static son compartidos si el objeto es alcanzable desde varios hilos. Un Libro creado y usado por un solo hilo es tan seguro como una variable local. El peligro no es el campo: es la compartición.
3. Una referencia local a un objeto compartido no protege nada. Es el error de intuición más frecuente de quien empieza: Material m es local, pero el Material que hay al otro lado no lo es.

Regla práctica que usarás mil veces. Antes de preguntarte "¿esto necesita synchronized?", pregúntate "¿puede este objeto ser alcanzado por dos hilos a la vez?". Si la respuesta es no, no hay nada que sincronizar. La mitad de la sincronización que se escribe en la industria es innecesaria por no hacerse esta pregunta.

Los dos términos se usan como sinónimos en la conversación informal y no lo son. La distinción es la que hace Rob Pike en una frase citadísima: "la concurrencia es tratar con muchas cosas a la vez; el paralelismo es hacer muchas cosas a la vez".

• Concurrencia: estructura. Varias tareas están en curso durante el mismo periodo de tiempo. Pueden ejecutarse intercaladas en un único núcleo, turnándose en rodajas de tiempo de unos pocos milisegundos.
• Paralelismo: ejecución. Varias tareas ejecutan instrucciones en el mismo instante físico, lo que exige varios núcleos.

Tres consecuencias que importan de verdad:

Primera: la concurrencia sirve aunque solo tengas un núcleo. El caso A de BiblioTech —el menú que responde mientras se importa— se resuelve con concurrencia pura. Aunque la máquina tuviera un solo núcleo, intercalar las dos tareas haría que el menú respondiera. No va más rápido: va más receptivo, que es otra cosa.

Segunda: el paralelismo es la única forma de que un cálculo termine antes. Si tienes que calcular las multas de cincuenta mil préstamos y eso es puro cálculo, intercalar en un núcleo no ahorra ni un milisegundo. Solo repartir entre núcleos lo hace.

Tercera y la que más duele: tu código concurrente se ejecutará en paralelo, quieras o no. Es tentador razonar "mi máquina de desarrollo hace las cosas por turnos, así que el error de carrera no aparecerá". El servidor de producción tiene treinta y dos núcleos y la reordenación de memoria que verás en 08-04 se manifiesta ahí y no en tu portátil. Un programa concurrente correcto tiene que serlo para cualquier entrelazado posible.

Solo hay tres razones legítimas para introducir hilos en un programa. Si tu motivo no es una de ellas, probablemente estés añadiendo complejidad sin ganancia.

Motivo 1: aprovechar varios núcleos. Un programa secuencial en una máquina de ocho núcleos usa el 12,5 % de la capacidad de cálculo. Si el trabajo es divisible, repartirlo puede acercarse a un factor de ocho. Puede: la ley de Amdahl dice que la aceleración está limitada por la fracción que no se puede paralelizar. Si el 20 % de tu trabajo es inherentemente secuencial, la aceleración máxima con infinitos núcleos es 5×, no infinita.

Motivo 2: no bloquear la interfaz. Todo programa con interacción —consola, escritorio, web— tiene un flujo que debe seguir respondiendo. Es el caso A: el menú de BiblioTech no puede quedarse mudo ocho segundos. La solución no es hacer la importación más rápida: es sacarla del hilo que atiende al usuario.

Motivo 3: solapar espera de E/S con trabajo útil. Este es el motivo más rentable y el peor entendido. Cuando un hilo llama a Files.readAllLines, el sistema operativo lo suspende hasta que el disco responda. Durante esos milisegundos el hilo no consume CPU: está aparcado. Si tienes doscientos avisos que escribir y cada uno espera 300 ms al disco, un solo hilo suma sesenta segundos de espera; veinte hilos solapan esas esperas y bajan a tres segundos —sin necesitar veinte núcleos, porque no están calculando, están esperando.

Los tres motivos mapean exactamente sobre los tres casos del apartado 1:

El caso C es importante precisamente porque no es un motivo, es una factura. En cuanto introduces hilos por los motivos 1, 2 o 3, aparece la obligación de proteger lo compartido. La concurrencia no es gratis: cambia rendimiento y receptividad por complejidad y clases enteras de errores nuevos.

Toda tarea cae, aproximadamente, en una de dos categorías. La categoría determina cuántos hilos conviene usar, y equivocarse aquí es la causa habitual de que "añadí hilos y va más lento".

• Limitada por CPU (CPU-bound): el hilo pasa casi todo su tiempo ejecutando instrucciones. Calcular multas, ordenar un millón de elementos, comprimir, cifrar, analizar texto.
• Limitada por E/S (I/O-bound): el hilo pasa casi todo su tiempo esperando a un dispositivo. Leer un fichero, escribir en disco, esperar a una base de datos, esperar a la red.

La regla de dimensionado, que se desarrollará con pool de hilos en 08-05:

Java te dice cuántos núcleos hay:

Dos matices sobre availableProcessors() que evitan sorpresas en producción:

1. Devuelve hilos de hardware, no núcleos físicos. Un procesador de 4 núcleos con hyperthreading devuelve 8. Para tareas de cálculo puro, los hilos lógicos rinden bastante menos que un núcleo real.
2. En un contenedor con límite de CPU, las JVM modernas (Java 10+) respetan el límite del cgroup. En Java 8 antiguo devolvía los núcleos de la máquina anfitriona, lo que provocaba pools gigantes en contenedores diminutos. Es un clásico de las migraciones.

No has escrito nunca un programa de un solo hilo. Cuando la JVM arranca, crea el hilo main y le hace ejecutar tu método main; además hay varios hilos internos —el recolector de basura, el compilador JIT, el finalizador— trabajando en segundo plano desde el primer instante.

Thread.currentThread() devuelve el hilo que está ejecutando esa línea en ese momento. Es la herramienta de diagnóstico número uno de este módulo:

Salida:

Fíjate en el detalle del método saludar(): un método no "pertenece" a un hilo. El mismo método puede estar ejecutándose simultáneamente en cinco hilos distintos, cada uno con su propio juego de variables locales en su propia pila. Esto vuelve a ser el apartado 3, visto desde el código.

Consejo que aplicarás en todo el módulo. Cuando algo raro pase, imprime o registra Thread.currentThread().getName(). La pregunta "¿en qué hilo se está ejecutando esto?" resuelve una proporción sorprendente de los misterios de concurrencia. En BiblioTech, RegistroOperaciones debería incluir el nombre del hilo en cada entrada; lo harás en el ejercicio 3.

Java distingue dos clases de hilos:

• No demonio (user thread): el hilo normal. main lo es.
• Demonio (daemon): hilo de servicio, pensado para tareas de apoyo que no deben impedir el cierre del programa.

La regla es tajante y hay que saberla de memoria:

La JVM termina cuando no queda ningún hilo NO demonio vivo. Los hilos demonio se abortan en ese instante, sin previo aviso, sin ejecutar finally, sin cerrar recursos.

Que main termine no apaga la JVM: si un hilo no demonio sigue vivo, el proceso sigue en pie. Es la causa clásica de "el programa no termina y no sé por qué".

Salida típica:

Léelo con cuidado, porque hay dos hechos en esa salida:

1. main termina en el paso 3 y el proceso no muere: hilo-usuario es no demonio y la JVM lo espera hasta que imprime TERMINADO.
2. hilo-demonio nunca llega a los pasos 4 y 5. En el instante en que hilo-usuario acaba, no queda ningún hilo no demonio, la JVM se apaga y el demonio se corta a mitad de camino.

Reglas prácticas:

• setDaemon(true) después de start() lanza IllegalThreadStateException. Siempre antes.
• Un hilo hereda por defecto la condición de demonio del hilo que lo crea.
• Nunca pongas trabajo que no se pueda perder en un hilo demonio. Si un demonio está escribiendo el fichero del catálogo cuando la JVM se apaga, el fichero queda a medias. Para trabajo que debe completarse, hilo no demonio y espera explícita con join() (08-02).
• El shutdown hook que añadiste a BiblioTech en el módulo 7 sí se ejecuta al apagar, y es el sitio correcto para el guardado de estado. No lo sustituyas por un demonio.

Un hilo parece gratis porque new Thread(...) es una línea. No lo es.

Memoria. Cada hilo reserva una pila. En un Linux de 64 bits el valor por defecto es de 1 MB (ajustable con -Xss). Es espacio de direcciones reservado y la memoria física se va tocando según crece la pila, pero el orden de magnitud manda: diez mil hilos son diez gigabytes de pilas reservadas. En una máquina normal, la JVM cae con OutOfMemoryError: unable to create native thread mucho antes.

Creación. Crear un hilo de plataforma implica una llamada al sistema y que el kernel monte sus estructuras. El orden es de decenas a cientos de microsegundos: mil veces más caro que crear un objeto normal. Si creas un hilo por cada petición y las peticiones son cortas, el coste de creación puede superar al trabajo útil.

Cambio de contexto. Cuando el planificador quita un hilo y pone otro, hay que guardar y restaurar registros, y —lo caro— la caché de datos del núcleo queda llena de datos del hilo anterior. El coste directo ronda el microsegundo; el indirecto, por fallos de caché, puede ser mucho mayor. Con más hilos activos que núcleos, la máquina puede pasar más tiempo cambiando de hilo que trabajando: es el thrashing de planificación.

Salida orientativa (varía mucho por máquina):

Ochenta microsegundos por hilo sin hacer absolutamente nada. Si tu tarea real dura menos que eso, crear un hilo para ella es una pérdida neta.

De aquí sale la conclusión que gobierna la práctica moderna: "un hilo por tarea" no escala. La solución clásica es el pool de hilos, un número fijo de hilos reutilizados que van consumiendo tareas de una cola; es 08-05. La solución nueva son los hilos virtuales de Java 21, que vuelven el coste tan bajo que "un hilo por tarea" vuelve a ser viable; se explican en 10-06.

Antes de escribir código concurrente conviene conocer los tres modos de fallo. Aquí solo se presentan con una intuición; resolverlos es el trabajo de 08-04 y siguientes.

Condición de carrera. El resultado depende del orden en que se entrelacen los hilos, y ese orden no lo controlas.

Intuición: dos empleados miran a la vez la misma hoja de inventario, ambos leen "quedan 3 ejemplares", ambos anotan "2" después de prestar uno. Se han prestado dos ejemplares y el inventario dice que se prestó uno.

Interbloqueo (deadlock). Dos hilos se esperan mutuamente para siempre, cada uno reteniendo lo que el otro necesita.

Intuición: Marta tiene la llave del archivo y necesita la del almacén; Diego tiene la del almacén y necesita la del archivo. Ninguno suelta la suya. Los dos esperan indefinidamente y no hay error, ni excepción, ni traza: simplemente nada avanza.

Inanición (starvation). Un hilo nunca consigue el recurso que necesita porque otros se lo llevan siempre.

Intuición: la impresora de la biblioteca atiende primero los trabajos cortos. El informe anual de 400 páginas de Nuria Vidal nunca llega a imprimirse, porque siempre hay alguien con un trabajo de dos páginas por delante.

Añade una cuarta característica común a los tres que hace la concurrencia especialmente traicionera: son heisenbugs. Añadir un System.out.println para depurar cambia los tiempos y hace desaparecer el fallo. Ejecutar con el depurador, igual. Y un programa con una condición de carrera puede funcionar correctamente durante meses hasta que un día, con más carga o en una máquina con más núcleos, produce un dato incorrecto. Por eso este módulo insiste tanto en la corrección por diseño y no en probar hasta que parezca que funciona.

Aquí está el programa prometido. Dos hilos, un contador compartido, cada hilo suma uno un millón de veces. El resultado esperado es 2.000.000. Casi nunca lo es.

Salida real de una ejecución (los números cambian en cada ejecución, ese es justo el punto):

Cuatro observaciones, todas importantes:

Primera: no se pierde un incremento, se pierden cientos de miles. No es un caso rarísimo que se da una vez entre un millón: es un fallo masivo. La razón se explica en 08-04, pero el resumen es que valor++ se compila a tres instrucciones —leer el valor, sumarle uno, escribir el resultado— y cualquier entrelazado entre esas tres pierde trabajo.

Segunda: el intento 3 dio el resultado correcto. Esto es lo verdaderamente peligroso. Si hubieras ejecutado el programa una sola vez y hubiera salido el intento 3, habrías concluido que el código está bien. Que un programa concurrente dé el resultado correcto no demuestra nada.

Tercera: nunca sale un valor mayor de 2.000.000. Los incrementos se pierden, no se duplican. Con un int de 32 bits las escrituras son atómicas —cada escritura escribe un valor completo—, así que el error es siempre por defecto. Con un long en una JVM de 32 bits podían verse valores imposibles, mitad de una escritura y mitad de otra; también en 08-04.

Cuarta: si sustituyes VUELTAS por 1000, probablemente salga siempre correcto. Con poco trabajo, el primer hilo termina antes de que el segundo arranque y no llega a haber solapamiento. Es la razón por la que estos errores no aparecen en pruebas pequeñas y sí en producción.

Un experimento que conviene hacer. Cambia private int valor por private volatile int valor y vuelve a ejecutar. Sigue fallando. Es la demostración de que volatile no resuelve esto, y una de las confusiones más extendidas del tema; el porqué está en 08-04.

Deja este programa a mano. Volverás a él con synchronized en 08-04 y con AtomicInteger en 08-06, y verás las dos formas correctas de arreglarlo, con su coste respectivo.

Error 1: creer que "no lo he visto fallar" significa "es correcto". Es el error conceptual más grave del módulo. Un entrelazado desfavorable puede ser raro en tu portátil y frecuente en un servidor de 32 núcleos con carga. Razona la corrección; no la pruebes a base de ejecuciones.

Error 2: confundir "es local" con "es seguro". Material m = catalogo.buscar(isbn) declara una referencia local a un objeto compartido. Lo seguro es la referencia; el objeto no.

Error 3: pensar que más hilos siempre van más rápido. Para tareas de cálculo, pasar de 8 a 80 hilos en 8 núcleos empeora el rendimiento por cambios de contexto. Mide antes de decidir.

Error 4: llamar a setDaemon(true) después de start(). Lanza IllegalThreadStateException. Y peor: poner trabajo importante en un demonio y descubrir que se corta a media escritura.

Error 5: suponer que main al terminar apaga la JVM. Con un hilo no demonio vivo, el proceso sigue. Si tu programa "no termina", busca hilos no demonio que siguen corriendo (verás cómo diagnosticarlo con volcados de hilos en 08-03).

Error 6: añadir hilos sin un motivo de los tres del apartado 5. Complejidad, errores nuevos y diagnóstico difícil a cambio de nada.

Error 7: depurar concurrencia con System.out.println. println está internamente sincronizado, así que cambia el comportamiento: puede hacer desaparecer la carrera que intentas ver. Usa el logger de 06-07, incluye el nombre del hilo, y acumula datos en memoria para volcarlos al final cuando midas.

Consejo 1: piensa en "tareas", no en "hilos". El resto del módulo va en esa dirección: describes qué trabajo hay que hacer y dejas que un ejecutor decida dónde se hace.

Consejo 2: la mejor sincronización es no compartir. Si cada hilo trabaja sobre sus propios datos y solo se combinan los resultados al final, no hay carreras posibles. Es el principio de confinamiento, y se desarrolla en 08-04.

Consejo 3: nombra todos tus hilos desde el primer día. Un volcado con Thread-0, Thread-1 y Thread-2 no dice nada; con bibliotech-importador, bibliotech-avisos-3 te dice dónde mirar. Se hace en 08-02.

Consejo 4: mide con System.nanoTime(), no con currentTimeMillis(). nanoTime es un reloj monótono pensado para medir intervalos; currentTimeMillis puede saltar hacia atrás si el sistema ajusta la hora.

Escribe una clase DiagnosticoConcurrencia con un main que imprima un informe del entorno: número de procesadores disponibles, memoria máxima de la JVM, nombre, identificador, prioridad y condición de demonio del hilo actual, y el número total de hilos vivos en la JVM en ese momento. Además, para una tarea limitada por E/S con una espera media de 400 ms y un cálculo medio de 50 ms por tarea, calcula e imprime el tamaño de pool recomendado según la fórmula N × (1 + espera/cálculo).

Pista: Thread.activeCount() da una aproximación de los hilos vivos del grupo actual; Runtime.getRuntime().maxMemory() da la memoria máxima en bytes.

Amplía el ejemplo del apartado 11 para responder empíricamente a esta pregunta: ¿a partir de cuántas vueltas empieza a fallar? Escribe UmbralDeCarrera que, para cada valor de vueltas en {100, 1_000, 10_000, 100_000, 1_000_000}, repita el experimento 10 veces con dos hilos y cuente en cuántas de las 10 repeticiones el resultado fue incorrecto. Imprime una tabla con la carga, el porcentaje de ejecuciones fallidas y la pérdida media.

Añade a BiblioTech un método de utilidad RegistroOperaciones.trazaHilo(String operacion) que registre en el logger de 06-07, en nivel INFO, una línea con el nombre del hilo actual, su identificador y la operación. Después escribe un main de demostración que lance dos hilos llamados bibliotech-importador y bibliotech-avisos, cada uno de los cuales llame a trazaHilo tres veces con pausas de 100 ms, y comprueba en la salida que las líneas de los dos hilos aparecen intercaladas y no en bloques.

Solución al Ejercicio 1

Puntos didácticos:

• availableProcessors() puede devolver valores distintos en ejecuciones distintas si la JVM corre en un contenedor con límites dinámicos. No lo caches en un static final si el proceso es de larga duración.
• activeCount() es explícitamente aproximado: los hilos pueden nacer y morir mientras se cuenta. Para diagnóstico serio se usa ThreadMXBean (08-03).
• El pool de E/S sale mucho mayor que el número de núcleos, y esa es exactamente la intuición del apartado 6: los hilos que esperan no compiten por CPU.

Solución al Ejercicio 2

Salida orientativa:

Lo importante de este ejercicio no es el número: es la forma de la curva. Con 100 vueltas no falla nunca porque el primer hilo termina antes de que el segundo empiece a solaparse; con un millón falla siempre. Un programa de producción es la columna de la derecha, y tu prueba unitaria suele ser la de la izquierda.

Solución al Ejercicio 3

Salida (con el formateador de ConfiguracionLog):

Tres cosas que enseña esta salida:

1. Las líneas están intercaladas y el orden entre hilos cambia en cada ejecución. En el paso 2 el hilo de avisos se adelantó al importador; en otra ejecución será al revés. No hay ningún orden garantizado entre hilos distintos.
2. Dentro de un mismo hilo, el orden sí está garantizado: paso 1 siempre precede a paso 2 en el mismo hilo. Esta es la primera intuición del modelo de memoria: dentro de un hilo, todo ocurre en el orden del programa.
3. java.util.logging es seguro para varios hilos: los Handler sincronizan la publicación, por eso las líneas no salen entremezcladas carácter a carácter. Es otra razón para usar el logger de 06-07 y no System.out.println a partir de ahora.

Ya tienes el modelo mental. No has escrito todavía concurrencia útil, pero has construido las tres ideas sin las cuales el resto del módulo sería memorización.

La primera: un hilo es un flujo de ejecución dentro de un proceso, mucho más barato de crear y de conmutar que un proceso, y con una diferencia decisiva: comparte toda la memoria del montón y los estáticos con los demás hilos, y solo tiene privadas su pila, sus variables locales y su contador de programa. Ese reparto —compartido arriba, privado abajo— explica por qué una variable local nunca sufre una condición de carrera y por qué un objeto alcanzable desde dos hilos siempre puede sufrirla. La pregunta correcta nunca es "¿es este campo peligroso?", sino "¿puede este objeto ser alcanzado por dos hilos a la vez?".

La segunda: concurrencia y paralelismo no son lo mismo. La concurrencia es una propiedad del diseño —varias tareas en curso a la vez, aunque se intercalen en un solo núcleo— y sirve para que el menú de BiblioTech siga vivo durante una importación. El paralelismo es una propiedad de la ejecución —varias tareas avanzando en el mismo instante— y es lo único que hace que un cálculo termine antes. Y la consecuencia práctica: tu código se ejecutará en máquinas con muchos más núcleos que la tuya, así que tiene que ser correcto para cualquier entrelazado, no solo para el que ves.

La tercera: los hilos se introducen por tres motivos y solo tres —aprovechar núcleos, no bloquear la interfaz, solapar espera de E/S—, y cuestan dinero: alrededor de 1 MB de pila y decenas de microsegundos por hilo, más el cambio de contexto. De ahí que el número adecuado de hilos dependa de si la tarea está limitada por CPU (≈ núcleos) o limitada por E/S (muchos más, según el ratio espera/cálculo), y de que "un hilo por tarea" no escale, que es la razón de ser de los pools de 08-05.

Sabes además distinguir el hilo main del hilo actual, consultar Thread.currentThread().getName() como primera herramienta de diagnóstico, y la regla del apagado: la JVM termina cuando no queda ningún hilo no demonio, y los demonios se abortan sin ejecutar su finally —por eso nunca se les confía trabajo que no se pueda perder—.

Y conoces los tres modos de fallo que definen el resto del módulo: la condición de carrera que da resultados incorrectos e intermitentes, el interbloqueo que para todo en silencio y sin excepción, y la inanición que deja a un hilo esperando para siempre. Con la advertencia que los hace especialmente traicioneros: son heisenbugs, y añadir una traza para verlos puede hacerlos desaparecer.

Sobre todo, tienes el contador roto. Dos hilos, un valor++, dos millones de incrementos y un resultado que unas veces es 1.362.544, otras 1.734.022 y de vez en cuando —lo más peligroso de todo— exactamente 2.000.000. Ese programa de veinte líneas contiene el módulo entero en miniatura: un fallo real, reproducible, invisible en pruebas pequeñas y masivo bajo carga.

En la próxima lección, Creación de Hilos, dejas de contemplar el problema y empiezas a construir. Verás las cuatro formas de crear un hilo y por qué Runnable gana a extender Thread; el error clásico de llamar a run() en lugar de start(), con la demostración de que ejecuta en el hilo equivocado; cómo esperar con join(), cómo nombrar hilos para que los logs sirvan de algo, y por qué las prioridades casi nunca hacen lo que crees; el protocolo completo de interrupción —interrupt(), InterruptedException, y por qué tragarse esa excepción es uno de los peores errores que se pueden cometer en Java—; y qué pasa cuando un hilo lanza una excepción que nadie captura. Al terminar, la importación del catálogo de BiblioTech se ejecutará en su propio hilo, con nombre propio, y se podrá cancelar.