sta*_*oid 36 java garbage-collection memory-leaks javafx javafx-8
我有一个JavaFX应用程序,当按下X按钮时,该应用程序最小化到托盘.我一直在通过VisualVM监视应用程序的内存趋势.
奇怪的是,当应用程序打开或最小化到任务栏时,内存总是被GC返回到使用的初始内存.然而,当它被最小化到托盘(stage.hide(),systemTray.show())时,内存得到GCed,但是呈上升趋势(泄漏).
在VisualVM中,Old Gen空间不断上升,一旦它在一段时间后达到最大值,应用程序将无法响应,并且CPU峰值达到80%.
我注意到如果我stage.show()通过双击托盘图标等在应用程序上,GC将清除所有内容恢复正常.但是,如果长时间离开,它将无法使GC成为老一代.
堆转储显示javafx.scene.Scene#7并javafx.scene.Node[]#2具有最多保留空间.如果未隐藏舞台,则两者都不会出现.在参考文献中,它显示
this[] -> dirtyNodes().
this - value: javafx.scene.Node[] #2
<- dirtyNodes - class: javafx.scene.Scene, value: javafx.scene.Node[] #2
<- value - class: javafx.scene.Node$ReadOnlyObjectWrapperManualFire, value:
javafx.scene.Scene #7
Run Code Online (Sandbox Code Playgroud)
造成这种情况的原因是什么?如何解决这个问题?
Alo*_*Sen -2
Java具有弱引用等功能:https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html
软参考:https://docs.oracle.com/javase/7/docs/api/java/lang/ref/SoftReference.html
这些允许您专门针对虚拟机->>垃圾收集的内容。
另外,还有并发API http://winterbe.com/posts/2015/04/07/java8-concurrency-tutorial-thread-executor-examples/
使用执行器服务和线程池。
对于java中的内存限制应用程序,软件应该调用
System.gc() // garbage collector
每隔一段时间,无论其自动调用
您可以使用 Runtime 类来安排项目的负载均衡器 https://docs.oracle.com/javase/7/docs/api/java/lang/Runtime.html
public Process exec(String command)
throws IOException
//--------------------------------------------------------
Executes the specified string command in a separate process.
public void gc()
//----------------------------------------------------------
Runs the garbage collector. Calling this method suggests that the Java virtual machine expends effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects
This is a convenience method. An invocation of the form exec(command) behaves in exactly the same way as the invocation exec(command, null, null).
Run Code Online (Sandbox Code Playgroud)
线程一直是内存密集型应用程序的一个问题,在 JavaFX 中,场景的每个组件都是与场景紧密绑定的线程,但在实现时,它似乎是松散绑定的。
如果需要长时间运行,最好在本机端(JNI)处理一些处理器密集型任务。此外,CLEAN 架构将受益
| 归档时间: |
|
| 查看次数: |
2148 次 |
| 最近记录: |