java原著中对线程的解释：

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.

热心网友翻译的版本：（来自www.cn-java.com）
 
在java技术中，线程通常是抢占式的而不需要时间片分配进程（分配给每个线程相等的cpu时间的进程）。一个常常犯的错误是认为“抢占”就是“分配时间片”。
在Solaris平台上的运行环境中，一样优先级的线程不能相互抢占对方的cpu时间。但是，在使用时间片的windows平台运行环境中，可以抢占一样甚至更高优先级的线程的cpu时间。抢占并不是绝对的，可是大多数的JVM的实现结果在行为上表现出了严格的抢占。纵观JVM的实现，并没有绝对的抢占或是时间片，而是依靠于编码者对wait和sleep这两个方式的使用。
抢占式调度模型就是许多线程属于可以运行状态（等待状态），但实际上只有一个线程在运行。该线程一直运行到它终止进入可运行状态（等待状态）或是另一个具有更高优先级的线程变成可运行状态。在后一种情况下，底优先级的线程被高优先级的线程抢占，高优先级的线程获得运行的机会。
线程可以因为各种各样的原因终止并进入可运行状态（因为堵塞）。例如，线程的代码可以在适当时候执行Thread.sleep()方式，故意让线程中止；线程可能为了访问资源而不得不等待直到该资源可用为止。
所有可运行的线程根据优先级保持在不同的池中。一旦被堵塞的线程进入可运行状态，它将会被放回适当的可运行池中。非空最高优先级的池中的线程将获得cpu时间。
最后一个句子是不精确的，因为：
（1）在大多数的JVM实现中，虽然不能保证说优先级有任何意义，但优先级看起来象是用抢占方法工作。
（2）微软windows的评价影响线程的行为，以至尽管一个处于可运行状态的优先级为5的java线程正在等待cpu时间，但是一个优先级为4的java线程却可能正在运行。
实际上，许多JVM用队列来实现池，但没有保证行为

越用越糊涂，越学越疑惑..........

从学java到现在，多线程设计一直困扰着我，也许是自己的e文太差，也许是自己天生愚笨，无论原版的e文和网友翻译的中文版，都拜读了无数遍了，而且涉及java多线程的开发也搞了一段时间，然而自己却还不能真正体会线程的深刻含义。“Preemption is not guaranteed;however,most JVM implementations result in behavior that appears to be strictly preemptive”，对于java多线程的抢占和时间片，不能说其为绝对的抢占，然而在JVM中，却表现了严格的抢占。对于目前的多任务操作系统，多线程的设计开发可以说让我体会了从前使用单线程语言无法比拟的交互性能和实时控制性，一度让我为其着迷，然而我一直疑惑的是到底这个多线程对系统的利用如何？linux/unix也好，windows也好，都有其独特的运行机制，而且多线程是否好用呢？真的那么易用？从自己学习java线程以来，犯的错误比自己学c多得多，可能是自己太笨了，无法领悟这么优秀语言的强盛性能。对于同步对象的恒定性和跨类的同步对象，让我确实够头疼的，总是犯些低级错误。

通过用了那么一段时间的java多线程，我还是感觉c++更灵活些，虽然java把多线程嵌入到了语言之中。在《Taming Java Threads 》一书中，对java线程的一些缺陷进行了分析，看了后，我认为对于一种面向对象的语言来说，多线程的设计的确难以满意面向对象。别的不说，无非就是个run()方式，呵呵.....学艺不精，是自己活该倒霉，不能怪别人。不过，java能使用wait(),notify()等机制来控制线程，对我们这些脑子不好使得人可是大大的恩赐阿。