Java线程-CPU使用率
这是我现在正在读的一本教科书中的一句话:
“也就是说,每当一个线程需要 执行一个包含很多的循环 迭代,这是一个很好的做法 每次迭代中的 sleep() - 事件较短的睡眠时间,例如 5 毫秒,可以减少总体 应用程序的CPU使用率来自 100%至> 1%”
我相信这是一个很好的做法,但是;调度程序不正是这样做的 - 需要一点时间线程1;暂停线程1;需要一点时间thread2...等等我无法掌握这样的掉落率,有人愿意启发我吗?
Here is a quote from a textbook I'm reading at the moment:
"That is, whenever a thread needs to
execute a loop with a lot of
iterations, it is good practice to put
a sleep() in each iteration
- Event short sleep times, such as 5 milliseconds, can reduce the overall
CPU usage of the application from
100% to > 1%"
It's a good practice, I believe, but; doesn't scheduler does exactly that - A bit of time to thread1; suspend thread1; A bit of time to thread2...etc. I can't grasp such drop rate, anyone willing to enlighten me?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
在更新某些内容的显示的程序中,您经常会看到这种情况。这就是所谓的“忙等待”,这很糟糕。
如果你有一个循环执行类似的操作,
那么当你确实不需要时,你就会耗尽你的 CPU。您是否需要每秒渲染 100000 多次?不,您实际上每秒只需要大约 30 帧。
这会将您的帧率限制在每秒 100 帧以下,最终您将获得更好的性能。
您并不总是希望将其用于处理器密集型后台线程,因为您希望它们具有优先级。话虽这么说,如果你的后台占用了所有 CPU,你将如何处理进一步的输入(比如,我不知道,取消按钮,因为你并不想开始那个密集的、长达数小时的计算?)
所以添加一个对你的线程进行短暂的睡眠可能是一个非常好的决定。
You see this a lot in programs that update the display of something. It's called Busy Waiting, and that's bad.
If you have a loop that does something like this
You're going to chew up your CPU when you really don't need to. Do you need to render it, over and over and over, 100000+ times a second? No, you really only need about 30 frames a second.
This will limit you to a little under 100 frames per second, and you'll end up with a much better performance.
You don't always want this for processor intensive background threads, as you want them to have priority. That being said, if your background takes all the CPU, how will you process further input (like, I don't know, a CANCEL button because you didn't mean to start that intensive, hours-long calculation?)
So adding a small sleep to your threads CAN BE a very good decision.
当您的程序执行数字运算(或其他 CPU 密集型任务)时,您希望它以 100% 的速度运行,不是吗?
OTOH,如果您的程序正在等待输入,那么您应该尽可能使用异步编程,而不是在循环中无休止地运行(异步=系统调用您)。
When your program does number-crunching (or other cpu intensive tasks) you want it to run at 100%, don't you?
OTOH, if your program is waiting for input, then you should use asynchronous programming as much as possible and not run endlessly in a loop (asynchronous = system calls you).
调度程序就是这样做的。
不同之处在于调度程序正确地执行了此操作。这意味着它将有效地使用 CPU,这就是为什么您会获得良好的 CPU 使用率。
我不认为这有什么不好。这只是意味着它正在工作。
当你让它休眠时,会有更多的空闲时间,并且你会减少 CPU 使用率。如果出于某种原因这是你的目标。
CPU 使用率高并没有什么害处(除非出现过热的情况,在这种情况下会出现硬件问题)。
通常,当我处理多线程问题时,我实际上的目标是高 CPU 使用率。这通常意味着问题在线程之间平均分配,并且我从 CPU 中获得最大收益。
如果你使用了 1% 的 CPU 就意味着它无法工作,那么为什么要拥有这么好的计算机呢?您应该充分利用硬件。
The scheduler does just that.
The difference is that the scheduler does it properly. Meaning that it will use the CPU efficiently, and that's why you'll get a good CPU usage.
I don't see anything bad about it. It just means it's working.
When you let it sleep there will be more idle time, and you'll reduce CPU usage. If that is you goal for some reason.
High CPU usage isn't harmful (unless you get over-heating in which case you have a hardware problem).
Usually when I approach multi-threading problems I actually aim for a high CPU usage. This usually means that the problem is divided evenly between the threads and I'm getting the maximum from the CPU.
If you're using 1% of the CPU it means it's not working, so why have such a good computer ? You should take advantage of the hardware.
忘了它。将 CPU 使用率限制在 1% 会给您带来什么? 什么都没有?
将 CPU 使用率限制为 100 倍通常意味着应用程序的速度会减慢 100 倍。
如果还有其他更重要的线程,或者您可能想使用 Thread.interrupt() 停止该线程,您可能需要它,但两者都可以通过其他方式实现。
Forget it. What does limiting the CPU usage to 1% buy you? Nothing at all?
Limiting the CPU usage by a factor of 100 means in general slowing down the app by the factor.
You may want it in case there are other more important threads or in case you may want to stop this thread using
Thread.interrupt()
, but both can be achieved otherwise.我从未听说过这种做法,但它可能会导致 CPU 使用率大幅下降。这是因为调度程序为每个线程提供的时间“位”非常小,因此与此相比,5 毫秒是相当大的时间量。
话虽如此,我认为您可以从线程减慢中受益:单核机器上的响应能力。
I have never heard of such practise, however it would probably result in huge drop in CPU usage. This is because the "bits" of time that scheduler gives for every threads are very small, so that 5ms is considerable amount of time comparing to that.
With that said, I see one place you could benefit from such slowing down of your thread: responsiveness on single-core machines.