Neue zusätzliche Felder in java.lang.Thread, was ist die Idee?

Question

Neue zusätzliche Felder in java.lang.Thread, was ist die Idee?

8

In Java 8 hat java.lang.Thread class 3 neue Felder erhalten:

%Vor%

wie es in Javadoc für die ausschließliche Verwaltung durch die Klasse java.util.concurrent.ThreadLocalRandom heißt.

Außerdem werden sie in ThreadLocalRandom auf sehr freakige Weise verwendet:

%Vor%

(derselbe Codestück kann auch in LockSupport class erfüllt werden).

und dann werden diese Offsets intern in mehreren java.concurrent places verwendet.

Was ist die Idee? Warum sind diese Felder in java.lang.Thread ? Warum nicht in ThreadLocalRandom ?

java java-8 thread-local

Andremoniy 30.12.2015, 12:01

quelle

2 Antworten

1

Ich werde das wieder aufleben lassen, indem ich eine kleine Antwort hinzufüge, da ich gerade diese in LongAdder getroffen habe und es gibt ein großartiges Video, wo Shipilev das in einfachen Worten erklärt (es ist auf Russisch), hier ist der Link: ThreadLocalRandom

Für den Fall von ForkJoinPool muss er Aufgaben in eine Warteschlange stellen und aus einer Warteschlange entfernen, wobei die Warteschlange genau über einen guten PRNG .

Dieses prng muss sehr schnell und hoch skalierbar sein. Nun, Java hat einen Platz: ThreadLocalRandom. Damit diese Felder in ThreadLocalRandom eingefügt werden können, benötigte sie ein ThreadLocal, das wiederum intern eine ThreadLocalMap verwendet (think HashMap).

ThreadLocal.get (denke HashMap # get) ist viel langsamer als diese Felder direkt aus Thread zu bekommen.

Eugene 07.12.2016 15:21

quelle

Tags und Links java java-8 thread-local

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Ablaufdatum des Enterprise Distribution-Bereitstellungsprofils

score 6 · Accepted Answer

Dies sind interne Felder. Erklärungen können nur von JDK-Entwicklern selbst kommen. Ich konnte dazu von Doug Lea einen Beitrag finden vom Januar 2013, erklärt die Gründe hinter diesen Feldern und warum sie innerhalb der Klasse Thread sind.

Als wir ThreadLocalRandom eingeführt haben, verhalten wir uns konservativ   implementiert, um eine tatsächliche ThreadLocal zu verwenden. Jedoch,   Je mehr es verwendet wird, desto besser ist es, es zu verbessern   die Umsetzung von Gehäuse ThreadLocalRandom Staat   (und damit verbundene Buchhaltung) in der Klasse Thread selbst.   Dies würde drei Felder (16 Gesamtbytes) umfassen.

Ich schlage vor, Folgendes zur Klasse Thread hinzuzufügen:
%Vor%
Die Gründe dafür sind:


Gleichmäßig schnellerer Zugriff auf ThreadLocalRandom state. Während    ThreadLocal access ist normalerweise schon ziemlich schnell, das ist   nicht nur schneller, es verschlechtert sich nicht in Fällen, in denen Benutzer   Programme erstellen eine große Anzahl von ThreadLocal s, die   kann (probabilistisch) dazu führen, dass irgendein gegebener Zugang wird   langsamer.



Geringere Gesamtfläche für jedes Programm, das ThreadLocalRandom verwendet.   Drei Felder benötigen weniger Platz als ein gepolstertes    ThreadLocal Objekt. As ThreadLocalRandom wird weit verbreitet   in JDK selbst beinhaltet dies fast alle Programme.



Weitere Zeit- / Raumeinsparungen für java.util.concurrent ForkJoinPool ,    ConcurrentHashMap , LongAdder , ConcurrentSkipList und andere   Klassen, die diese Form des einheitlichen ThreadLocalRandom verwenden könnten   Buchhaltung statt ihrer eigenen speziellen Zweck ThreadLocal s   wie sie es jetzt tun.