背景信息：Java线程
JVM为Java线程定义了十个逻辑优先级，包括：
java.lang.Thread.MIN_PRIORITY = 1 java.lang.Thread.NORM_PRIORITY = 5 java.lang.Thread.MAX_PRIORITY = 10
传递这些值[1..10]以为Thread.setPriority(int) Java线程分配优先级。Java线程的默认优先级是NORM_PRIORITY。（未明确调用setPriority run的Java线程NORM_PRIORITY。）JVM可以以其选择的任何方式自由实现优先级，包括忽略该值。
Java HotSpot™虚拟机当前将每个Java线程与唯一的本机线程相关联。Java线程和本机线程之间的关系是稳定的，并且在Java线程的生命周期中持续存在。
历史线程优先级实现
在1.4.2之前的版本中，当Java线程调用该Thread.setPriority 方法或创建线程时，HotSpot将调用thr_setprio() Java优先级映射到本机优先级。调用thr_setprio() 对Java线程的执行行为影响很小。该JVM也没有打电话priocntl()来调整基础LWP的优先级。这是一个有意识的设计决策，因为在1.4.2时间范围内，Solaris上唯一可用的libthread是较旧的T1 libthread。
注意： JVM可以通过指定THR_BOUND何时创建线程，强制本机线程以1：1的方式绑定到T1下的LWP 。THR_BOUND但是，由于附加到JVM的线程可能不是THR_BOUND，而原始线程不是，因此是不够的THR_BOUND。鉴于Solaris中没有办法强制线程在创建后被绑定，HotSpot实现者决定在调用Java线程时不谨慎更改LWP优先级。setPriority()
在1.4.2中，HotSpot能够在启动时确定它是在T1还是T2下运行。如果JVM在T1下启动，优先级的影响将与早期版本中的相同。
但是，在T2下，1.4.2将对Thread.setPriority 方法的调用转换为对两者的调用thr_setprio()（以更改本机进程本地优先级）和priocntl()（以更改基础LWP的调度优先级）。JVM priocntl()仅调用在TS（分时共享），IA（交互式）和 RT（实时）调度类中运行的线程。priocntl(2) 有关调度类的说明，请参见Solaris 手册页。如果Java线程不在TS，IA或RT调度类中，则JVM不会尝试设置基础LWP的优先级priocntl()。
不幸的是，TS和IA调度类中的本机线程的默认优先级是可能的最高优先级。Java线程的默认逻辑优先级是NORM_PRIORITYJava线程优先级域的中间位置。当JVM映射NORM_PRIORITY到本机和LWP优先级时，结果是一个小于默认本机优先级的值。假设我们有一个运行JVM的2-CPU系统，而且JVM有两个Java线程，两者都在NORM_PRIORITY。假设线程在IA或TS调度类中，通常就是这种情况。创建Java线程时，JVM调用priocntl()mapNORM_PRIORITY到TS或IA优先频段的中间。此外，假设另一个进程中的2个本机“C”线程与Java线程同时运行/准备就绪。本机C线程和Java线程都受CPU限制和旋转，计算。本机线程将在TS或IA调度类中以最高优先级运行，并且JVM线程将以中优先级运行。由于所有四个线程都在竞争CPU周期，因此本机线程将接收相对更多的CPU周期，并且Java线程在某种意义上将处于不利地位。仅当Java线程与普通线程竞争且系统完全饱和时才会出现此效果。
相反，使用较低相对优先级的好处是在TS和IA调度类中，以较低优先级运行的线程接收较长的量子，假设它没有被准备好的较高优先级线程抢占中量子。较长的量程通常对服务器应用程序中的线程有利，因为来自抢占的上下文切换率降低。一个线程被允许在CPU上运行更长的时间和缓存重载瞬态（线程被安排到CPU之后的一段时间 - 当一个线程因重新填充CPU的数据缓存而导致高缓存未命中率时取代先前线程的数据）在较长的量子上摊销。
JRE 5.0提供与1.4.2相同的优先级映射，除了[10 ... 5]范围内的Java优先级都映射到最高可能的TS或IA优先级，而[1..4]范围内的优先级映射相应地降低本地TS或IA优先级。此更改的优点是Java线程NORM_PRIORITY 现在可以按预期与本机线程竞争。如果Java线程和本机线程都没有明确设置优先级（通常是这种情况），则两个类的线程将在相同的基础上竞争，在TS或IA调度类中以最高优先级运行。
假设Java线程未明确设置其优先级setPriority()，此更改将恢复1.4.2之前使用的Java线程的行为和有效LWP优先级。这种实现的缺点是没有区分5到10的Java优先级。例如，逻辑优先级8的Java线程映射到与优先级为9的Java线程相同的LWP优先级。
杂记
以下声明适用于所有版本的HotSpot：
- JVM永远不会更改LWP的调度类。
- 调用该
Thread.setPriority方法可能是昂贵的操作。轻微的优先级调整可能会降低性能。 - 如果外部线程附加到JVM，则JVM将该线程的优先级设置为
NORM_PRIORITY。反过来，这会更改线程的本机优先级，并可能更改运行本机线程的LWP的优先级。具体来说，如果本机线程调整其优先级然后附加到JVM，则JVM将覆盖该线程的先前优先级设置。如果线程分离，JVM不会“撤消”或恢复本机线程的优先级。
一般调度问题：优先级，让步和监控公平性
这些Thread.setPriority和Thread.yield方法是建议性的。它们构成了从应用程序到JVM的提示。正确编写的，健壮的，与平台无关的代码可以使用setPriority()和yield() 优化应用程序的性能，但不应依赖于这些属性的正确性。同样地，任何假设应作出关于哪些线程被授予监视器或顺序线程响应于所述唤醒的所有权的顺序notify或notifyAll 方法。