Thread-sichere Klassen in Java-Sammlungen
Thread-sichere Klassen
Im Sammlungsframework sind einige Klassen threadsicher, diese sind alle in jdk1.1 enthalten. Nach jdk1.2 erschienen viele nicht threadsichere Klassen. Im Folgenden sind diese threadsicheren Synchronisierungsklassen aufgeführt:
vector: Es verfügt über einen Synchronisierungsmechanismus mehr (Thread-Sicherheit) als arraylist. Aufgrund seiner geringen Effizienz wird seine Verwendung nicht mehr empfohlen. Bei Webanwendungen, insbesondere Frontend-Seiten, steht die Effizienz (Seitenreaktionsgeschwindigkeit) oft im Vordergrund.
Statck: Stack-Klasse, First In Last Out
Hashtable: Thread-sicherer als Hashmap
Enumeration: Enumeration, entspricht Iterator
Außer diesen, alles andere sind nicht threadsichere Klassen und Schnittstellen.
Die Methoden threadsicherer Klassen sind synchronisiert und es kann immer nur einzeln darauf zugegriffen werden. Es handelt sich um ein schweres Objekt mit geringer Effizienz.
Sonstiges:
1. Der Unterschied zwischen Hashtable und Hashmap
Hashtable ist Thread-sicher, das heißt, Hashtable-Methoden bieten einen Synchronisationsmechanismus, der nicht Thread-sicher ist , das heißt, es ist kein Synchronisierungsmechanismus vorgesehen; Hashmap erlaubt das Einfügen von Nullwerten nicht!
2. Was ist zu tun, wenn mehrere Threads gleichzeitig eine Sammlung ändern?
Verwenden Sie den alten Vector/Hashtable Klasse
StringBuffer ist Thread-sicher, während StringBuilder Thread-unsicher ist. Ohne ein tiefes Verständnis von Sicherheit und Unsicherheit entsteht leicht die Illusion, dass alle Operationen auf StringBuffer threadsicher sind. Die von Java garantierte Thread-Sicherheit bedeutet jedoch, dass die Methodenausführung exklusiv ist Bei mehreren Aufrufen des Objekts selbst ist es immer noch sicher. Schauen Sie sich das folgende Beispiel an. Es gibt einen Datenelementinhalt, der zur Erweiterung verwendet wird, aber die Kombination mehrerer Anhänge ist nicht zu kontrollierbar. Wenn Sie jedoch das Schlüsselwort „synchronisiert“ zu den Protokoll- und getContest-Methoden hinzufügen, werden die Ergebnisse sehr organisiert. Wenn Sie zu StringBuider wechseln oder sogar auf halbem Weg anhängen, wird es auch anderen Threads weichen, die auf dieser Basis arbeiten:
public class StringBufferTest { private StringBuffer contents = new StringBuffer(); public void log(String message){ contents.append(System.currentTimeMillis()); contents.append("; "); contents.append(Thread.currentThread().getName()); for(int i=0;i<10000;i++){ contents.append(i); contents.append(message); //append本身是线程安全的,修改contents时,其它线程无法访问。 contents.append("\n"); } contents.append("\n\n"); } public void getContents(){ System.out.println(contents); } } class RunThread extends Thread{ String message; StringBufferTest buffer; public RunThread(StringBufferTest buffer, String message){ this.buffer = buffer; this.message = message; } public void run(){ while(true){ buffer.log(message); buffer.getContents(); } } public static void main(String[] args) { StringBufferTest ss = new StringBufferTest(); new RunThread(ss, "you").start(); new RunThread(ss, "me").start(); new RunThread(ss, "she").start(); } }
Die Methoden von StringBuilder und StringBuffer sind genau gleich, es handelt sich um ein Multithread- und ein Single-Threaded-Problem. Wenn ein Thread die Append-Methode desselben StringBuffer aufruft, hat das nichts damit zu tun, ob er threadsicher ist. Sofern Ihr Ergebnis nicht darin besteht, dass die angehängte Zeichenfolgenreihe durcheinander ist, bedeutet dies, dass er threadsicher ist. Thread-Sicherheit bedeutet, dass jeweils nur ein Thread auf kritische Ressourcen zugreifen kann. Thread-Sicherheit bedeutet nicht, dass seine Operationsreihen synchronisiert sind, sondern dass andere Threads sich nicht ändern dürfen, wenn er eine bestimmte Methode ausführt. Ob eine Klasse threadsicher ist, hängt davon ab, ob mehrere Threads gleichzeitig ausgeführt werden und diese Threads möglicherweise gleichzeitig eine bestimmte Methode ausführen. Das Ergebnis jeder Operation ist jedoch dasselbe wie bei der Single-Thread-Ausführung und kann daher als Thread-sicher bezeichnet werden. Da die Protokollmethode nicht gesperrt ist, erhält jeder nach Aufhebung der Anhängesperre möglicherweise Ausführungsfragmente der CPU.
Aber verstehen Sie die Multi-Thread-Sicherheit nicht falsch:
public String toString(){ StringBuffer buffer = new StringBuffer(); buffer.append('<'); buffer.append(this.name); buffer.append('>'); return buffer.toString(); }
Dieser Code ist vollständig threadsicher. Die in der Methode definierten Variablen werden erstellt, wenn jeder Thread eintritt. Es gibt keine Thread-Sicherheitsprobleme. Im Allgemeinen sind Variablen im Zusammenhang mit der Systemsicherheit im Allgemeinen Mitgliedsvariablen. Die interne Implementierung von stringBuffer selbst ist standortsicher! Thread-Sicherheit bedeutet, dass die von der Klasse selbst bereitgestellten Funktionen sicher sind. Das heißt, wenn Sie eine Zeichenfolge einfügen, ist das Einfügen dieser Zeichenfolge sicher, Sie müssen jedoch zwei Zeichenfolgen einfügen und die Reihenfolge der beiden Zeichenfolgen festlegen. Wenn in der Zwischenzeit andere Einfügefehler auftreten, spielt dies keine Rolle . Ja Problem mit Ihrem eigenen Code.
Vielen Dank fürs Lesen, ich hoffe, es kann Ihnen helfen, vielen Dank für Ihre Unterstützung dieser Website!
Weitere Artikel zum Thema Thread-Sicherheit über Klassen in Java-Sammlungen finden Sie auf der chinesischen PHP-Website!