Java multithreading model and java Multithreading

Java multithreading model and java Multithreading

Speaking of Java multithreading, it involves multithreading models and the relationship between Java threads and underlying operating systems. As we are familiar with, modern machines can be divided into two major parts: hardware and software, 2-5-1-1. hardware is the foundation, and software provides means to implement different functions. Moreover, software can be divided into operating systems and applications. The operating system focuses on the interaction management of hardware and provides a runtime environment for applications to use, applications are software that can implement several functions and run in the operating system environment. Likewise, threads can be divided into Kernel threads and User threads Based on the operating system and applications ).
 
Figure 2-5-1-1
A kernel thread is a thread that is directly supported and managed by the operating system kernel. operations such as thread creation, startup, synchronization, destruction, and switching are completed by the kernel. Basically all modern operating systems support kernel threads. A user thread is a thread database fully built in the user space. It is supported by the kernel without kernel management, and the kernel cannot perceive the existence of the user thread, thread creation, startup, synchronization, destruction, and switching are all completed in the user mode, without switching to the kernel. User threads can be viewed as higher-level threads, while kernel threads are the bottom-Layer Support. Therefore, there must be a ing Relationship between them. Generally, there are three common relationships, the following lists them one by one.
① One-to-one model
One-to-one model is the simplest ing model. 2-5-1-2, KT is the kernel thread, UT is the user thread, and each user thread corresponds to a kernel thread, because each user thread has its own kernel thread, they do not affect each other. Even if one thread is blocked, another thread is allowed to continue execution. This is undoubtedly an advantage of this model, however, there is also a serious defect. Due to the one-to-one relationship, the number of user threads represents the number of kernel threads, while the overhead of kernel threads is high, generally, the operating system limits the number of kernel threads and the number of user threads.
 
Figure 2-5-1-2
② Multiple-to-one model
The second is the multi-to-one model, which is 2-5-1-3. You can clearly see that multiple user threads are mapped to the same kernel thread, it can be seen that a kernel thread implements the concurrent functions of several user threads. thread management is carried out in the user space and generally does not need to be switched to the kernel state, which is highly efficient, in addition, compared to the one-to-one model, more threads are supported. However, this model has a fatal weakness: If a thread executes a blocking call, all threads will be blocked and only one thread can access the kernel at any time. In addition, all operations on the thread will be handled by the user application. Therefore, this model is generally not used in a multi-threaded operating system except for operating systems that do not support multithreading.
 
Figure 2-5-1-3
③ Multiple-to-Multiple Model
Many-to-many models are proposed to solve the disadvantages of the previous two models. 2-5-1-4, multiple user threads are mapped to Multiple kernel threads to form multiplexing. The one-to-one model mentioned above has the problem of being limited by the number of kernel threads. Although many-to-one models solve the number restriction problem, it has the risk of one thread blocking leading to the blocking of all threads, in addition, the concurrency is not strong because only one core thread can schedule only one thread. Let's take a look at how many-to-many models solve these problems. Because many-to-one is a multi-to-many subset, many-to-many has the advantage of many-to-one, and the number of threads is not limited. In addition, Multiple kernel threads can process multiple user threads. When a thread is blocked, another thread can be scheduled for execution. This also enhances concurrency.
 
Figure 2-5-1-4

The three models have their own characteristics. Different modern operating systems may use different thread models. For example, linux and windows may use one-to-one models, some versions of solaris and unix may use many-to-many models. For thread creation and management, the thread Library provides user-level and kernel-level APIs for operations. At the user level, because kernel operations are not involved, all code and data structures are stored in the user space. On the contrary, the kernel level is supported by the kernel and will directly call the kernel system operations, the code and data structure exist in the kernel space. In actual programs, we generally do not directly use kernel threads. User threads and kernel threads directly need an intermediate data structure, which is supported by the kernel and is an advanced abstraction of kernel threads, this advanced interface is called Light Weight Process (LWP. Figure 2-5-1-5 adds lightweight processes to three models. From a perspective, LWP is a user thread in a broad sense, not a user process defined in a narrow sense. The LWP thread library is based on the kernel, many operations require kernel calling, with low efficiency. To perform fast and low-consumption operations, a pure user thread is required, and the thread library is fully built in the user space. As a result, we can see that a process P generally contains several user processes. User processes correspond to lightweight processes in a certain relationship, while lightweight processes are the advanced embodiment of kernel threads. As a result, a kernel thread blocking will also cause LWP to be blocked, and the user thread connected to LWP will also be blocked.

Figure 2-5-1-5

Finally, let's talk about the relationship between Java threads and underlying operating systems. Because Java encapsulates the differences between underlying operating systems through JVM, therefore, Java Threads must encapsulate different operating systems to provide a unified definition of concurrency. In the history of JDK development, java developers once called Green Threads) "User threads to implement Java threads, but since jdk1.2, java threads are implemented using the native thread model of the operating system. That is to say, the implementation of Java threads is implemented separately through the thread libraries provided by different operating systems, JVM maps Java threads Based on thread models of different operating systems. If Java runs on windows, it usually uses Win32 API to implement multithreading, if Java runs in linux, The Pthread thread library is directly used to implement multithreading. In this way, the underlying implementation details are smoothly hidden and provided to developers is a thread semantics with unified abstraction.