JavaFX 8 QuantumRenderer CPU使用率很高

时间:2014-09-18 06:48:44

标签: javafx cpu renderer

我有一个JavaFX APP,其中包含两个列表视图,显示从我的服务器收到的传入客户订单(使用自定义cellfactory)。我还有一些tableview显示来自Postgres数据库的信息(这些信息分布在tabpane中的几个选项卡中)。 用户必须接受订单(通过点击它),并在文本框中输入一些信息。

该应用程序最初是使用Java7编写的。我没有任何问题。 但最近我决定改用Java8。我修改了我的代码以使用lambdas并在应用程序中添加了一些额外的东西:

  • 在文本流中每分钟检查和显示订单状态的时间表;
  • 修改了customcellfactory类以使用外部CSS,使用setId而不是setStyle;
  • ...

现在,应用程序运行正常,但在正常运行2-3小时后,它变得迟缓。由于我很难模拟探查器内部的行为,因此我使用jstack top -H,并将pidnid匹配,以了解正在发生的事情。

通过这种方式,我发现罪魁祸首是QuantumRenderer,CPU使用率为95 +%:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
30300 utilizat+  20   0 5801608 527412  39696 S  95,1  6,5  60:57.34 java

"QuantumRenderer-0" #9 daemon prio=5 os_prio=0 tid=0x00007f4f182bb800 nid=0x765c runnable [0x00007f4eeb2a1000]
   java.lang.Thread.State: RUNNABLE
    at com.sun.prism.es2.X11GLDrawable.nSwapBuffers(Native Method)
    at com.sun.prism.es2.X11GLDrawable.swapBuffers(X11GLDrawable.java:50)
    at com.sun.prism.es2.ES2SwapChain.present(ES2SwapChain.java:186)
    at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:107)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
    at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
    at java.lang.Thread.run(Thread.java:745)

运行该应用程序的计算机使用的是一个64位版本的Lubuntu。

我无法弄清楚我应该在哪里找出问题所在......

1 个答案:

答案 0 :(得分:3)

您的渲染器似乎正在使用X11管道(Java2D?),这可能是高CPU使用率(软件加速)的原因。您的显卡是否支持硬件加速?

尝试使用-Dprism.verbose=true获取更多信息,如果您的图形卡确实支持硬件加速,您可能希望尝试使用-Dprism.forceGPU=true强制它,同时尝试启用OpenGL管道以{{1}来提高Java2D性能(你也可以尝试旧的Java2D标志 -Dprism.order=es2,es1,sw,j2d,但我认为这不会影响棱镜)。

我还建议您查看一下OpenJFX performance tips and tricks checklist我发现节点中的CPU使用率很高,但在使用Node.setCache(true)及其CacheHints时有所修复使用任何类型的动画(具有使用更多内存的缺点)。

另外,请看一下如何从工作线程更新UI。在FX UI线程中进行最低限度的工作并正确地从您的工作人员更新它是非常重要的,只有在必要时,请查看this other question以了解有关 javafx.concurrent.Task <的更多信息。 / em>类及其从工作线程更新UI的正确用法。

这看起来更像是一个软件加速问题而且Dprism.verbose应该让你知道更多,但是遵循其他建议永远不会伤害!希望这有帮助!