char[] 中保留的控制台输出导致 OutOfMemoryError
我的小程序总是内存不足。 堆转储分析显示罪魁祸首是traceMsgQueueThread 拥有的char[]，它包含java 控制台输出的全部内容。 随着日志消息发送到控制台，这种情况会随着时间的推移而增长，直到最终小程序耗尽内存。
这种情况似乎只发生在少数客户端上，并且在 1.5 之前到 1.6.0_10 的各种 JRE 上都出现过。 我们所有的客户端都使用相同的参数运行，即 -Xmx256m 和 -XX:+HeapDumpOnOutOfMemoryError，但只有少数客户端出现此问题。
关闭控制台似乎在一个实例中有效，但它不可重复，不幸的是这不是一个选项，因为我们需要日志记录。
有人以前见过这个，或者知道该怎么做吗？
I've got an applet that keeps running out of memory. A heap dump analysis shows that the culprit is a char[] owned by the traceMsgQueueThread that contains the entire contents of the java console output. This grows over time as log messages are sent to the console until eventually the applet runs out of memory.
This only seems to occur for a handful of clients, and has been seen on various JREs from pre 1.5 to 1.6.0_10. All our clients run with the same parameters, i.e. -Xmx256m and -XX:+HeapDumpOnOutOfMemoryError, yet only a few exhibit this problem.
Turning the console off seemed to work in one instance, but it wasn't repeatable and unfortunately is not an option as we need the logging.
Has anyone seen this before, or know what to do about it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在Windows下，您可以通过进入控制面板->Java->高级->Java控制台来禁用控制台。 不过，这显然必须在逐台机器的基础上完成，而且它甚至可能没有帮助，但我怀疑告诉它不要启动控制台会阻止创建该线程。
Under Windows, you can disable the console by going to Control Panel->Java->Advanced->Java Console. This would obviously have to be done on a machine-by-machine basis, though, and it may not even help, but I suspect that telling it not to start the console will stop that thread from being created.
我必须有一些选项来关闭该跟踪。 尝试虚拟机配置或 java 调用中传递的某些参数。
There must me some option to turn off that tracing. Try virtual machine configuration or some parameter passed in the java invocation.