Ich suche eigentlich nach einem einfacheren Weg den Thread zu beenden, egal wo der Thread läuft. Aber die meisten Lösungen im Internet weisen mich darauf hin, das boolesche Flag zu verwenden, um die Ausführung des Threads zu steuern. Wenn ich den Thread stoppen möchte, setze die boolesche Variable auf false.
Aber was, wenn die Aufgabe, die im Runnable ausgeführt wird, eine LANGE lineare Aufgabe ist, was bedeutet, dass sich die Aufgabe nicht wiederholt? In diesem Fall ist es nicht so einfach, eine "while" -Schleife zu erstellen, um den gesamten Aufgabenblock abzudecken.
Es ist wirklich so verlockend, Thread.stop zu verwenden, aber die Warnung "Veraltet" scheint ziemlich gefährlich zu sein. Ich habe diesen Artikel gelesen Warum sind Thread.stop, Thread.suspend, Thread.resume und Runtime.runFinalizersOnExit veraltet ?
aber ich kann es nicht verstehen
Wenn eines der zuvor von diesen Monitoren geschützten Objekte in war Ein inkonsistenter Zustand. Andere Threads können diese Objekte nun in einem anzeigen inkonsistenter Zustand. Solche Objekte sollen beschädigt sein.
Was bedeutet der "inkonsistente Zustand"? Ich schätze es, wenn jemand das erklären kann.
Ich möchte meine Frage auf eine niedrigere Ebene der Ansicht ausdehnen, sagen wir i = i + 1; in JVM (vielleicht Assemblersprache), vielleicht wird diese Java-Anweisung in einige kleinere Anweisungen aufgeteilt, zum Beispiel wie move i ; add i ; get i into memory 0x0101 ( Dies ist ein Beispiel! Ich kenne die Assemblersprache überhaupt nicht!)
Nun, wenn wir thread.stop aufrufen, wo wird es eigentlich aufhören? Wird der Thread nach einer COMPLETED-Java-Anweisung anhalten oder in der Mitte der "Assemble-Sprache" sein? Wenn die Antwort die zweite ist, könnte es ein Grund sein, dass wir gesagt haben
Solche Objekte sollen beschädigt sein.
?
Ok, meine Frage ist irgendwie verwirrt, hoffe jemand kann es verstehen und erklären. Vielen Dank im Voraus.
Der "inkonsistente Zustand" bedeutet den Zustand der Daten, wie es Ihrer Anwendung wichtig ist. Geben Sie an, dass Ihre Anwendungslogik sorgfältig erstellt wurde, indem Sie Ihre Anwendung mit Sperren / Monitoren threadsicher machen.
Stellen Sie sich vor, Sie haben diese einfache Methode:
%Vor%Diese Methode wird zusammen mit anderen Methoden synchronisiert, da mehrere Threads dieses Objekt verwenden. Vielleicht gibt es ein
%Vor%Dies stellt sicher, dass ein Thread eine unvollständige Messung nicht lesen kann, d. h. wenn die aktuelle Messung innerhalb von z.B. doSomething (), getMeasurement () blockiert / wartet, bis das erledigt ist.
Stellen Sie sich nun vor, dass doSomething in einem Thread ausgeführt wird und Sie .stop() für diesen Thread aufrufen.
Der Thread wird also möglicherweise direkt nach der Ausführung von count++; gestoppt, der gehaltene Monitor wird entsperrt und die Methode wird beendet und average = count/total; wird nicht ausgeführt,
Das bedeutet, dass die Daten jetzt inkonsistent sind. Wer danach getMeasurement () aufruft, erhält nun inkonsistente Daten.
Beachten Sie auch, dass es an dieser Stelle nicht sehr relevant ist, ob dies auf einer Java-Anweisungsebene oder auf einer niedrigeren Ebene geschieht. Die Daten können sich in einem inkonsistenten Zustand befinden, über den Sie in keinem Fall nachdenken können.
"Beschädigtes Objekt" ist ein High-Level-Konzept, es passiert nicht auf JVM-Ebene. Ein Programmierer entwirft seine Klasse mit Blick auf die Thread-Sicherheit, indem er kritische Bereiche mit Schlössern schützt. Es ist eine Invariante seiner Klasse, dass jeder kritische Abschnitt entweder vollständig ausgeführt wird oder gar nicht abläuft. Wenn Sie stop einen Thread verwenden, wurde ein kritischer Abschnitt möglicherweise in der Mitte unterbrochen, wodurch die Invariante unterbrochen wird. In diesem Moment ist das Objekt beschädigt .
Das Stoppen eines Threads birgt viele weitere Gefahren, z. B. keine Säuberung durchgeführt, keine erworbenen Ressourcen freigegeben usw. Wenn ein Thread nicht aufgibt, was er tut, gibt es keine Möglichkeit, ihn aufzuhalten, ohne die gesamte Anwendung zu kompromittieren.
In der Praxis muss jedesmal, wenn ein Alien-Code ausgeführt werden muss, der zwangsweise abgebrochen werden muss, dies in einem separaten Prozess erfolgen, da das Löschen eines Prozesses mindestens die Bereinigung auf Betriebssystemebene durchführt macht es viel besser, den Schaden einzudämmen.
Ich bin kein Experte, aber das ist, was ich denke.
Wenn Sie Thread.stop() verwenden, verursachen Sie die Ausnahme ThreadDeath , die dazu führt, dass alle Monitore freigegeben werden.
Da Sie eine Ausnahme provozieren, wenden Sie ein unnatürliches Verhalten auf den Zustand der Dinge an.
Andere Threads, die sich auf diese Monitore verlassen, könnten in eine inkonsistente Situation geraten, weil sie dies nicht erwartet haben. Und ich glaube nicht, dass Sie die Monitore vorhersagen können, die die Reihenfolge freigeben.
Ich glaube, das Problem ist, dass sich der Thread in der Mitte eines Synchronisierungsblocks befindet, der mehrstufige Aktualisierungen für die Mitglieder eines Objekts durchführt. Wenn der Thread abrupt gestoppt wird, sind einige Aktualisierungen eingetreten, aber keine anderen, und der Status des Objekts kann ihn jetzt unbrauchbar machen.
Ich habe meine Zweifel, dass die ThreadDeath-Behandlung eine Lock , die von AbstractQueuedSynchronizer unterstützt wird, freigibt, was die Anwendung auf dem Weg zu einer Art Deadlock lassen könnte.
An jedem logischen Punkt in Ihrer langen Code-Sequenz können Sie einfach hinzufügen:
%Vor% ... wird die Ausführung zu diesem Zeitpunkt beendet, wenn festgestellt wird, dass Thread.interupt() für die Thread aufgerufen wurde, die die lange laufende Aufgabe ausführt.
Es ist nicht klar, wie die stop.-Methode gestoppt werden kann, wenn die run () -Methode beendet wurde oder eine Ausnahme aufgetreten ist. thread ist dann stop.by, wenn die boolesche Flag-Variable .Bydefault "false"
Tags und Links java multithreading