Por qué hilos

Código en:JavaC#PythonJavaScript

En resumen: Un hilo es una línea de ejecución separada dentro del programa; los hilos aceleran el trabajo que espera (red, disco) incluso con un solo núcleo, mientras que el trabajo que calcula necesita más núcleos.

Problema

El cliente espera tres veces

El cliente pulsa «Pedir». Antes de ver «Gracias», el servidor tiene que consultar tres servicios por la red: el pago (si el banco acepta la tarjeta), el almacén (si el artículo está disponible) y el correo (si salió la confirmación). Cada uno responde en unos 200 ms.

Aquí la red es Network. call espera 200 ms y devuelve la respuesta del servicio. El programa consulta los tres uno tras otro:

Network net = new Network();
String payment = net.call("pago", "aceptado");
String stock = net.call("almacén", "disponible");
String email = net.call("correo", "enviado");
System.out.println(payment);
System.out.println(stock);
System.out.println(email);
System.out.println("Rondas de espera: " + net.rounds());

Salida

pago: aceptado
almacén: disponible
correo: enviado
Rondas de espera: 3

Cada pregunta empieza cuando termina la anterior. El cliente espera la suma: unos 600 ms. Y todo el tiempo el procesador no hace nada: solo espera una respuesta.

Network también cuenta las rondas de espera: una ronda nueva empieza cuando el programa pregunta y no se espera ninguna otra respuesta. Aquí hay tres, una por pregunta. En esta lección la velocidad se mide con este número y no en milisegundos: el tiempo depende de la máquina, mientras que el número de rondas es el mismo en cada ejecución.

Más precisamente, para curiosos

Así funciona Network. synchronized viene de la lección «Hilos»: los dos contadores los tocan varios hilos a la vez. Por qué sin él se pierden números lo cuenta la lección siguiente, «Condición de carrera».

class Network {
    private int inFlight = 0;
    private int rounds = 0;

    // Consulta un servicio por la red: la respuesta llega después de ~200 ms.
    String call(String service, String answer) {
        synchronized (this) {
            if (inFlight == 0) rounds++;   // nadie espera: una ronda nueva
            inFlight++;
        }
        pause(200);
        synchronized (this) {
            inFlight--;
        }
        return service + ": " + answer;
    }

    synchronized int rounds() {
        return rounds;
    }

    private static void pause(int ms) {
        try {
            Thread.sleep(ms);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

La idea

Trabajo que espera y trabajo que calcula

El trabajo de un programa es de dos tipos.

• Trabajo que espera (I/O-bound): una petición al banco, una consulta a la base de datos, leer un archivo, enviar un correo. El programa pregunta y se queda quieto hasta que llega la respuesta. Mientras tanto el procesador está libre.
• Trabajo que calcula (CPU-bound): 1000 facturas en PDF, miniaturas de productos, un informe sobre un millón de pedidos. Aquí el procesador está ocupado todo el tiempo.

Un hilo que espera no usa el procesador. Por eso los hilos ayudan al trabajo que espera incluso con un solo núcleo: el primer hilo pregunta y se duerme, el segundo pregunta y se duerme, lo mismo el tercero, y las tres esperas corren juntas. El trabajo que calcula necesita un núcleo todo el tiempo. Solo se acelera con más núcleos, uno por hilo.

Así que la primera pregunta ante un programa lento es: «¿qué está esperando?». La respuesta decide qué ayuda.

Míralo

Los tres a la vez

Las tres preguntas se convierten en tareas de un grupo de 3 hilos (ExecutorService de la lección «Hilos»). submit devuelve un Future enseguida, y get() espera la respuesta:

Network net = new Network();
ExecutorService pool = Executors.newFixedThreadPool(3);
Future<String> payment =
        pool.submit(() -> net.call("pago", "aceptado"));
Future<String> stock =
        pool.submit(() -> net.call("almacén", "disponible"));
Future<String> email =
        pool.submit(() -> net.call("correo", "enviado"));
System.out.println(payment.get());
System.out.println(stock.get());
System.out.println(email.get());
pool.shutdown();
System.out.println("Rondas de espera: " + net.rounds());

Salida

pago: aceptado
almacén: disponible
correo: enviado
Rondas de espera: 1

Network net = new Network();
ExecutorService pool = Executors.newFixedThreadPool(3);
Future<String> payment =
        pool.submit(() -> net.call("pago", "aceptado"));
Future<String> stock =
        pool.submit(() -> net.call("almacén", "disponible"));
Future<String> email =
        pool.submit(() -> net.call("correo", "enviado"));
System.out.println(payment.get());
System.out.println(stock.get());
System.out.println(email.get());
pool.shutdown();
System.out.println("Rondas de espera: " + net.rounds());

Paso a paso, en palabras

1. Un pedido necesita tres respuestas por la red: el pago, la comprobación del almacén y el correo de confirmación. Cada una espera unos 200 ms.
2. Una tras otra: el hilo pregunta por el pago y no hace nada hasta que llega la respuesta.
3. Solo entonces pregunta por el almacén. Otros 200 ms de espera.
4. Solo entonces pregunta por el correo. Otros 200 ms de espera.
5. 3 rondas de espera: el cliente espera unos 600 ms, y el procesador está parado todo el tiempo.
6. A la vez: las tres preguntas salen juntas, cada una en su propio hilo, y las tres esperas se superponen.
7. El programa espera las respuestas. Cuando llega la primera, las otras dos también están listas.
8. 1 ronda de espera: unos 200 ms, lo que tarda la respuesta más lenta. Las mismas respuestas, en el mismo orden, un tercio de la espera.

Las respuestas son las mismas y en el mismo orden. Hay una ronda de espera: las tres preguntas salen antes de que haya llegado ninguna respuesta. El cliente espera unos 200 ms, lo que tarda el servicio más lento, en vez de 600.

Los hilos apenas usan aquí el procesador: tres ejecuciones cortas de call y tres pausas. Por eso esto funciona también en un servidor con un solo núcleo.

Más precisamente, para curiosos

Los hilos del grupo son hilos reales del sistema operativo. Cada uno tiene su propia pila y cuesta memoria, así que mil preguntas simultáneas con mil hilos salen caras. Java 21 tiene hilos virtuales (Executors.newVirtualThreadPerTaskExecutor()): mientras espera, un hilo virtual no retiene uno real, así que puede haber cientos de miles. El código es el mismo.

Pruébalo

El correo espera el pago

Un compañero cambia el pedido: el correo tiene que decir si está pagado y si hay existencias, así que sale solo después de que hayan respondido el pago y el almacén.

Network net = new Network();
ExecutorService pool = Executors.newFixedThreadPool(3);
Future<String> payment =
        pool.submit(() -> net.call("pago", "aceptado"));
Future<String> stock =
        pool.submit(() -> net.call("almacén", "disponible"));
// el correo dice si está pagado y si hay existencias
System.out.println(payment.get());
System.out.println(stock.get());
Future<String> email =
        pool.submit(() -> net.call("correo", "enviado"));
System.out.println(email.get());
pool.shutdown();
System.out.println("Rondas de espera: " + net.rounds());

Respuesta

pago: aceptado
almacén: disponible
correo: enviado
Rondas de espera: 1

pago: aceptado
almacén: disponible
correo: enviado
Rondas de espera: 2

pago: aceptado
almacén: disponible
correo: enviado
Rondas de espera: 3

Comprobar

Pruébalo

Esperar la respuesta

¿Qué espera la respuesta del pago?

Future<String> payment =
        pool.submit(() -> net.call("pago", "aceptado"));
System.out.println(payment.);

Comprobar

Problema

Mil facturas a fin de mes

A fin de mes la tienda genera una factura en PDF para cada uno de 1000 pedidos. Aquí nada espera la red: el procesador calcula todo el tiempo. render representa el dibujo del PDF con un cálculo que solo carga el procesador y devuelve una suma de control:

// Genera la factura (aquí: un cálculo que solo carga el procesador).
static int render(int invoice) {
    int h = invoice;
    for (int i = 0; i < 2000; i++) {
        h = (h * 31 + i) % 1_000_003;
    }
    return h;
}

// Las facturas desde from hasta to, inclusive.
static long renderRange(int from, int to) {
    long sum = 0;
    for (int n = from; n <= to; n++) {
        sum += render(n);
    }
    return sum;
}

long total = renderRange(1, 1000);
System.out.println("Facturas: 1000");
System.out.println("Suma de control: " + total);

Salida

Facturas: 1000
Suma de control: 499409728

Un núcleo calcula todo mientras los demás están parados. Aquí no hay rondas de espera: nada espera.

Míralo

Cuatro hilos, cuatro núcleos

Las facturas se dividen en 4 partes de 250, y cada parte es una tarea de un grupo de 4 hilos. Cada hilo calcula en su propio núcleo:

ExecutorService pool = Executors.newFixedThreadPool(4);
List<Future<Long>> parts = new ArrayList<>();
for (int p = 0; p < 4; p++) {
    int from = p * 250 + 1;
    parts.add(pool.submit(() -> renderRange(from, from + 249)));
}
long total = 0;
for (Future<Long> part : parts) {
    total += part.get();
}
pool.shutdown();
System.out.println("Facturas: 1000");
System.out.println("Suma de control: " + total);

Salida

Facturas: 1000
Suma de control: 499409728

La suma de control es la misma: dividir no cambia el resultado, solo quién lo calcula.

Cuánto más rápido es depende de la máquina. En mi portátil, con un cálculo 250 veces más pesado por factura (500 000 pasos en vez de 2000), un núcleo tardó unos 1,9 s y cuatro unos 0,5 s.

Son tiempos de ejemplo, no una promesa. Más partes que núcleos no ayudan: solo se turnan en los mismos núcleos.

Más precisamente, para curiosos

• Cuántos hilos. Para el trabajo que calcula, tantos como núcleos: Runtime.getRuntime().availableProcessors() te dice cuántos. Para el trabajo que espera, muchos más está bien: solo duermen.
• No todo se divide. Si una décima parte del trabajo no se puede dividir (por ejemplo sumar las partes o escribir un archivo), ningún número de núcleos lo hace más de 10 veces más rápido. Es la ley de Amdahl.

La idea

Qué ayuda

	Trabajo que espera	Trabajo que calcula
Qué lo frena	la respuesta de la red, del disco, de la base de datos	el propio cálculo
Qué ayuda	esperar varias cosas a la vez	más núcleos
En Java	un grupo de hilos, hilos virtuales	un grupo con tantos hilos como núcleos
Con un núcleo	ayuda	no ayuda

Los hilos tienen un precio. Mientras cada uno trabaje con sus propios datos (su propio servicio, sus propias 250 facturas), todo va bien. En cuanto dos hilos tocan lo mismo (un contador compartido, las existencias del almacén), empiezan errores que no aparecen en cada ejecución. Esa es la lección siguiente: «Condición de carrera».

Ejercicio

La página del producto

Resuelve la tarea en tu editor.

La página del producto. Antes de mostrar la página, el servidor consulta tres servicios: el precio, las reseñas y la entrega. Cada uno responde en unos 200 ms y no depende de los demás. Usa Network de la primera tarjeta y consúltalos todos a la vez, de modo que haya una ronda de espera:

Salida

precio: 89 €
reseñas: 4,6 de 5
entrega: mañana
Rondas de espera: 1

Más tareas

• Cinco servicios. Añade el almacén y un descuento. ¿Cuántas rondas hay si el descuento depende del precio?
• Cuántos núcleos. Ejecuta las facturas con 1, 2, 4 y 8 partes y mide el tiempo en tu máquina. ¿Cuándo deja de ir más rápido? Compáralo con el número de núcleos de tu máquina. - La herramienta equivocada. Pon en render una pause/sleep de 200 ms en cada décima factura, como si esperara al disco. ¿Qué ayuda más ahora: más hilos o más núcleos?

Test

Ponte a prueba

1. Un pedido espera tres servicios de 200 ms cada uno que no dependen entre sí. ¿Cuánto espera el cliente si los consultas todos a la vez?

Unos 67 ms: un tercioUnos 600 ms: la sumaUnos 200 ms: lo que tarda el más lento

2. El servidor tiene un solo núcleo. ¿Ayudan los hilos al trabajo que espera la red?

Sí: un hilo que espera no usa el procesador, así que los demás avanzan mientras él esperaNo: con un núcleo los hilos se turnan y todo tarda lo mismo que uno tras otroSolo si hay al menos tantos hilos como núcleos

3. Tienes que calcular 1000 facturas y el procesador tiene 4 núcleos. ¿Cuántos hilos ayudan más?

Uno: los hilos no ayudan a calcularUnos 4: tantos como núcleos1000: uno por factura

4. ¿Por qué la lección cuenta rondas de espera y no milisegundos?

Porque los milisegundos no se pueden medirEl tiempo depende de la máquina y de su carga, mientras que el número de rondas es el mismo en cada ejecuciónPorque las rondas son números más pequeños

Comprobar

Empezar la lección de nuevo

Lecciones relacionadas

• Se basa en: Excepciones · Listas · Lambdas · Hilos
• Continúa en: Condición de carrera · Bloqueo · Operaciones atómicas y objetos inmutables · Productor y consumidor
• Ejercicios sobre el tema: Concurrencia y condiciones de carrera