Virtuelles Thread-Pinning kann nicht reproduziert werden (JDK 21), aber MySQL ist nicht so parallel, wie es sein sollte ⇐ Java

[Anonymous]

Das JDK 21-Dokument über virtuelle Threads (im Folgenden „VT“)
(https://docs.oracle.com/en/java/javase/ ... reads.html)
ist ziemlich klar über einen synchronisierten Block, der dazu führt, dass ein Thread angeheftet wird, oder über native Methoden, oder ...
Alles begann mit einer weiteren SO-Frage zu MySQL und virtuellen Threads (Kann virtuelle Threads Abfragen einer Datenbank in Java verbessern?), und dies zeigte, dass VT MySQL-Anweisungen nicht wie vorgesehen parallelisiert (auf Treibern vor 9.0.0, z. B. 8.4). Aber ich kann das sicherlich in einer Kata reproduzieren.... Versuchen wir es!
Ich habe 12 Aufgaben mit 1 Thread pro Aufgabe erstellt, wobei jede Aufgabe 3 erledigt Blockierungsoperation von 1000 ms innerhalb eines synchronisierten Blocks. Es sollte 3x1000ms = 3 Sekunden pro Aufgabe dauern. Zumindest in Plattformthreads. Und diese Plattform-Threads tun dies immer vorhersehbar.
Ich habe Variationen von Blockierungsoperationen als Object.wait() in synchronisierten s geschrieben, als einfache Thread.sleep() (synchronisiert und nicht) , als Condition.await() von ReentrantLock und als Socket-Inputstream read() (synchronisiert und nicht). Mein Geld wurde im Netzwerk gelesen, da das der MySQL-Treiber war. Außerdem können wir der JDK-Quelle entnehmen, dass object.wait() und thread.sleep() VT-freundlich gemacht wurden. Ich habe es sogar versucht, aber ein Pipe Input/Output Stream-Setup gelöscht, da alles auf der gleichen vorherigen In-Memory-Synchronisierung basiert.
Bei VTs sollte ich laut Dokument synchronisiert und nativ erwarten Methoden, aber keine Reentrantlocks, würden mehr Zeit in Anspruch nehmen, aber es würde davon abhängen, wie viele Carrier-Threads es gibt ... Das sagen sie nicht.
(UPDATE: Eigentlich habe ich das später dort gefunden sind so viele wie Kerne, aber Extras insgesamt können bis zu 256 erstellt werden).
Wenn es nur so viele Trägerthreads wie Kerne gibt, dann habe ich 4 Träger. Ich sollte damit rechnen, dass meine Aufgaben nur 4 gleichzeitig ausführen, wenn ich den VT wirklich fixiert habe, und dass die gesamten Aufgaben innerhalb der 9-Sekunden-Marke abgeschlossen sind.
Das wollte ich beweisen. Also habe ich diesen komplexen Test unten geschrieben.
Und ich habe es versäumt, einen Träger-Thread anzupinnen; (zunächst: siehe meine eigene Antwort) Die 12 Aufgaben enden fast gleichzeitig bei der 3-Sekunden-Marke.< /p>
Was noch interessanter ist, ist, dass ich 12 Threads gestartet habe, aber irgendwann 14 Träger verwendet wurden.
(UPDATE: Dies sind die erwarteten zusätzlichen Träger nachdem ich ein besseres Dokument gefunden habe: „Die Erfassung eines Betriebssystems Thread wird durch vorübergehendes Hinzufügen eines Trägerthreads zum Scheduler kompensiert />Um die übertragene Thread-ID anzuzeigen, habe ich zunächst JNA verwendet, um den Kernel 32 GetCurrentThreadId() abzurufen. Später habe ich Foreign Function Invocation (FFI) verwendet, wie von einem Kommentator vorgeschlagen. Ich habe diesen JNA-Code seitdem entfernt.
Ich werde den Code der ursprünglichen Frage nicht wiederholen, da er veraltet ist und vieles mehr, selbst wenn Sie die Antwort nicht auch lesen.
Ich wollte unbedingt wissen, wie der ältere MySQL-Treiber 8.4 einen VT-Träger so anheften kann, dass die Parallelität reduziert wird, und insbesondere, wie sie das im Treiber 9.0.x beheben würden, aber ich hatte keine Lust, MySQL-Code zu lesen zu tun Das. Es schien, als wäre eine Kata in der Größe einer einzelnen Datei angebracht.
(UPDATE: Ich habe also den Weg gefunden, das Anheften zu reproduzieren, siehe Antwort.)
(UPDATE: Seit der Antwort haben Kommentatoren festgestellt, dass Java 24 synchronisierte()-Blöcke und -Methoden so implementieren wird, dass VTs die Bindung von den Plattform-Threads lösen können.)