HashTable kann ohne Performance-Verlust in Multithreaded-Anwendungen eingesetzt werden.

[osion]

Hallo

Diese Aussage hat mich überrascht:
"Der Container HashTable kann ohne Performance-Verlust in Multithreaded-Anwendungen eingesetzt werden."

Thread-Safe ist es meiner Meinung nicht, weil ich könnte ja mehrmals den gleichen Hash-Wert überschreiben.

 

[KonradN]

Kannst Du evtl. etwas ausführen, was Du genau meinst?

Hashtable (Java SE 17 & JDK 17)

declaration: module: java.base, package: java.util, class: Hashtable

docs.oracle.com

Unlike the new collection implementations, Hashtable is synchronized. If a thread-safe implementation is not needed, it is recommended to use HashMap in place of Hashtable. If a thread-safe highly-concurrent implementation is desired, then it is recommended to use ConcurrentHashMap in place of Hashtable.

Ansonsten noch ein Vergleich HashMap zu Hashtable:

Differences between HashMap and HashTable in Java - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

www.geeksforgeeks.org

 

[Hansen_07]

Hallo

Diese Aussage hat mich überrascht:
"Der Container HashTable kann ohne Performance-Verlust in Multithreaded-Anwendungen eingesetzt werden."

Darf ich fragen woher diese Aussage stammt? Also die Quelle?

 

[LimDul]

Bezüglich der Performance würde ich das auch eher als fraglich sehen.

Aber hierzu:

Thread-Safe ist es meiner Meinung nicht, weil ich könnte ja mehrmals den gleichen Hash-Wert überschreiben.

Das hat nix mit Thread-Sicherheit zu tun, dass mehrere Threads da einander Dinge überschreiben können.

Thread-Safe heißt, es gibt zwei Threads A und B, die eine Operation auf einem Objekt durchführen wollen. Thread A will opA durchführen, Thread B will opB durchführen. Wenn das Objekt Thread Safe ist, heißt es, wenn die beide es gleichzeitig durchführen wollen kommt eins von folgenden zwei Ergebnissen raus: Erst opA, dann opB oder erst opB und dann opA.

Sprich, dass Ergebnis ist dasselbe wenn sie in Reihenfolge durchgeführt werden (man weiß nur die Reihenfolge nicht).

Bei einem nicht Thread-Safen Objekt kann es passieren, dass dabei Murks raus kommt und Stände entstehen, die nicht entstehen würden, wenn man es in Reihenfolge macht.

Mal banal auf HashTable bezogen, wenn Thread A den Wert X speichern will und Thread B den Wert Y, dann ist sichergestellt, dass danach entweder X oder Y gespeichert ist (man weiß vielleicht nicht vorher welcher von beiden). Während bei einem nicht Thread-Safen Objekt vielleicht Z oder null am Ende gespeichert ist.

 

[temi]

Bezüglich der Performance würde ich das auch eher als fraglich sehen.

Aber es könnte stimmen, denn es wird ja in der Doku darauf hingewiesen (siehe #2), dass es empfohlen wird die (vermutlich performantere) HashMap zu verwenden, wenn man Threadsicherheit nicht benötigt.

Es ist also wohl eher umgekehrt:

"Der Container HashTable kann ohne Performance-Gewinn auch in Singlethreaded-Anwendungen eingesetzt werden."

 

[KonradN]

Die Frage ist, wie man Performance Verlust definiert. Und natürlich ist es ein Performance Verlust, wenn ein Thread warten muss, bis ein anderer fertig ist. Damit macht parallelisierung nur begrenzt Sinn, wenn alle Aufrufe synchronized sind und die Zugriffe eine große Bedeutung spielt.

 

[httpdigest]

Ja,... also wenn der Bottleneck deiner Anwendung das synchronized einer HashTable ist (also ohne Contention mit mehreren Threads), dann hast du quasi alles richtig gemacht.