Eclipse 从UI线程调用PlatformUI.getWorkbench（）.getDisplay（）.syncExec

我看到：

if (Display.getCurrent() == null){
   PlatformUI.getWorkbench().getDisplay.asyncExec(aRunnable)
} else {
   aRunnable.run();
}

我想知道是否真的需要手动检查当前的执行线程。如果我无条件使用

PlatformUI.getWorkbench().getDisplay.asyncExec(aRunnable)

---

显示实现不会正确处理这两种情况吗？如果是这样的话，在用

syncExec

替换

asynceec

时，它是否也能正确地处理它？

SWT的显示将正确地处理

syncExec

和

asynceec

，而不管它们是从UI线程还是其他线程调用的

---

如果您真的想要避免调用这些API的微小开销，并且喜欢在发布的代码上执行同步，那么进行这样的检查是有意义的

这是一个实现细节，说明从UI线程调用

syncExec

或

asynceec

时如何操作。各国：

导致用户界面线程在下一个合理的时机调用runnable的run（）方法

这意味着您的

Runnable

可以简单地放在队列中，并在下一个调度循环中执行，可能在其他

Runnable

之后执行。如果在UI线程上特别调用

Runnable

的

run

方法，则可以更好地控制其调度

当然，从UI线程调用时，

syncExec

和

asynceec

的行为可能会有所不同。我似乎记得当从UI线程调用时，

syncExec

将立即执行，

asynceec

将始终对其工作进行排队，但这是一个实现细节，不能保证

此外，否，您不能将

异步执行

的每个实例都替换为

同步执行

syncExec

将等待相关的runnable被UI线程发布和执行，这可能会造成严重的争用问题。假设以下代码在非UI线程上运行：

synchronized(foo)
{
    display.asynExec(new Runnable() {
        public void run()
        {
            synchronized(foo)
            {
                System.out.println("Hello!");
            }
        }
     });
}

这是一个微不足道的例子——但它不会死锁。

asyncExec

调用将对该runnable进行排队并返回，它将退出

synchronized

块，以便UI线程上的runnable稍后可以获得锁。但是，将其替换为

syncExec

肯定会死锁

---

通常，建议使用

asynceec

，除非您认为需要

syncExec

提供的执行保证。

我认为您可以删除从“进一步，否…”开始的部分，这与我的问题无关。