"Ciao, Amigo! Abbiamo un argomento nuovo e molto difficile. Mi dispiace. Spesso è considerato uno degli argomenti più complessi non solo in Java, ma anche nella programmazione in generale. Sto parlando del multithreading . "
Immagina un tipico gioco per computer, ad esempio un gioco di corse di astronavi. Stai volando attraverso le distese del cosmo, schivando meteoriti e incrociatori di pattuglia. Altre due dozzine stanno partecipando con te a queste gare illegali.
Diciamo che decidi di scrivere un gioco del genere. Il tuo programma dovrà tenere traccia dei comandi (input da tastiera), muovere le astronavi, calcolarne le traiettorie, determinare le conseguenze di eventuali collisioni e disegnare tutto questo sullo schermo dell'utente. Questo è un lavoro molto complesso.
Ricordi come abbiamo risolto il «problema di grande complessità» nell'esempio della compagnia di spedizioni in crescita?
L'abbiamo diviso in dipartimenti indipendenti e rigidamente specificato (standardizzato) come potrebbero interagire.
"Ma cosa facciamo quando le parti indipendenti devono eseguire un lavoro in parallelo con le altre parti?! La risposta a questa domanda è threads ."
Prova a immaginare un programma come un piccolo robot che gira attorno al codice ed esegue i comandi . Innanzitutto esegue un comando su una riga, quindi passa a quella successiva e così via.
"Lo vedo nella mia mente. Un gioco da ragazzi!"
"Molto bene. E ora immagina di avere molti di questi robot. Mentre uno gestisce l'input dell'utente, un secondo aggiorna gli oggetti in base a quell'input. Un terzo esegue il codice per visualizzare questi oggetti sullo schermo. Diverse volte al secondo, un quarto controlla se qualche nave si è scontrata e, in tal caso, calcola i risultati della collisione."
Pertanto, non solo possiamo dividere il programma in parti/oggetti indipendenti, ma anche fare in modo che queste parti possano svolgere il proprio lavoro indipendentemente l'una dall'altra. Minore è l'interazione tra le singole parti, meno complesso è il programma.
Immagina di poter sostituire il manager con uno script che invia lettere . E gli altri reparti aziendali non erano nemmeno in grado di dire che c'era stato un cambiamento. Questo genere di cose avveniva già nel 26° secolo con ottimi risultati. La maggior parte dei manager, e persino dei massimi dirigenti, può essere sostituita con successo da uno script di media complessità. Solo dopo l'intervento dell'«office plankton union» sono cessati i licenziamenti di massa dei dirigenti. Ma sto divagando.
"Interessante!"
"Non solo possono esserci molti di questi "piccoli robot" che eseguono il codice, ma possono anche comunicare tra loro e generare nuovi robot".
"Genera nuovi robot?"
"Sì, per eseguire nuove attività. A volte è vantaggioso creare un altro robot (un altro thread) per eseguire un'azione contemporaneamente al thread corrente (robot)."
" Sembra una buona cosa, ma non riesco a pensare a dove la userei. "
E perché li chiamiamo « fili »?
"Immagina che ogni robot sia di un colore diverso e contrassegni i comandi con il suo colore mentre li esegue. Il percorso intrapreso dal piccolo robot è come la linea lasciata da una matita. Questo percorso si snoda dietro il robot, come un filo dietro un ago."
Ogni «piccolo robot» ha un compito per cui è stato creato. Puoi pensare a un thread è l'insieme di comandi eseguiti durante l'esecuzione di questa attività.
Diciamo che stai volando su un'astronave per consegnare il carico. Quindi "consegnare il carico" è il tuo compito e sei nel bel mezzo di eseguirlo. E la tua traiettoria di volo è il tuo filo. Potremmo dire che ogni nuovo compito, ogni compito non ancora completato, ha il suo filo (un percorso che deve ancora essere percorso).
"In altre parole, c'è un compito e un "robotino" che lo esegue. E un thread è solo il percorso seguito dal robot mentre completa il suo compito?"
"Esattamente."
È così che funziona tutto nel profondo. Poiché il computer dispone di un solo processore, può eseguire solo un comando alla volta. Quindi ecco cosa succede: il processore passa costantemente da un thread all'altro. Passa a un nuovo thread, esegue alcuni comandi, quindi passa al thread successivo, esegue alcuni comandi e così via. Ma poiché il passaggio da un thread all'altro avviene centinaia di volte al secondo, ci sembra che tutti i thread siano in esecuzione contemporaneamente.
