What is Java thread priority? 什么是java线程优先级

就一个小程序，运行一次输出结果不一样，这是因为线程调度方法不能确定，取决你当前操作系统的进程，线程调度优先级。
所以要想线程按一定的顺序运行，哪么只能选择Synchronized 互斥（对象锁）和 wait notify合作关系了。
一、概念
1、干活线程建立时是以排队的顺序，排在前面的干活线程先执行，
       同时也给了一个默认的优先级 5。
2、sleep(100) :可以暂停当前干活线程的执行，从就绪队列另取一个干活线程去cpu执行。
      是不是一定按照排队的顺序取一个干活线程呢！不一定，还取决你使用的操作系统。
3、Thread.yield():只是给线程调度者出主意的人,你可以叫别的干活线程干活了,这是最佳转换时间。    
         调度程序：有决定权，叫不叫别的干活线程干活不一定。
         Thread.yield():唯一 的好处是 确保a context switch  发生。
            Context Switch：操作系统切换任务，先前一个任务的Context都被保持下来，新任务的Context会被装载进来
4、调度程序改默认优先级5，把特急的设置成高优先级10，目前就三种优先级，如果改的话，只能改成最低，最高。 
    按道理高优先级的线程会先执行，但是还是不一定，有时低优先级也开始运行。
    public final static int MIN_PRIORITY = 1; //最低优先级
    public final static int NORM_PRIORITY = 5;//干活线程建立默认优先级
    public final static int MAX_PRIORITY = 10;//hhhh
  所以对于设置优先级，只是本地记号，一切由操作系统决定。
二、影响线程优先级是否有效的几个因素：
      http://www.javamex.com/tutorials/threads/priority.shtml        CPU distribution:像我们平时有一个大蛋糕，调度者每个人分一块，这就是分配。
 Priority优先级：执行顺序从高到低

 setPriority(),我们想当然，优先级高的线程先执行，低的后执行，但是有可能和我想法不一样，理由：
 1、由于我们的 OS and VM 版本不同, Thread.setPriority() 也许什么也不做;
  2、在UNIX 系统中，表示分配。
 3、线程优先级是由 "global" and "local" priority settings 构成。
      Java's setPriority() 方法工作在 local priority 。
      理由：你当前软件设置的优先级不能直接影响系统的其它软件吧！
          你通常不想，鼠标点击线程或处理音频数据被随机用户线程取代吧!
          当我们正在看一个好看的电影时，随便一个小软件运行，这时电影停下，让小软件执行，哈哈，我们会被气死。
 4、java 有1--10个优先级，不同的操作系统也许有，也许没有，看操作系统说明书。
 5、当一些低优先级的线程长时间得不到运行，操作系统给一个临时优先级boost(加速)，低优先级线程占用cpu.
 6、大多数操作系统的线程调度者有时对线程优先级执行临时的操作。
      例如：当一个线程接收一个事件或它正在等待一个i/o，不用时可以在任务管理自己手动调整优先级最低。             
 7、
      1》你的应用通常不知道其他进程正在运行的是什么线程，因此改变一个线程的优先级对整个系统的影响也许不可预测。
      2》例如，你也许发现，你设计在“后台运行的低优先级线程”几乎根本不运行，这是因为杀毒软件线程的优先级稍微高些（但仍然低于正
常），并且杀毒软件不同，占用内存和消耗cpu这些性能也不同。
 8、我们自己可以在“任务管理器”任意调整每一进程的优先级，如果不太重要的进程设置成“低”，哪么其它的程序速度会大幅提高。
      一个进程的优先级发生变化，里面所有的线程的优先级发生了变化。
     

    

所以，上面的影响总是存在，但是自己小软件设置优先级也是必要的。
   比如：学校的班级排名和全年级排名。
三、转载 http://www.javamex.com/tutorials/threads/priority_what.shtml
     What is Java thread priority?In our introduction to thread priority, we pointed out some problems with the system, notably differences between what priority actually means on different systems. Here, we'll look at how thread priority is actually implemented in Windows and Linux.1、Windows priorities 和 java优先级对应表。 In the Hotspot VM for Windows, setPriority() map to Windows relative priorities (set by the SetThreadPriority() API call). The actual mappings were changed between Java 5 and Java 6 as follows:

Java to Windows priority mappings

Java Priority	Windows Priority (Java 5)	Windows Priority (Java 6)
1	THREAD_PRIORITY_LOWEST
2
3	THREAD_PRIORITY_BELOW_NORMAL
4
5	THREAD_PRIORITY_NORMAL	THREAD_PRIORITY_NORMAL
6	THREAD_PRIORITY_ABOVE_NORMAL
7	THREAD_PRIORITY_ABOVE_NORMAL
8	THREAD_PRIORITY_HIGHEST
9	THREAD_PRIORITY_HIGHEST
10	THREAD_PRIORITY_TIME_CRITICAL

THREAD_PRIORITY_TIME_CRITICAL：最高优先级了。

In effect, the priority mappings were 'shifted down' to avoid THREAD_PRIORITY_TIME_CRITICAL, apparently following reports that this setting could affect vital processes such as audio. Note that there is really no such mapping to THREAD_PRIORITY_IDLE as suggested by Oaks & Wong (they were possibly misinterpreting a dummy value that appears at the beginning of the priority mapping table in the VM source code).
On Windows, thread priority is a key element in deciding which thread gets scheduled, although the overall priority of a thread is a combination of the process's priority class, the thread's relative priority (values from the table above), plus any temporary "boost" given in specific circumstances (such as on returning from a wait on I/O). But in general:
在Windows，线程优先级是决定哪一个线程调度的关键部分，进程的优先级类构成全部线程的优先级，
Windows线程的优先级：上面表给出的线程+临时加速的线程
boost：加速

低优先级线程必须在所有高优先级线程处于waiting状态，才有机会占有cpu。
Lower-priority threads are given CPU when all higher priority threads are waiting (or otherwise unable to run) at that given moment.The actual proprtion of CPU allotted to a thread therefore depends on how often that situation occurs— there's no relation per se（本身） between priority and CPU allocation.
实际上分配一个线程占有cpu的比例，取决于这种情况的多久发生一次，线程的优先级和cpu的分配本身无联系，对，unix 就是这样
例如：下图10个线程同时执行，60s内，10个线程各占有cpu多少时间,占的时间/60s=一个线程占有的比例，
      而9，10线程明显占有很大的比例，明显还是和线程的优先级有关，是的，因为下面是window 系统。
 Now of course, if this was literally the be-all and end-all to thread scheduling, then there'd quite possibly be lower-priority threads that barely got any CPU at all, being continually starved by higher-priority threads that needed CPU.
非常有可能低优先级线程根本得不到cpu执行，当高优先级线程继续占用cpu时，会饿死低优先级线程。

 So Windows has a fallback mechanism, whereby a thread that hasn't run for a long time is given a temporary priority boost.
这种情况的解决办法：就是长时间没有执行的线程给一个临时优先级boost(加速)，占用cpu.
 (For more details about some of the points mentioned here, see the section on thread scheduling.)
What this generally means is that on Windows:当所有线程竞争cpu时，线程的优先级并没有什么意义。
Thread priority isn't very meaningful when all threads are competing for CPU.As an illustration, Figure 1 opposite shows the results of an experiment in which ten threads are run concurrently, one thread with each Java priority. 
图1例子：横坐标（线程优先级1--10），纵坐标就是产生的数字。
  规定：10个线程同时运行，60s后全部结束，查看每一线程产生了多少个数字，这些数字被看作这个线程占用cpu的时间。
  测试结果 ：线程优先级1-8 差不多占用cpu的时间是一样的。9,10 分配线程占用大部分cpu时间。      
                   主要原因就是THREAD_PRIORITY_HIGHEST 有最高优先级。  
  测试环境： Java 6 Update 10. Vista 双核，重复实验多次，图形是一样的。

                linux 图形不一样。
Each thread sits in a CPU-intensive（cpu一直处于计算中） loop (continually a 
 random number using a XOR Shift异或移位 generator). Each thread keeps a count of how many numbers it has generated1. After a certain period (60 seconds in this case), all threads are told to stop and queried to find out how many numbers they generated; the number generated is taken as an indication of the CPU time allocated to that thread2. As can be seen, thread priorities 1-8 end up with a practically equal share of the CPU, whilst priorities 9 and 10 get a vastly greater share (though with essentially no difference between 9 and 10). The version tested was Java 6 Update 10. For what it's worth, I repeated the experiment on a dual core machine running Vista, and the shape of the resulting graph is the same. My best guess for the special behaviour of priorities 9 and 10 is that THREAD_PRIORITY_HIGHEST in a foreground window has just enough priority for certain other special treatment by the scheduler to kick in (for example, threads of internal priority 14 and above have their full quantum
 replenished after a wait, whereas lower priorities have them reduced by 1).



Java thread priority to nice value mappings in Linux

Java thread priority	Linux nice value
1	4
2	3
3	2
4	1
5	0
6	-1
7	-2
8	-3
9	-4
10	-5

2、Linux priorities

Under Linux, you have to go through more hoops to get thread priorities to function at all, although in the end, they may be more useful than under Windows. In Linux:
thread priorities only work as of Java 6 onwards;
for them to work, you must be running as root (or with root privileges via setuid);
the JVM parameter -XX:UseThreadPriorities must be included.
The rationale behind requiring root privileges to alter thread priorities largely eludes me. Whether or not Linux itself generally should place such a restriction on changing nice values is arguable, bit since it doesn't, it seems odd to add it to the JVM (as opposed to, say, building in a restriction via the Java SecurityManager). And does anyone really run, say, their web server as root?
Assuming you go through these steps to enable them, Java thread priorities in Hotspot map to nice values. Unlike Windows priorities, Linux nice values are used as a target for CPU allocation (although like Windows, recent versions of Linux— from kernel 2.6.8 onwards— also apply various heuristics to temporarily boost or penalise threads). The mappings from Java priorities to Linux nice values are given in the table opposite. Note that:
nice value means "how nice the thread is to other threads", so a lower number means higher priority;
Java doesn't actually map to the full range (nice values go from -20 to 19), probably to prevent negative impact on system threads.
Figure 2 shows the results of the thread priority experiment repeated under Linux with kernel 2.6.18. The different coloured traces simply represent 3 separate runs of the experiment. The graph shows that there is a correlation between Java priority (nice value) and CPU allocation, although it is far from linear.
四、代码，每次执行结果不一样。

package concurrency; import java.util.concurrent.*; public class SimplePriorities implements Runnable { private int countDown = 5; private volatile double d; // No optimization private int priority; public SimplePriorities(int priority) { this.priority = priority; } public String toString() { return Thread.currentThread() + ": " + countDown; } public void run() { Thread.currentThread().setPriority(priority); while (true) {//当语句执行完，那么让另一个任务执行。 // An expensive, interruptable operation: for (int i = 1; i < 100000; i++) { d += (Math.PI + Math.E) / (double) i; if (i % 1000 == 0) Thread.yield(); } System.out.println(this); if (--countDown == 0) return; } } public static void main(String[] args) { ExecutorService exec = Executors.newCachedThreadPool(); for (int i = 0; i < 5; i++) exec.execute(new SimplePriorities(Thread.MIN_PRIORITY)); exec.execute(new SimplePriorities(Thread.MAX_PRIORITY)); exec.shutdown(); } }