fabwu
commented
9 years ago A thread is a thread of execution in a program. The JVM allows an application to have multiple threads of execution running concurrently. In the Hotspot JVM there is a direct mapping between a Java Thread and a native operating system Thread. After preparing all of the state for a Java thread such as thread-local storage, allocation buffers, synchronization objects, stacks and the program counter, the native thread is created. The native thread is reclaimed once the Java thread terminates. The operating system is therefore responsible for scheduling all threads and dispatching them to any available CPU. Once the native thread has initialized it invokes the run() method in the Java thread. When the run() method returns, uncaught exceptions are handled, then the native thread confirms if the JVM needs to be terminated as a result of the thread terminating (i.e. is it the last non-deamon thread). When the thread terminates all resources for both the native and Java thread are released. http://blog.jamesdbloom.com/JVMInternals.html
JVM mappt Java Threads zu Native Threads und das BS kümmert sich um Verteilung auf CPU's
alexsuter
Wir sprechen von aktuellen JVMs (7, 8):
Wir haben ja die State-Engine für das Threading der JVM in VSK und PRG2 relativ gut gelernt. Ist das nun komplett User Level Threading? Weiss der Kern tatsächlich nichts von den eigentlichen Threads. Mir leuchtet ein, dass wenn man eine plattformunabhängige Threading Geschichte aufziehen will, muss das die JVM natürlich selber machen. Aber werden die Threads nicht irgendwo im System registriert. Das muss doch sein?
Wenn ich die JVM laufen lassen (= 1 Prozess), und darin 100 Threads. Sehe ich die Threads dann im Task Manager nicht? (also der Thread Counter). Wenn ich diese dort sehen würde, dann weiss doch der Kern bescheid darüber?
Oder ist es vielleicht eher ein kombinierter Ansatz wie bei "Zwei Level Thread Modell".