线程的并发性
下一个与OS平台相关的问题（这也是编写与平台无关的Java程序要面对的问题）是必须确定并发性和并行在该平台的定义。并发的多线程系统总会给人多个任务同时运行的感觉，其实这些任务是被分割为许多的块交错在一起执行的。在一个并行的系统中，两个任务实际上是同时（这里的同时是真正的同时，而不是快速交错执行所产生的并行假象）运行的，这就要求有多个CPU。如图1.1：
图1.1 Concurrency vs Parallelism
多线程其实并不能加快的程序速度。如果你的程序并不需要频繁的等待IO操作完成，那么多线程程序还会比单线程程序更慢些。但在多CPU系统下则反之。
Java线程系统非平台独立的主要原因就是要实现彻底的平行运行的线程，如果不使用OS提供的系统线程模型，是不可能的。对于JAVA而言，在理论上，允许由JVM来模仿整个线程系统，从而避免我在前一篇文章(驯服JAVA线程2)中，所提到的进入OS核心的时间消耗。但是，这样也排除了程序中的并行性，因为如果不使用任何操作系统级的线程（这样是为了保持平台独立性），OS会把JVM的实例当成一个单线程的程序来看待，也就只会分配单个CPU来执行它，从而导致就算运行在多CPU的机器上，而且只有一个JVM实例在单独运行，也不可能出现两个Java线程真正的并行运行（充分的利用两个CPU）。
所以，要真正的实现并行运行，只有存在两个JVM实例，分别运行不同的程序。做的再好一点就是让JVM把Java的线程映射到OS级的线程上去（一个Java线程就是一个系统的线程，让系统进行调配，充分发挥系统对资源的操控能力，这样就不存在只能在一个CPU上运行的问题了）。不幸的是，不同的操作系统实现的线程机制也不同，而且这些区别已经到了在编程时不能忽视的地步了。
由于平台不同而导致的问题
下面，我将会通过比较Solaris和WindowsNT对线程机制实现不同之处，来说明前面提到的问题。
Java，在理论上，至少有10个线程优先等级划分（如果有两个或两个以上的线程都处在on ready状态下，那么拥有高优先级的线程将会先执行）。在Solaris里，支持231个优先等级，当然对于支持Java那10个的等级是没问题的。
在NT下，最多只有7优先级划分，却必须映射到Java的10个等级。这就会出现很多的可能性（可能Java里面的优先级1、2就等同于NT里的优先级1，优先级8、9、10则等于NT里的7级，还有很多的可能性）。因此，在NT下依靠优先级来调度线程时存在很多问题。
更不幸的还在后面呢！NT下的线程优先级竟然还不是固定的！这就更加复杂了！NT提供了一个名叫优先级助推（Priority Boosting）的机制。这个机制使程序员可以通过调用一个C语言的系统Call（Windows NT/2000/XP: You can disable the priority-boosting feature by calling the SetProcessPriorityBoost or SetThreadPriorityBoost function. To determine whether this feature has been disabled, call the GetProcessPriorityBoost or GetThreadPriorityBoost function.）来改变线程优先级，但Java不能这样做。当打开了Priority Boosting功能的时候，NT依据线程每次执行I/O相关的系统调用的大概时间来提高该线程的优先级。在实践中，这意味着一个线程的优先级可能高过你的想象，因为这个线程碰巧在一个繁忙的时刻进行了一次I/O操作。线程优先级助推机制的目的是为了防止一个后台进程（或线程）影响了前台的UI显示进程。其它的操作系统同样有着复杂的算法来降低后台进程的优先级。这个机制的一个严重的副作用就是使我们无法通过优先级来判断即将运行的就绪太线程。
在这种情况下，事态往往会变得更糟。
