"Hallo Amigo!"
"We gaan een nieuw onderwerp starten: threads."
"Laten we beginnen. Vandaag zullen we de toestanden onderzoeken die een Thread-object passeert (of zou kunnen passeren) wanneer een thread wordt uitgevoerd."
"Hoeveel staten kun je nu opnoemen, Amigo?"
"Twee. De eerste is een thread voordat de methode start() wordt aangeroepen: het object bestaat, maar de thread is nog niet actief. En de tweede is nadat de methode start() is aangeroepen: wanneer de thread iets aan het doen is belangrijk."
"Je hebt gelijk - er is zo'n onderscheid. Deze staten worden nieuw en actief genoemd , maar dat is nog maar het begin."
"Ten eerste zal de thread op een gegeven moment stoppen met draaien, wat betekent dat er een situatie kan zijn waarin het Thread-object bestaat, maar de thread niet in de nieuwe of actieve staat is. "Deze staat, waarin de thread klaar is met draaien, wordt genoemd beëindigd ."
"Maar er is meer. Vergeet niet dat er op elk moment maar één thread actief is. Wat simultaan werk lijkt, is eigenlijk dat de processor constant van thread naar thread springt. Er is een aparte status voor wanneer de thread lijkt te zijn actief is, maar eigenlijk op zijn beurt wacht: het wordt ready-to-run genoemd . Terwijl een thread werkt, schakelt hij constant over van running naar ready , en dan weer terug naar running wanneer hij weer actief wordt."
"Onmiddellijk nadat de methode start () is aangeroepen, krijgt de thread de status Ready-to-run toegewezen en wordt deze in een gedeelde lijst met threads geplaatst waar de JVM tussen schakelt."
"Dat is niet zo moeilijk. Voordat het begint te draaien, heeft het de nieuwe status. Nadat het klaar is, wordt het beëindigd . Als het draait, is de thread actief ; als het wacht, is het klaar . ."
"Je beknoptheid is verbazingwekkend, maar je hebt gelijk."
"Maar er is meer. De thread kan worden geblokkeerd. Bijvoorbeeld wanneer u een gesynchroniseerd blok invoert. Als een thread een codeblok bereikt dat is gemarkeerd als gesynchroniseerd en een andere thread gebruikt het, dan zal onze thread de geblokkeerde status ingaan en wachten om de mutex (vergrendeling) van het object te ontgrendelen."
"Zo ziet deze situatie met staten eruit:"
"Maar er is meer. Er is ook een aparte status die waiting wordt genoemd . Dit is wanneer een thread niet is geblokkeerd , maar ook niet gereed is . Bijvoorbeeld wanneer je de join ()-methode aanroept op een andere thread."
Wanneer we join() aanroepen op een ander Thread-object, is het alsof onze thread zich "verbindt", maar in werkelijkheid wacht het gewoon tot de andere thread klaar is.
"Bovendien is er ook de wait () methode (van het wait/notify/notifyAll trio van methoden), die een thread in de wachtstand zet wanneer deze wordt aangeroepen."
"Wauw."
"Wacht even! Er is nog meer. Een thread kan slapen door bijvoorbeeld de slaapmethode aan te roepen. Hier is ook een aparte status voor. Dat heet « getimed wachten ». « getimed wachten » betekent dat de thread ergens op wacht een beperkte tijd. Als u een wait-methode aanroept met een parameter, zoals wait(timeout) of join(timeout), dan gaat de thread naar de status timed-waiting."
"Hier is het volledige diagram:"
"Hmm. Is dat alles? Of zijn er nog 10 interessante staten?"
"Voor nu is dat het."
"In de praktijk kun je het eerste diagram gewoon onthouden. Het is eenvoudiger. Maar het tweede is nauwkeuriger."
"Vreemd genoeg zijn er veel Thread-statusdiagrammen op internet en ze zijn allemaal verschillend."
"Daarom heb ik je dit diagram gegeven - het is het meest complete en correcte."
"In dit diagram worden de toestanden gereed en actief gecombineerd in een enkel blok dat runnable wordt genoemd. Weet je waarom?"
'Nee. Het is de eerste keer dat ik zoiets zie.'
"De Thread- klasse heeft een interne klasse genaamd State , evenals een openbare State getState()- methode."
public enum State
{
NEW,
RUNNABLE,
BLOCKED,
WAITING,
TIMED_WAITING,
TERMINATED;
}"Je kunt altijd de getState () -methode op een Thread- object aanroepen en de huidige status ervan achterhalen. En natuurlijk zal het een van de State-enumwaarden zijn."
"Ik begrijp het. Dus de echte staten bevinden zich in de JVM, maar er zijn ook staten waartoe u toegang kunt krijgen via Java-code met behulp van de methode State getState()."
"En onder welke omstandigheden zou ik dat gebruiken?"
"Waarschijnlijk nooit."
"Maar je moet weten wat er in threads gebeurt. Anders heb je een heleboel bugs en kun je niet eens raden wat de oorzaak is."
"Bovendien vragen werkgevers graag naar Thread-statussen tijdens interviews."
GO TO FULL VERSION