Sammlungen, die im .NET Framework 1.0 eingeführt wurden, sind im System.Collections-Namensraum zu finden. Diese Sammlungen, einschließlich der häufig verwendeten ArrayList und Hashtable, bieten eine Art Thread-Sicherheit durch die Synchronized-Eigenschaft, die einen threadsicheren Wrapper zurückgibt, der mit der Sammlung zusammenhängt. Der Wrapper funktioniert, indem er das gesamte Set für jede Hinzufügen- oder Entfernungsoperation sperrt. Daher muss jeder Thread, der auf die Sammlung zugreifen will, warten, bis er an der Reihe ist, um die Sperre zu erwerben. Dies ist nicht skalierbar und führt zu erheblichen Leistungseinbußen für große Sammlungen. Darüber hinaus verhindert dieses Design keinen Streit vollständig. Weitere Informationen finden Sie auf der folgenden Seite auf der MSDN-Website: Synchronisation in generischen Sammlungen
Die im .NET Framework 2.0 eingeführte Collection-Klasse ist im System.Collections.Generic Namensraum zu finden. Zu diesen Sammlungskursen gehören List<T>, Wörterbuch< TKey, TValue> usw. Diese Klassen bieten eine höhere Typsicherheit und Leistung im Vergleich zu .NET Framework 1.0-Klassen. Die Collection-Klasse .NET Framework 2.0 bietet jedoch keine Thread-Synchronisation; Beim Hinzufügen oder Entfernen von Elementen auf mehreren Threads gleichzeitig muss der Benutzercode alle Synchronisationen bereitstellen.
Wir empfehlen die Verwendung gleichzeitiger Sammlungsklassen in .NET Framework 4, da sie nicht nur die Typsicherheit der .NET Framework 2.0-Sammlungsklassen bieten, sondern auch eine effizientere und vollständigere Thread-Sicherheit bieten als die Thread-Sicherheit der .NET Framework 1.0-Sammlung.
Einige gleichzeitige Sammlungstypen verwenden leichte Synchronisationsmechanismen wie SpinLock, SpinWait, SemaphoreSlim und CountdownEvent, die im .NET Framework 4 neu sind. Typischerweise verwenden die oben genannten Synchronisationstypen das "busy spinning" für eine kurze Zeit, bevor der Thread in den eigentlichen Wartezustand versetzt wird. Wenn die Wartezeit sehr kurz erwartet wird, verbraucht der Spin deutlich weniger Rechenressourcen als die Wartezeit, was Kernel-Umwandlungen beinhaltet, die viele Ressourcen beanspruchen. Für Sammlungsklassen, die Rotation verwenden, bedeutet diese Effizienz, dass mehrere Threads in der Lage sind, Elemente sehr schnell hinzuzufügen und zu entfernen. Weitere Informationen zum Limitieren und Blockieren finden Sie bei SpinLock und SpinWait. Die ConcurrentQueue-<T> und ConcurrentStack-Klassen<T> verwenden überhaupt keine Sperren. Stattdessen verlassen sie sich auf Interlock-Operationen zur Gewindesicherheit.
illustrieren
Da gleichzeitige Collection-Klassen ICollection unterstützen, bieten sie Implementierungen für die Eigenschaften IsSynchronized und SyncRoot, auch wenn sie nicht miteinander verwandt sind. IsSynchronized gibt immer false zurück, während SyncRoot immer null ist (nichts in Visual Basic).
Die folgende Tabelle listet die Sammlungstypen im System.Collections.Concurrent Namensraum auf.
Art | Beschreibung | BlockingCollection<T> | Bietet<T> jegliche Art von Drosselung und Blockierung zur Implementierung von IProducerConsumerCollection. Weitere Informationen finden Sie unter BlockingCollection-Übersicht. | ConcurrentDictionary<TKey, TValue> | Key/value ist eine threadsichere Implementierung des Wörterbuchs. | ConcurrentQueue<T> | Thread-Sicherheitsimplementierung der FIFO-Warteschlangen (First in, first out). | ConcurrentStack<T> | Threadsichere Implementierung von LIFO (Last-in, First-Out)-Stacks. | ConcurrentBag<T> | Threadsichere Implementierung einer außerordentlichen Sammlung von Elementen. | IProducerConsumerCollection<T> | Typen müssen implementiert werden inBlockingCollectionSchnittstellen, die in der
|
|
Veröffentlicht am 06.06.2017 17:13:53
|
|
|
Veröffentlicht am 08.11.2017 15:24:45
|
Vermieter|
Veröffentlicht am 08.02.2021 10:00:41
|
