In-depth decryption: the relationship between Java and threads

Concurrency does not have to depend on multi-threading (such as PHP's multi-process concurrency), but talking about concurrency in Java, most of them are inseparable from threads.

Thread implementation

Thread is the basic unit of CPU scheduling. The Thread class is significantly different from most Java APIs. All its key methods are declared as Native, meaning that this method is not used or cannot be implemented using platform-independent means.

Kernel-Lever Thread (KLT)

The threads directly supported by the kernel of the operating system (Kermel, hereinafter referred to as the kernel) are switched by the kernel. The kernel schedules the threads by manipulating the scheduler (Sheduler) and is responsible for mapping the tasks of the threads to each processor.

Each kernel thread can be regarded as an avatar of the kernel, so that the OS has the ability to handle multiple things at the same time, and a kernel that supports multiple threads is called a multi-threaded kernel (Multi-Threads Kernel).

Programs generally do not directly use KLT, and a high-level interface that uses KLT is Light Weight Process (LWP), which is the thread we usually talk about. Since each LWP is supported by a KLT, Therefore, only by supporting KLT first can there be LWP. This 1: 1 relationship is called 一对一的线程模型.

In-depth decryption: the relationship between Java and threads

  • limitation

    Because it is based on KLT, various thread operations, such as creation, destructuring, and synchronization, require system calls. The cost of system calls is relatively high, and you need to switch back and forth between user mode and kernel mode. Secondly, each LWP needs to have a KLT support, so LWP consumes certain kernel resources (such as KLT stack space), so the number of LWPs supported by a system is limited.

User thread

The creation, switching and scheduling of various details all need to be considered, implementation and its difficulties, and has been abandoned by languages ​​such as java and ruby ​​to mix user threads with lightweight processes.

Java thread implementation

User threads are still completely built in user space, so operations such as user thread creation, switching, and destruction are still inexpensive, and can support large-scale user threads. Lightweight processes supported by concurrent operating systems are used as user threads and kernel threads. The bridge between them can use the thread scheduling function and processor mapping provided by the kernel, and the system call of the user thread must be completed by a lightweight thread, which greatly reduces the risk of the entire process being completely blocked.

In this mixed mode, the ratio of the number of user threads to lightweight processes is indefinite, that is, the relationship between N: M. Many UN1X series operating systems, such as Solaris, HP-UX, etc. provide N: M threads Model implementation.

Java thread

Prior to JDK 1.2, it was based on a user thread implementation called "Green-Threads". In JDK 1.2, it was replaced with the operating system's native threading model. Therefore, in the current JDK version, what does the operating system support? The thread model largely determines how the threads of the Java virtual machine are mapped. There is no way to agree on different platforms. The virtual machine specification does not limit which thread model Java threads need to use to achieve .

The threading model only affects the concurrent size and operating costs of threads. These differences are transparent to the coding and running of Java programs.

For Siun JDK, its Windows and Linux versions are implemented using a one-to-one thread model, a Java thread is mapped into a lightweight process, because the thread model provided by Windows and Linux systems is one One-to-one and on the Solaris platform, due to the operating system's threading characteristics can support one-to-one (via Bound

Threaids or Alternate Libthread) and many-to-many (through LWP / Thread Based Synchronization

Implementation) of the thread model, so the Solaris version of the JDK also provides two platform-specific virtual peach parameters:

-XX: + UseLWPSynchronization (default) and -XX: + UseBoyndThreads to explicitly specify which threading model the virtual machine uses.

Java thread scheduling

  • Thread scheduling

    The process of allocating processor usage rights to threads by the system, there are two main scheduling methods

  • Cooperative Threads-Scheduling

  • Preemptive Threads-Scheduling

In a multi-threaded system using cooperative scheduling, the thread execution time is controlled by the thread itself. After the thread executes its work, it must actively notify the system to switch to another thread.

Cooperative multithreading

  • Maximum benefit

    The implementation is simple, and because the thread has to do its own thing before switching the thread, the switching operation is known to the thread, so there is no problem of thread synchronization

  • The disadvantages are also obvious

    Thread execution time is uncontrollable

Using a multi-thread system with preemptive scheduling, then each thread will be allocated execution time by the system, and the switching of threads is not determined by the thread itself. In this way of thread scheduling, the thread execution time of the system-controllable Java thread scheduling The way is preemptive scheduling. Although Java thread scheduling is done automatically by the system, we can still "suggest" that the system allocate more execution time to certain threads, which can be done by setting thread priority. The Java language has set a total of 10 levels of thread priority (Thread.MIN_PRIORITY to Thread.MAX_PRIORITY). When two threads are in the Ready state at the same time, the thread with the higher priority is easier to be selected for execution by the system.

Java threads are implemented by mapping to the system's native threads, so thread scheduling ultimately depends on the OS. Although many OSs now provide the concept of thread priority, it does not necessarily correspond to the priority of Java threads, such as There are 2147483648 (232) priorities in Solaris, but there are only 7 in Windows, which is better than a system with more Java thread priority. It is better to leave a space in the middle, but a system with less thread priority than Java There have to be several situations where the priority is the same, not only that on some platforms different priorities will actually become the same, but there are other situations where we cannot rely too much on priority: priority may be affected by the system Change it yourself.

For example, there is a "Priority Boosting" (Priority Boosting) in the Windows system, of course it can be

Closed) function, its general purpose is that when the system finds that a thread is performing particularly "diligently", it may cross the thread priority to allocate execution time for it. Therefore, we can't use the priority in the program to determine exactly which group of threads with the status of Ready will be executed first.

Guess you like

Origin www.cnblogs.com/CQqfjy/p/12703037.html