關於執行緒的講解(出自Java原著)(轉)

關於執行緒的講解(出自Java原著)(轉)[@more@]Thread Scheduling

In Java technology,threads are usually preemptive,but not necessarily Time-sliced(the process of giving each thread an equal amount of CPU time).It is common mistake to believe that "preemptive" is a fancy word for "does time-slicing".

For the runtime on a Solaris Operating Environment platform,Java technology does not preempt threads of the same priority.However,the runtime on Microsoft Windows platforms uses time-slicing,so it preempts threads of the same priority and even threads of higher priority.Preemption is not guaranteed;however,most JVM implementations result in behavior that appears to be strictly preemptive.Across JVM implementations,there is no absolute guarantee of preemption or time-slicing.The only guarantees lie in the coder’s use of wait and sleep.

The model of a preemptive scheduler is that many threads might be runnable,but only one thread is actually running.This thread continues to run until it ceases to be runnable or another thread of higher priority becomes runnable.In the latter case,the lower priority thread is preempted by the thread of higher priority,which gets a chance to run instead.

A thread might cease to runnable (that is,because blocked) for a variety of reasons.The thread’s code can execute a Thread.sleep() call,deliberately asking the thread to pause for a fixed period of time.The thread might have to wait to access a resource and cannot continue until that resource become available.

All thread that are runnable are kept in pools according to priority.When a blocked thread becomes runnable,it is placed back into the appropriate runnable pool.Threads from the highest priority nonempty pool are given CPU time.

The last sentence is worded loosed because:
(1) In most JVM implementations,priorities seem to work in a preemptive manner,although there is no guarantee that priorities have any meaning at all;
(2) Microsoft Window’s values affect thread behavior so that it is possible that a Java Priority 4 thread might be running,in spite of the fact that a runnable Java Priority 5 thread is waiting for the CPU.
In reality,many JVMs implement pool as queues,but this is not guaranteed hehavior.

執行緒排程（試翻譯，歡迎指正）
在java技術中，執行緒通常是搶佔式的而不需要時間片分配程式（分配給每個執行緒相等的cpu時間的程式）。一個經常犯的錯誤是認為“搶佔”就是“分配時間片”。
在Solaris平臺上的執行環境中，相同優先順序的執行緒不能相互搶佔對方的cpu時間。但是，在使用時間片的windows平臺執行環境中，可以搶佔相同甚至更高優先順序的執行緒的cpu時間。搶佔並不是絕對的，可是大多數的JVM的實現結果在行為上表現出了嚴格的搶佔。縱觀JVM的實現，並沒有絕對的搶佔或是時間片，而是依賴於編碼者對wait和sleep這兩個方法的使用。
搶佔式排程模型就是許多執行緒屬於可以執行狀態（等待狀態），但實際上只有一個執行緒在執行。該執行緒一直執行到它終止進入可執行狀態（等待狀態）或是另一個具有更高優先順序的執行緒變成可執行狀態。在後一種情況下，底優先順序的執行緒被高優先順序的執行緒搶佔，高優先順序的執行緒獲得執行的機會。
執行緒可以因為各種各樣的原因終止並進入可執行狀態（因為堵塞）。例如，執行緒的程式碼可以在適當時候執行Thread.sleep()方法，故意讓執行緒中止；執行緒可能為了訪問資源而不得不等待直到該資源可用為止。
所有可執行的執行緒根據優先順序保持在不同的池中。一旦被堵塞的執行緒進入可執行狀態，它將會被放回適當的可執行池中。非空最高優先順序的池中的執行緒將獲得cpu時間。
最後一個句子是不精確的，因為：
（1）在大多數的JVM實現中，雖然不能保證說優先順序有任何意義，但優先順序看起來象是用搶佔方式工作。
（2）微軟windows的評價影響執行緒的行為，以至儘管一個處於可執行狀態的優先順序為5的java執行緒正在等待cpu時間，但是一個優先順序為4的java執行緒卻可能正在執行。
實際上，許多JVM用佇列來實現池，但沒有保證行為。