The mapping between Java threads and Linux kernel threads

Linux starts with the NPTL (Native POSIX thread Library) support from Kernel 2.6, but at this point the threads are inherently lightweight processes.

Threads in Java are managed by the JVM, and how it corresponds to the operating system's threads is determined by the implementation of the JVM. The hotspot on Linux 2.6 uses the NPTL mechanism, and theJVM thread has a one by one relationship with the kernel lightweight process . The scheduling of threads is completely given to the operating system kernel, and of course the JVM retains some policies that affect its internal thread scheduling, for example, under Linux, as long as a thread.run will invoke a fork to produce a thread.

The way Java threads are implemented on Windows and Linux platforms now seems to be the way kernel threads are implemented. threads implemented in this way are directly supported by the operating system kernel-the kernel completes thread switching, the kernel implements thread scheduling by manipulating the scheduler (thread Scheduler), and the thread tasks are reflected on individual processors. Kernel threads are a single clone of the kernel. Instead of using the kernel thread directly, the program uses its advanced interface, the lightweight process (LWP), which is the thread. This may seem a mouthful. Look at the picture:

(Note: KLT is the kernel thread kernel the thread, which is "Kernel clone".) Each KLT corresponds to one of the lightweight processes in Process P LWP (also known as threads), during which the user state, the kernel state of the switch, and the thread Scheduler on the processor CPU. ）

The way this thread is implemented also has its drawbacks: using kernel threads on the program surface will inevitably switch the user and kernel states back and forth on the operating system, and the support number of LWP is limited because it is a one-to-two threading model.

For a large program, we can the number of threads opened at least equals the number of CPU cores running the machine。 In the Java program we can get this number by the following line of code:runtime.getruntime (). Availableprocessors ();so the minimum number of threads is instantaneous CPU cores. If all the tasks are computationally intensive, the minimum number of threads is the number of threads we need. Opening up more threads only affects the performance of the program, because switching between threads consumes additional resources. If the task is IO-intensive, we can open up more threads to perform the task. When a task performs an IO operation, the thread will be blocked and the processor will immediately switch to another appropriate thread to execute. If we only have as many threads as the number of cores, even if we have a task to execute, they cannot do it because the processor does not have a thread that can be used for scheduling. If a thread is blocked 50% of the time, the number of threads should be twice times the number of cores. If fewer ratios are blocked, then they are computationally intensive, and fewer threads need to be opened. If more time is blocked, then the IO-intensive program can open up more threads. So we can get the following calculation formula for the number of threads:number of threads = number of cores/(1-blocking rate)We can use the corresponding analysis tool or Java management package to get the value of blocking rate. ============ Reprint Http://blog.sina.com.cn/s/blog_605f5b4f010198b5.html

The mapping between Java threads and Linux kernel threads