Java Swing EDT 和 Java Swing并发性

Question

我只是想知道是否仍然有必要确保 invokeLater() Runnable 的同步性。

我遇到了死锁，需要在保持并发性的同时克服它。

这是一个好的代码示例吗？：

private String text;

private void updateText()
{
    SwingUtilities.invokeLater(new Runnable()
    {
        public void run()
        {
            synchronized(FrameImpl.this)
            {
                someLabel.setText(text);
            }
        }
    });
}

对于这个相当糟糕的示例感到抱歉，但我们必须假设 text 正在被不同的线程修改，无法注入，并且依赖于正确的值。

这是正确的解决方案吗？还是我会通过将同步代码发送到未知的上下文中而无意中造成死锁问题？

谢谢。

Answer 1

更好的解决方案是这样的：

public class Whatever {
    private String text;
    private final Object TEXT_LOCK = new Object();

    public void setText(final String newText) {
        synchronized (TEXT_LOCK) {
            text = newText;
        }
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                someLabel.setText(newText);
            }
        });
    }

    public String getText() {
        synchronized (TEXT_LOCK) {
            return text;
        }
    }
}

这将确保如果两个线程尝试同时调用 setText，那么它们不会互相干扰。第一个线程将设置 text 的值，并使用该值将 UI 更新排入队列。第二个线程还将设置 text 的值并将第二个 UI 更新排入队列。

最终结果是 UI 最终将显示最新的文本值，但内部 text 变量将立即包含最新的值。

一些注意事项：

1. 使用单独的锁定对象（即 TEXT_LOCK）意味着您不会受到其他地方的代码的影响，将监视器锁定在 Whatever 实例上并无意中导致死锁。最好始终严格控制您的锁定对象。最好还是最小化同步块的大小。
2. 您可以使整个setText方法同步，但需要注意的是，它确实使您可能容易陷入上述死锁。
3. 即使Strings 是不可变的，读取text 的值也需要同步。 Java 内存模型有一些微妙之处，这意味着您总是需要同步可由多个线程读取/写入的变量。

查看 Brian Goetz 的 Java 并发实践，深入了解其中的棘手部分并发性（包括奇怪的内存模型）。

Answer 2

现在这是正确的，任务的所有输出都必须包装到 InvokeLater() 中，从 BackGround 任务更新 GUI 的另一个示例是 此处

private String text;

private void updateText() {

    synchronized (FrameImpl.this) {
        SwingUtilities.invokeLater(new Runnable() {

            public void run() {
                someLabel.setText(text);
            }
        });
    }
}