当前位置: 技术问答>java相关
请教线程之间通过优先级的高低来判断由哪个线程来执行！
来源: 互联网 发布时间：2015-06-23
本文导语: 有2个现成A,B，在A执行的时候该如何来判断B的优先级呢，假设B的优先级是随着等待时间 增加和变高的。 请帮我讲讲工作原理，有源代码最好了。 十分感激！ | 呵呵，你还是不要指望线程的优先级可以...
有2个现成A,B，在A执行的时候该如何来判断B的优先级呢，假设B的优先级是随着等待时间
增加和变高的。
请帮我讲讲工作原理，有源代码最好了。
十分感激！
增加和变高的。
请帮我讲讲工作原理，有源代码最好了。
十分感激！
|
呵呵，你还是不要指望线程的优先级可以发挥作用的了，以下内容摘自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.
文章的标题是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.
|
得到线程的优先级很容易，有方法。但是不能指望优先级在多大程度上能用于控制逻辑。因为优先级的高低只代表一个概率，如果把所有的优先级比作一个靶的话，那么优先极高的就是外圈，低的是内圈。你仅仅是击中外圈的机会大点而已。你不能规定自己首先集中哪个。是这样吧，欢迎大家指正，免得误了人家，呵呵。
|
我们是无法具体决定哪个现在来运行，优先级高只是意味着它得到的CPU的时间段多一些，并不代表它能优先运行。
|
优先级应该在线程队列中表现出来，java的线程有10个优先级别，深入线程生命周期一书有很好的讨论。
|
就像我刚才贴的那篇文章那样，实际上为了更好的可移植性，你不能依赖线程优先级完成线程间的调度，每个JVM的实现都是不同的，而且线程调度是和平台相关的，因此在你一个平台下可以比较正常使用的优先级设置到另外一个平台或者JVM下可能根本就没有任何作用！！！！
|
很难作到这一点，线程的优先级不是能通过程序来完全控制它，而由操作系统来完全一大半(java定的线程优先级有10个，但其它的有10个吗？单这一点就有很不可预测的东西)。
用其它的办法来实现你的要求吧。
用其它的办法来实现你的要求吧。
|
那要看具体的平台的调度了
|
要看虚拟机和平台的调度，我们无法控制。
|
去看看关于java的书,譬如:java in thinking! 等。
关于线程的见解蛮多的！！
关于线程的见解蛮多的！！
|
up!关注！
您可能感兴趣的文章:
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术，将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外，均为转载、整理或搜集自网络。欢迎任何形式的转载，转载请注明出处。
本站(WWW.)站内文章除注明原创外，均为转载、整理或搜集自网络。欢迎任何形式的转载，转载请注明出处。