Ich habe eine Frage bezüglich der Implementierung einer Stornierungsrichtlinie für eine Thread-Unterklasse. Es scheint üblich zu sein, es so zu machen:
%Vor%Die Frage, die ich habe, bezieht sich auf Thread.currentThread () ... Warum ist es üblich, currentThread () zu verwenden, um das Unterbrechungsflag zu überprüfen, aber nicht, es in der cancel () -Methode zu setzen? Wäre es nicht ausreichend, einfach die Methode isInterrupted () von A wie folgt aufzurufen:
%Vor%Ich konnte weder im Thread JavaDoc noch in Brian Goetz 'hervorragendem Buch über gleichzeitiges Java oder stack overflow eine Antwort finden.
Vielen Dank im Voraus für Ihre Einsichten!
Prost, Georg
In Ihrem Fall genügt es, !isInterrupted() aufzurufen, weil Sie von der Klasse Thread ausgehen. Normalerweise dehnen Sie nicht von Thread aus - deshalb rufen Sie Thread.currentThread() auf.
Ausgehend von Java 5 ist es keine gute Idee, direkt mit Threads zu arbeiten . Sie sollten stattdessen das Executor-Framework verwenden und je nach Ihren Anforderungen eine Ausführungsrichtlinie auswählen. Die Instanz isInterrupted() -Methode testet, ob dieser Thread unterbrochen wurde. Der unterbrochene Status des Threads ist von dieser Methode nicht betroffen. Die innere isInterrupted() ist eigentlich eine native Methode.
Bei der Verwendung des Executor-Frameworks wissen Sie nicht, welche Thread-Instanz gerade Ihren Code ausführt, daher lautet die Konvention Thread.currentThread.isInterrupted ()
Das cancel ist klar: Es leitet den Aufruf effektiv an this.interrupt ; die Thread-Instanz, auf die die cancel -Methode angewendet wird.
Wie bei der Methode run ist alles, was Sie angeben, sinnvoll, wenn man annimmt, dass die Methode run tatsächlich von der (erwarteten) Instanz von class A aufgerufen und nur aufgerufen wurde. Während das wahrscheinlich eine sichere Annahme ist, ist es allgemein wahr? Nun, wenn Sie mich nach einem aussagekräftigen Beispiel dafür fragen, wie / wann diese Annahme verletzt werden könnte, ich bin mir nicht sicher, ob ich das so spät in der Nacht aus meinem Hut ziehen kann: -)
Betrachten Sie eine andere Methode als run . Wenn es eine Methode auf class A ist, sollte sie davon ausgehen, dass sie von / auf demselben Thread aufgerufen wird? Vielleicht ist es eine Methode in einer anderen Klasse. Es scheint also wahrscheinlich, dass dies nur eine Best-Practice-Methode ist, um potenzielle Bugs zu eliminieren: Ihr Code wird kopier- und pastensicher [@Thomas hat diese Einsicht auch gemacht]
Es sollte gleich sein, wenn dieser Code im gerade laufenden Thread ist. Vielleicht befürchten Autoren, dass jemand die run-Methode in einem anderen Thread ausführen wird, vielleicht wollen sie, dass es genauso aussieht wie anderswo. Oder sie kopieren es eingefügt und haben nicht gedacht.
Tags und Links java multithreading concurrency