Chuleta de procesos e hilos

01Conceptos básicos

PCB (Process Control Block)

Cada proceso tiene un PCB con lo que el SO necesita para ejecutarlo: el código, los datos y el estado del procesador (registros y el PC, Program Counter).

Al ejecutar una app, el SO carga el ejecutable en memoria, le asigna recursos (CPU, memoria, ficheros…) y gestiona su ciclo de vida.

Proceso vs hilo

Todo proceso tiene como mínimo 1 hilo. Con 1 hilo es monohilo; con varios, multihilo.

02Estados de un proceso y planificación

• Nuevo: creado, aún no se ejecuta.
• Preparado (ready): listo, esperando la CPU.
• Ejecución (running): usando la CPU.
• Bloqueado (waiting): esperando un recurso o evento, como leer un fichero. Cuando llega, vuelve a Preparado, no a Ejecución.
• Finalizado (terminated): ha acabado.

Planificadores

Hay más procesos que CPUs, así que el planificador decide quién se ejecuta y cuándo.

Algoritmos de planificación

03Concurrencia, paralelismo y distribución

• Concurrencia: varias tareas «a la vez». No siempre es paralelismo real.
• 1 núcleo: se alternan muy rápido → multiprogramación.
• Varios núcleos: paralelismo real → programación paralela.

Objetivos de la concurrencia: mejorar el tiempo de respuesta, aprovechar mejor los recursos (mientras uno espera al disco, otro usa la CPU) y modularidad (dividir la app en tareas independientes).

Problemas típicos

04Gestión de procesos e IPC

PID: identificador único del proceso. PPID: PID del proceso padre.

IPC (Inter-Process Communication)

Cómo se pasan datos los procesos. Técnicas sencillas: ficheros y pipes. Más potentes: sockets, memoria compartida y colas de mensajes. Se elige según si es local o distribuida, si importa la velocidad o la persistencia, y si el acoplamiento es fuerte o débil.

Redirecciones de la shell

Sincronización entre procesos

• Bloqueo de ficheros: solo un proceso puede escribir (nuestro FileLock).
• Semáforos: contador que limita cuántos acceden. Binario = 1, como un candado; contador = N a la vez.
• Colas de mensajes: además de comunicar, coordinan (uno espera el «permiso» del otro).

05Procesos en Java

Runtime

Process p = Runtime.getRuntime().exec("notepad");   // lanza un proceso externo
p.waitFor();                                       // espera a que acabe

Métodos de Process

ProcessBuilder (el recomendado)

Da más control de los argumentos, permite redirigir la entrada y salida, y es más claro.

ProcessBuilder pb = new ProcessBuilder("ls", "-l");   // orden y argumentos separados
pb.redirectOutput(new File("salida.txt"));          // también redirectInput / redirectError
pb.redirectError(ProcessBuilder.Redirect.INHERIT);   // errores del hijo en nuestra consola
pb.directory(new File("bin"));                        // carpeta de trabajo del hijo
Process p = pb.start();                               // ahora sí se ejecuta

Pipes en Java: ProcessBuilder.startPipeline(lista) arranca todos los procesos de la lista y conecta la salida de cada uno con la entrada del siguiente. Devuelve una List<Process>; el último tiene el resultado final.

06Hilos en Java

Todo programa Java empieza con el hilo principal (main thread). Hay dos formas de crear hilos:

// 1) Heredar de Thread
class MiHilo extends Thread {
    public void run() { System.out.println("Hola desde un hilo"); }
}
new MiHilo().start();

// 2) Implementar Runnable  (⭐ recomendada)
class MiTarea implements Runnable {
    public void run() { System.out.println("Hola"); }
}
new Thread(new MiTarea()).start();

Por qué Runnable es mejor: Java no tiene herencia múltiple, así que tu clase puede heredar de otra a la vez, y el código se reutiliza mejor.

Thread.State: NEW (creado sin start), RUNNABLE, BLOCKED (esperando entrar en un synchronized), WAITING (wait/join sin tiempo), TIMED_WAITING (sleep, wait con tiempo), TERMINATED.

07Sincronización de hilos

• Sección crítica: código que toca un recurso compartido. Solo un hilo a la vez.
• Exclusión mutua (mutex): el mecanismo que lo garantiza.
• count++ no es atómico (lee, suma, escribe) → con varios hilos da resultados erróneos.
• Lectores/escritores: varios lectores a la vez, pero si escribe uno, nadie más accede.

// Método sincronizado: bloquea el objeto entero
public synchronized void incrementar() { count++; }

// Bloque sincronizado: solo bloquea la parte crítica (más eficiente)
public void incrementar() {
    synchronized (this) { count++; }
}

Deadlock y cómo evitarlo

Hilo 1 bloquea la cuenta A y quiere la B; hilo 2 bloquea la B y quiere la A → ninguno avanza. Solución: un orden global de bloqueo: todos bloquean siempre en el mismo orden, por ejemplo por id de cuenta.

08Comunicación entre hilos: wait() / notify()

No basta con no pisarse: a veces un hilo tiene que avisar a otro («ya hay datos»).

• wait(): el hilo se duerme y suelta el lock hasta que le avisen.
• notify(): despierta a un hilo que espera. notifyAll(): a todos.
• Solo se pueden llamar dentro de un bloque synchronized (necesitan el monitor). Si no: IllegalMonitorStateException.

synchronized (obj) {
    while (!condicion) {     // ⚠️ while, NO if
        obj.wait();
    }
    // hacer el trabajo
    obj.notifyAll();
}

Se usa while y no if porque al despertar hay que volver a comprobar la condición: puede haber cambiado antes de recuperar el lock.

Productor / Consumidor

• Los productores meten datos en un almacén compartido de capacidad limitada; los consumidores los sacan.
• Almacén lleno → el productor hace wait().
• Almacén vacío → el consumidor hace wait().
• Cada vez que uno mete o saca algo, hace notify() para despertar al otro.

P1Varios procesos, un extracto: FileLock

Cada entidad (titular, empresa…) ejecuta su propio BankProcess: si lo lanzas 3 veces, son 3 procesos con su memoria, su consola y su PID. Lo único que comparten es statement.txt, el recurso compartido. Escribir en él es la sección crítica.

public void writeOperation(Operation operation, String concept, double amount) {
    String linea = fecha + " | " + operation + " | " + concept + " | " + signo + importe + " €\n";

    try (FileOutputStream fos = new FileOutputStream(fileName, true);   // true = append
         FileLock lock = fos.getChannel().lock()) {                // 🔒 si otro lo tiene, ESPERA aquí
        fos.write(linea.getBytes(StandardCharsets.UTF_8));          // sección crítica
    } catch (IOException e) {
        System.err.println("Error: " + e.getMessage());
    }   // 🔓 el try-with-resources libera el lock y cierra el fichero (orden inverso)
}

La demostración (rúbrica)

• Quitar la sincronización: escribiendo sin lock y letra a letra, el fichero sale mezclado (22002266--1100…) → condición de carrera.
• Volver a poner el lock: el segundo proceso espera y las líneas salen enteras.
• En el debugger: breakpoint en fos.write. Con lock, B no llega al breakpoint: sale como Running, atascado en lock(). Sin lock, los dos se paran a la vez.

# Lanzar varios procesos y gestionarlos (desde la carpeta del proyecto)
java -cp bin bank.BankProcess          # en 2 o 3 terminales
jps -l                                  # PID de cada proceso Java
ps -ef | grep BankProcess               # alternativa con ps (PID y PPID)
kill 4117                               # SIGTERM: pide que termine
kill -9 4117                            # SIGKILL: lo mata al instante

P212 tuberías en paralelo: ProcessBuilder

BankFilter hace desde Java lo mismo que esta línea de shell, pero para los 12 meses a la vez:

java StatementFilter amount -gt 100 < statement-01.txt | java StatementFilter amount -lt 200 >> filter.txt

Cada filtro es un proceso: 2 filtros × 12 meses = 24 procesos a la vez. StatementFilter lee de System.in y escribe en System.out, como un grep. Resultado: solo los SUPERMERCAT de 120 € (52 líneas).

public static void main(String[] args) throws IOException {
    deleteOldOutput();                                       // filter.txt se escribe en append
    List<Process> lastPipelineProcesses = startAllPipelines(); // fase 1: arrancar, SIN esperar
    collectOutputs(lastPipelineProcesses);                    // fase 2: recoger en orden
    System.exit(0);
}

private static Process startPipeline(String fileName) throws IOException {
    List<ProcessBuilder> builders = createProcessBuilders();          // un builder por filtro
    builders.get(0).redirectInput(new File("bank", fileName));      // solo el 1º lee el fichero  (= <)
    List<Process> processes = ProcessBuilder.startPipeline(builders); // arranca y conecta  (= |)
    return processes.get(processes.size() - 1);                       // el último tiene el resultado
}

private static void collectOutputs(List<Process> last) throws IOException {
    try (FileOutputStream fos = new FileOutputStream(OUTPUT_FILE, true)) {   // (= >>)
        for (Process process : last) {
            process.getInputStream().transferTo(fos);   // espera solo si ese mes no ha acabado
        }
    }
}

Lo que pide la rúbrica de la parte 2

# Ejecutar el filtro a mano con redirecciones (¡si no sabes, suspendes la parte 2!)
java -cp bin bank.filter.StatementFilter amount -gt 100 < bank/statement-01.txt > salida.txt
java -cp bin bank.filter.StatementFilter amount -gt 100 < bank/statement-01.txt | java -cp bin bank.filter.StatementFilter amount -lt 200 > enero.txt

# Un filtro sin < se queda esperando teclado: así puedes buscarlo y matarlo
java -cp bin bank.filter.StatementFilter concept -eq super
jps -l        # en otra terminal
kill 5230

# Modificar la pipeline: retiradas de 100 € o más
{ "java", "-Duser.dir=bin", FILTER_CLASS, "operation", "-eq", "withdraw" },
{ "java", "-Duser.dir=bin", FILTER_CLASS, "amount", "-ge", "100" }

Operadores de StatementFilter: columnas operation y concept con -eq/-ne (en concept, -eq significa «contiene»); amount con -lt -le -eq -ge -gt -ne. El importe se compara sin signo.