Javafx：javafx.concurent和Platform.runLater之间的区别？

Javafx：javafx.concurent和Platform.runLater之间的区别？

Platform.runLater

A

Worker

是对的补充

Platform.runLater

。

• 使用

  Platform.runLater

  时会提供的JavaFX应用程序线程的执行关闭，要运行的JavaFX应用程序线程一些逻辑。
• 使用

  Worker

  时，您是在JavaFX应用程序线程运行，并希望产卵一些逻辑或（尤其是）I / O上一个新的线程，这样你就不会阻塞了JavaFX应用程序线程。

你绝不会希望做一个内部网络I / O

Platform.runLater

的

run

方法，但常常会想这样做的

Worker

的

call

方法。

任务与服务

考虑使用Worker的Task或Service子类。这些是FutureTask的
JavaFX包装器（后者又是Runnable）。工作者提供了一种在后台线程上运行逻辑的调用方法。它们维护执行状态（通过向JavaFX线程提供线程安全的回调通知来更改状态），并通过value，message和exception属性返回调用结果。

利用

Task

和

Service

javadoc示例中的设计模式来简化具有以下功能的线程安全应用程序的创建：

• 异步获取数据以更新UI。
• 定期更新消息以了解任务进度。
• 构造 尚未 附加到显示场景的节点图。
• 通过进度条等监视进度

一起使用Workers和Platform.runLater

而且，使用

Task

和

Service

不使用与不兼容

Platform.runLater

。例如，如果您要运行很长的时间，

Task

要从中定期将部分结果返回到UI或在缓冲区填满时返回，则

Platform.runLater

在任务的

call

方法中执行是实现此目的的方法。

使用现有的线程系统

当您没有库提供的现有线程服务，而是创建自己的线程以在后台执行时，工作器将非常有用。如果您已有线程服务，则需要使用

Platform.runLater

JavaFX应用程序线程来执行逻辑。

小心编写多线程代码

请注意，即使您使用，也仍然需要知道自己在做什么

Worker

。您仍然必须注意不要违反标准JavaFX并发规则，例如从不更新活动场景图中的节点（包括不更新活动场景图中的节点绑定到的值），例如可观察到的项目支持列表一个ListView控件）。

回答您的一些其他问题

这是否意味着使用javafx.concurrent，我们可以有多个实际的绘图线程，还是全部都结束在一个线程上？

JavaFX中只有一个渲染线程。您不能使用JavaFX并发创建更多渲染线程。您可以执行一些 *** 作，例如在JavaFX线程之外创建节点，或者使用许多线程将像素设置为屏幕外的WriteableImage或Canvas，但是最终每个渲染 *** 作都将通过JavaFX系统管理的单个线程，您无法对其进行控制。

如果我使用javafx.concurrent重写我的应用程序，我是否可以像我曾经使用Swing + JavaFX一样模仿2个绘制线程的经验？

不。即使您可以，我也不建议这样做。使用这样的模型，创建微妙的，难以调试的线程处理相关错误太容易了。这样设置带来的收益可能会比您期望或期望的要少。

有关为什么不建议使用2个或更多“绘制线程”的信息，请参阅相关文章：

• 牙痛
• 多线程工具包：失败的梦想

Java 8添加了一个实验性的命令行开关，以将相同的线程用于JavaFX应用程序线程和Swing事件分配线程。这样做的主要原因是它简化了编程模型。

一切都落在javafx上，这意味着在执行诸如打开文件选择器之类的 *** 作时会出现很多暂停。

也许您的代码效率低下（例如，在UI线程上执行I / O）导致了暂停。

繁重的工作（例如，打开FileChooser）

打开和呈现FileChooser并不繁琐。JavaFX可以轻松处理此类 *** 作，而不会降低性能。与I /
O相关的工作可能很耗时，例如，递归地遍历大型文件树以获取文件属性。在这种情况下，您可以做的是为I /
O生成一个线程以在中运行它，

Worker

并通过定期将部分结果反馈给UI线程

Platform.runLater

。这样的方案将很好地工作。瓶颈不是图形，因此拥有另一个图形线程不会带来任何好处。瓶颈是速度较慢的I
/ O系统，并且通过为I / O使用单独的线程来掩盖此瓶颈，从而不会影响主UI线程，并且在发生I / O时用户不会遇到UI冻结的情况。