Thread.sleep(0)的写法原理深入解析

　　// Begin the process of bringing the system to a safepoint.

　　// Java threads can be in several different states and are

　　// stopped by different mechanisms:

　　//

　　// 1. Running interpreted

　　// The interpeter dispatch table is changed to force it to

　　// check for a safepoint condition between bytecodes.

　　// 2. Running in native code

　　// When returning from the native code, a Java thread must check

　　// the safepoint _state to see if we must block. If the

　　// VM thread sees a Java thread in native, it does

　　// not wait for this thread to block. The order of the memory

　　// writes and reads of both the safepoint state and the Java

　　// threads state is critical. In order to guarantee that the

　　// memory writes are serialized with respect to each other,

　　// the VM thread issues a memory barrier instruction

　　// (on MP systems). In order to avoid the overhead of issuing

　　// a memory barrier for each Java thread making native calls, each Java

　　// thread performs a write to a single memory page after changing

　　// the thread state. The VM thread performs a sequence of

　　// mprotect OS calls which forces all previous writes from all

　　// Java threads to be serialized. This is done in the

　　// os::serialize_thread_states() call. This has proven to be

　　// much more efficient than executing a membar instruction

　　// on every call to native code.

　　// 3. Running compiled Code

　　// Compiled code reads a global (Safepoint Polling) page that

　　// is set to fault if we are trying to get to a safepoint.

　　// 4. Blocked

　　// A thread which is blocked will not be allowed to return from the

　　// block condition until the safepoint operation is complete.

　　// 5. In VM or Transitioning between states

　　// If a Java thread is currently running in the VM or transitioning

　　// between states, the safepointing code will wait for the thread to

　　// block itself when it attempts transitions to a new state.