的Java应用程序，使屏幕显示10分钟的闲置时间后反应迟钝 [英] Java app makes screen display unresponsive after 10 minutes of user idle time
问题描述
我已经写了Java应用程序，允许用户脚本鼠标/键盘输入（ JMacro ，链接并不重要，只有为好奇）。我个人使用的应用程序在网络游戏，而我睡自动化人物动作过夜。不幸的是，我继续回来到计算机早上找到它反应迟钝。在进一步的测试，我发现我的应用程序会导致约10分钟的用户空闲时间（即使该应用程序本身是模拟用户活动）后，计算机停止响应。我似乎无法以针点问题，所以我希望别人可能有在哪里看或什么可能导致该问题的建议。
I've written a Java app that allows users to script mouse/keyboard input (JMacro, link not important, only for the curious). I personally use the application to automate character actions in an online game overnight while I sleep. Unfortunately, I keep coming back to the computer in the morning to find it unresponsive. Upon further testing, I'm finding that my application causes the computer to become unresponsive after about 10 minutes of user idle time (even if the application itself it simulating user activity). I can't seem to pin-point the issue, so I'm hoping somebody else might have a suggestion of where to look or what might be causing the issue.
相关症状及特点：
- 后，用户空闲10分钟 出现反应迟钝
- 用户仍可以移动鼠标指针在屏幕上
- 一切，但鼠标出现冻结...点击鼠标没有任何效果，也没有应用更新它们的显示，包括Windows 7桌面
- 我离开了任务管理器了沿着与应用程序在一夜之间，所以我可以看到屏幕冻结之前的最后一个任务管理器的图片中的Java应用程序在正常的CPU /内存使用率和CPU使用总量只有约1％
- 移动鼠标后，屏幕上的图像开始30分钟内再次更新（这后两小时十分碰运气......有时候10分钟，有时没有结果（换句话说，用户从闲置回来） ）
- 用户可以CTRL-ALT-DEL去Windows 7的CTRL-ALT-DEL屏幕（后30秒暂停）。用户仍然可以移动鼠标指针，但点击任何按钮选项导致屏幕出现再次冻结
- 在一些非常罕见的情况下，系统永不死机了，我回来在早晨全响应
- 的的Java应用程序会自动停止在半夜输入脚本，因此Windows 7检测真正的懒惰并把显示器进入待机模式......他们成功地走出了在手动移动鼠标在早晨，当我醒来的时候，即使桌面显示仍出现冻结
- Unresponsiveness occurs after user is idle for 10 minutes
- User can still move the mouse pointer around the screen
- Everything but the mouse appears frozen... mouse clicks have no effect and no applications update their displays, including the Windows 7 desktop
- I left the task manager up along the with the app overnight so I could see the last task manager image before the screen freezes... the Java app is at normal CPU/Memory usage and total CPU usage is only ~1%
- After moving the mouse (in other words, the user comes back from being idle), the screen image starts updating again within 30 minutes (this is very hit and miss... sometimes 10 minutes, sometimes no results after two hours)
- User can CTRL-ALT-DEL to get to Windows 7's CTRL-ALT-DEL screen (after a 30 second pause). User is still able to move mouse pointer, but clicking any of the button options causes the screen to appear to freeze again
- On some very rare occasions, the system never freezes, and I come back to it in the morning with full responsiveness
- The Java app automatically stops input scripting in the middle of the night, so Windows 7 detects "real" idleness and turns the monitors into Standby mode... which they successfully come out of upon manually moving the mouse in the morning when I wake up, even though the desktop display still appears frozen
由于症状和问题的特点，就好像在Java应用程序导致的登录用户停止更新，包括所有运行的应用程序。桌面显示
Given the symptoms and characteristics of the issue, it's as if the Java app is causing the desktop display of the logged in user to stop updating, including any running applications.
编程概念和Java包：
- 多线程
- 标准的退出和 ERR 的被重新路由到一个javax.swing.JTextArea中
- 应用程序使用Swing GUI的
- awt.Robot（极重度使用）
- awt.PointerInfo
- awt.MouseInfo
- Multi-threading
- Standard out and err are rerouted to a javax.swing.JTextArea
- The application uses a Swing GUI
- awt.Robot (very heavily used)
- awt.PointerInfo
- awt.MouseInfo
系统规格：
- Windows 7专业版
- 的Java 1.6.0 U17
在最后，我要强调，我不找任何具体的解决办法，因为我不要求一个非常具体的问题。如果有人使用我使用了Java库时遇到了类似的问题，我只是想知道。我也很乐意AP preciate的东西有什么建议来尝试尝试，以进一步查明是什么原因造成我的问题。
In conclusion, I should stress that I'm not looking for any specific solutions, as I'm not asking a very specific question. I'm just wondering if anybody has run into a similar problem when using the Java libraries that I'm using. I would also gladly appreciate any suggestions for things to try to attempt to further pinpoint what is causing my problem.
谢谢！
罗斯
PS，我会如果我管理整个别的绊倒，而我继续调试这个发布更新/答复。
PS, I'll post an update/answer if I manage to stumble across anything else while I continue to debug this.
更新：我的应用程序所涉及的多线程处理每个初始化自己的机器人对象和创建异步输入事件。我重构应用程序只包含一个机器人单独的对象，但不同的进程仍然异步调用输入的命令。据我所知，这并没有改变我的应用程序的行为。我的下一步可能是围绕创建机器人单一个同步的包装器来看看是否有帮助，但由于症状，我不知道为什么会。
Update: my app involved multi-threaded processes each initializing their own Robot objects and creating input events asynchronously. I refactored the app to only contain one Robot singleton object, but the different processes still asynchronously invoke input commands. As far as I can tell, this did not change the behavior of my app. My next step might be to created a synchronized wrapper around the Robot singleton to see if that helps, but given the symptoms, I don't know why it would.
推荐答案
我不熟悉的机器人，而 在GUI应用程序捕获的异常的可以产生非常奇怪的结果作为事件调度线程死亡并重新启动。你可能会得到来自的如何捕获的异常的处理的。
I'm not familiar with the vagaries of Robot, but Uncaught exceptions in GUI applications can produce very odd results as the event dispatch thread dies and restarts. You might get some ideas from How uncaught exceptions are handled.
这篇关于的Java应用程序，使屏幕显示10分钟的闲置时间后反应迟钝的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
