我们是无法具体决定哪个现在来运行,优先级高只是意味着它得到的CPU的时间段多一些,并不代表它能优先运行。

解决方案 »

  1.   

    呵呵,你还是不要指望线程的优先级可以发挥作用的了,以下内容摘自IBM的一个java专家的一篇文档,而且现在有很多关于多线程的优先级的讨论。
    文章的标题是Dispelling Java programming language myths Myth 5: Waiting threads are awakened in priority order
    When writing multithreaded code, often the situation arises where you have more than one thread waiting on an event. This occurs when more than one thread calls wait inside a synchronized method or block that is locked on the same object. Waiting threads are awakened when another thread calls notify or notifyAll from within a synchronized method or block that is locked on the same object. The notify call wakes up only one thread. Therefore, if more than one thread is waiting, there will be no contention for the lock. The notifyAll call, on the other hand, wakes up all waiting threads to compete for the lock. However, only one thread will get the lock; the others will block. When multiple threads are waiting, the question is which thread runs after a call to notify or notifyAll? Many programmers incorrectly assume that there is a predefined order to how threads are awakened. Some think that the highest priority thread is awakened first, while others might think it is the thread that has been waiting the longest. Unfortunately, neither assumption is true. In these situations, the thread that is awakened is undefined. It might be the thread with the highest priority or the thread that has been waiting the longest, but there is no guarantee that it will be. The priority of a thread does not determine whether it is notified (in the case of using the notify method) or in what order multiple threads are notified (in the case of using the notifyAll method). Therefore, you should never make assumptions about the order in which threads are awakened as a result of calls to these methods. In addition, you should never make assumptions about the scheduling of a thread during preemption. Thread scheduling is implementation-dependent and varies by platform. It is unwise to make this type of assumption if your code is to be portable. In addition, the notifyAll method, like the notify method, does not provide a way to specify the order in which waiting threads are notified. The order depends on the Java virtual machine, and no guarantees are made beyond the fact that all waiting threads are awakened. This behavior presents a problem when you need to notify multiple threads in a particular order. There are two ways to achieve a controlled order of awakened threads: Use the specific notification pattern 
    Use a VM implemented with the Real-Time Specification for Java (RTSJ) 
    Specific notification pattern
    This pattern, developed by Tom Cargill, specifies how you can control the order of threads to be awakened from a call to notify and notifyAll. This is accomplished through a separate lock object for each thread, or set of threads, that needs to be notified together. This enables notification to happen in a defined order to a specific lock object and thus to its associated thread or threads. The execution overhead of this pattern is minimal if implemented properly. There is, however, some added code complexity. This added complexity can be displaced with the additional control this pattern gives you. You should consider implementing this pattern if you have the need to control the notification order of multiple threads. RTSJ
    The RTSJ changes the standard behavior of certain Java semantics. One of these semantics is ensuring that waiting threads are queued in priority order. Therefore, when one or more threads are waiting and a call is made to notify or notifyAll, the thread with the highest priority executes first. The others must wait.Generally, it is not recommended to use a real-time implementation for anything but real-time programs. There are various trade-offs that are made to enable the Java programming language for real-time programming. One overriding principle in the creation of the RTSJ is that timeliness takes precedence over execution speed. 
      

  2.   

    优先级应该在线程队列中表现出来,java的线程有10个优先级别,深入线程生命周期一书有很好的讨论。
      

  3.   

    就像我刚才贴的那篇文章那样,实际上为了更好的可移植性,你不能依赖线程优先级完成线程间的调度,每个JVM的实现都是不同的,而且线程调度是和平台相关的,因此在你一个平台下可以比较正常使用的优先级设置到另外一个平台或者JVM下可能根本就没有任何作用!!!!
      

  4.   

    很难作到这一点,线程的优先级不是能通过程序来完全控制它,而由操作系统来完全一大半(java定的线程优先级有10个,但其它的有10个吗?单这一点就有很不可预测的东西)。
    用其它的办法来实现你的要求吧。
      

  5.   

    非常感谢各位的回答,看来java对线程的优先级处理是很不可预测的东西。
    可是java总因该和平台的操作系统调度挂勾吧,jvm不会把将要运行的线程放入操作系统的就绪队列吗,而实时强占方式会使就绪队列的线程优先级提高,当高于正在运行的线程时,会讲它阻塞并放入就绪队列!!
    这些都因该是操作系统所做的呀??
      

  6.   

    去看看关于java的书,譬如:java in thinking! 等。
      关于线程的见解蛮多的!!
      

  7.   

    可不可以在线程A,B中定义一个整形的变量temp,当A线程运行时,temp会增加,当达到一定的高度时,调用sleep(),这样A线程就会wait,而系统会转而执行B线程。B线程运行也和A一样!
    请问这样行吗?