"Go" java JVM thread vs. operating system thread

Original link: http://segmentfault.com/q/1010000000370403

Java's goal is to cross-platform, and different operating systems (such as UNIX-like and Windows) its task scheduling mechanism is very different, so Java at the JVM level abstracted a set of its own threading mechanism to map the different operating system task scheduling. As you mentioned some of the drawbacks, Java after version 1.1, this threading module is based on kernel-level threading [1].

First, if there is only one logical CPU on a machine, then the system scheduler can schedule the task by rotating the time slice, so there is no real parallel, only concurrency; only multiple logical CPUs will appear in parallel;

Second, for different operating systems, the task scheduling mechanism is different:

1. For Unix-like systems, the
2. is typically the scheduling unit for a process as a task, or an operating system scheduler that allocates resources such as CPUs for a process. Because processes are independent of each other and are not directly accessible to each other, this increases the communication costs of the application. So behind the micro-process, micro-process and process is different, allow to a certain extent, each other can be directly accessed, in detail, refer to linuxthreads. The JVM, under some Unix-like platforms, is the process of mapping threads to the operating system's micro-processes to implement thread scheduling. In this way, multiple threads can be dispatched directly by the system scheduler, which corresponds to the high cost of creating and destroying their threads, and that the JVM's thread priority is difficult to match and does not provide an exact guarantee, just a hint. It should be explained that after linux2.6, Linuxthreads is replaced by NPTL, NPTL provides a 1:1-form threading model, that is, each thread one by one corresponds to a kernel scheduling entity, which is the kernel-level thread. The same NPTL provides additional replaceable m:n model thread.
   A call for the JVM to create a thread under Linux (bool Os::create_thread in Os_linux.cpp in Openjdk-6-src-b27 (thread* thread, Threadtype thr_ Type, size_t stack_size):
   int ret = pthread_create (&tid, &attr, (void* (*) (void*)) Java_start , thread);
   Specific follow-up call tracking, please refer to the implementation of Pthread;
4. For Windows systems, the first thread is the 1:1 model described in the system's smallest unit of dispatch, Wiki[thread]. And for the user-state thread and kernel-state thread, is generally for the N:1 model and the M:N model, that is, multiple user-state threads mapped to a kernel thread, the system scheduler is the kernel-state thread, the user-state thread is ignorant. The individual is not very familiar with the threading model of Windows, as described in NPTL and Wiki[thread] and, it feels that Windows directly takes the thread as the dispatch unit without the difference between the user-state thread and the kernel-state thread. It is important to note that the JVM-defined thread priority and the thread priority of Windows can match nicely.
   Windows JVM creates a call to thread-(bool Os::create_thread in Os_windows.cpp in Openjdk-6-src-b27 (thread* thread, Threadtype thr_ The following API is called in Type size_t stack_size):
   HANDLE thread_handle = (HANDLE)_beginthreadex(NULL, (unsigned)stack_size, (unsigned (__stdcall *)(void*)) java_start, thread, CREATE_SUSPENDED | STACK_SIZE_PARAM_IS_A_RESERVATION, &thread_id);
   Refer to the Windows API for specific follow-up calls.

Finally, answer your question:

1. Java multithreading is not deceptive, for different operating systems to adapt, it does achieve concurrency and parallelism;
2. User-level threads usually occur at the process level, typically through different implementations such as system invocation to simulate implementation concurrency, while kernel-level threads are generally dispatched by the scheduler of the system, which is a native level of concurrency;
3. Kernel-level threads have the system scheduler scheduling, can certainly enjoy the benefits of multi-core, and user-level thread is through the simulation implementation of scheduling, because its mapping of the scheduling entity (process or mapped kernel-level thread) is the system scheduler scheduling unit, so compared with the kernel-level thread, its access to resources is indeed a certain limit. For more detailed information or to continue in-depth understanding, please refer to the reference wiki and other literature

"Go" java JVM thread vs. operating system thread