关于I / O线程的Java调度机制

Question

From this answer , I understand that when java threads wait for I/O, they're in the RUNNABLE state.

This confuses me, because from what I understood the java scheduler slices CPU resources equally between all the RUNNABLE threads (let's ignore priority for that matter).

To demonstrate what's bugging me, consider that following: My process has 1000 threads. 999 of these are waiting for I/O which will take some time to finish. The one left thread only does CPU calculations.

All these 1000 threads are in the RUNNABLE state, meaning time will be sliced equally between them. This will cause the 1 thread to be given only 0.1% CPU which is absurd (when no other thread actually needs the CPU).

I realize that there's something I miss here, but cannot figure out what it is? Is there an additional mechanism to handle I/O CPU time consumption?

Answer 1

You are confusing Java thread states and OS thread states. They are different, though have some things in common.

JVM tries to map java states onto OS states but it can't do this always properly. For example, when java code calls some native method (IO syscall or any other syscall, JNI, etc), JVM has no knowledge of what thread is actually doing in its native code. So, JVM marks this thread as RUNNABLE until it exits native method. If this native syscall is doing blocking IO and it is actually is blocked (for example, reading from socket), OS will put thread into sleeping state. So, it is OK to have some thread which is RUNNABLE from JVM point of view and is S state (sleeping) from OS point of view.

In Linux, OS thread states may be found out from ps -eLf output. Description of these states is available in ps man page. Mapping between java thread names and native thread ids can be found out by using jstack : convert hex nid field into decimal value and search for it in ps output.

Answer 2

The actual scheduling and time slicing depends on the OS. For eg, for Linux the scheduling uses a heuristic calculation to update dynamic priority of tasks based on their interactivity (I/O bound versus CPU bound). Also there have been additions to the scheduling algorithms in recent versions as detailed in this paper. Another good reading on this topic (in context of Linux OS) is here .