Java 中调度线程无法运行的原因是什么?
我开发了一个小型 Java 应用程序,它通过计划执行器服务运行两个计划线程。在大多数计算机上,我的应用程序运行得很好。然而,在测试中,我遇到了一台计算机,其中我的线程运行频率不高,或者根本不运行。我有一个线程计划以 250 毫秒的间隔运行。它只是检查 std 上是否有任何内容可以读取,如果有则读取并执行命令。该线程偶尔运行,但从未达到应有的频率。我的另一个线程每 5 秒运行一次,并简单地在屏幕上打印一些内容。它运行一次,然后就不会再运行了。这是我正在使用的代码:
scheduledThreadManager.scheduleWithFixedDelay(new Runnable()
{
@Override
public void run()
{
try
{
if(inputReader.ready())
{
String command = inputReader.readLine();
executeCommand(command);
}
}
catch(IOException e)
{
System.out.println(e.toString());
e.printStackTrace();
}
}
}, 250, 250, TimeUnit.MILLISECONDS);
scheduledThreadManager.scheduleWithFixedDelay(new Runnable()
{
@Override
public void run()
{
System.out.println(idleString);
}
}, 0, 5000, TimeUnit.MILLISECONDS);
我已确保我的应用程序在执行计划线程期间不会挂起。该计算机配备了 Core2Duo 处理器,因此我不知道该硬件如何无法满足我的需求,但也许事实并非如此。另一件有趣的事情是,除了这些线程之外,我还运行一个主应用程序线程,并且它运行正常。任何有关此问题原因的输入将不胜感激。
I have developed a small Java application that runs two scheduled threads via a scheduled executor service. On most computers my application runs just fine. In testing however I have come across a computer where my threads are not running as often as they should or not at all. I have one thread scheduled to run on 250 ms intervals. It simply checks to see if there is anything to read on std in, if there is it reads it and executes a command. This thread runs sporadically but never as often as it should. My other thread runs every 5 seconds and simply prints something to the screen. It runs once and then never gets ran again. Here is the code I am using:
scheduledThreadManager.scheduleWithFixedDelay(new Runnable()
{
@Override
public void run()
{
try
{
if(inputReader.ready())
{
String command = inputReader.readLine();
executeCommand(command);
}
}
catch(IOException e)
{
System.out.println(e.toString());
e.printStackTrace();
}
}
}, 250, 250, TimeUnit.MILLISECONDS);
scheduledThreadManager.scheduleWithFixedDelay(new Runnable()
{
@Override
public void run()
{
System.out.println(idleString);
}
}, 0, 5000, TimeUnit.MILLISECONDS);
I have made sure that my app is not hanging during execution of the scheduled threads. The computer has a Core2Duo processor in it so I can't see how the hardware would not be able to meet my needs, but perhaps that is not so. The other interesting thing is that I am running a main application thread in addition to these and it is running correctly. Any input into what the cause of this problem is would be greatly appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您说“我安排了一个线程以 250 毫秒的间隔运行”,但这不是您对其进行编程的目的。您使用了
scheduleWithFixedDelay
,这意味着“在一次执行结束和下一次执行开始之间留出 250 毫秒”。因此,如果您的任务执行时间为 100 毫秒,那么两次执行之间的间隔将是 350 毫秒,如果您的任务的执行时间变化很大,那么执行它的时间间隔也会变化。看一下
scheduleAtFixedRate
相反,它具有“每 X 毫秒运行一次”语义,并且可能更符合您的需要:scheduleAtFixedRate
的一大危险是,如果配置错误,或者任务执行时间过长,您的任务最终可能会重叠。You said " I have one thread scheduled to run on 250 ms intervals", but that's not what you've programmed it to do. You used
scheduleWithFixedDelay
, and that means "leave 250ms between the end of one execution, and the start of the next". So if your task takes 100ms to execute, then it'll be 350ms between executions, and if your task's execution time varies a lot, then so will the intervals at which it gets executed.Have a look at
scheduleAtFixedRate
instead, that has "run every X millis" semantics, and may be more what you need:The big danger with
scheduleAtFixedRate
is that your tasks can end up overlapping, if you configure it wrong, or your tasks take too long to execute.我认为您可以通过两种方法解决该问题:
设置探查器并观察应用程序随时间的进展,直至其挂起。
如果应用程序挂起,请使用kill -3 (Linux) 或CTRL-BREAK (Windows) 获取线程转储,这将使您更深入地了解正在发生的情况。然而,它们并不是最容易阅读的东西。请参阅:
http://www.0xcafefeed.com /2004/06/of-thread-dumps-and-stack-traces/
There are two ways I think you can approach the problem:
Setup a profiler and watch the applications progress over time until it hangs.
If the application is hung then use kill -3 (Linux) or CTRL-BREAK (Windows) to obtain a thread dump which will give you some more insight into what's going on. They're not the easiest things to read however. See:
http://www.0xcafefeed.com/2004/06/of-thread-dumps-and-stack-traces/