涉及Swing和AWT-EventQueue的无响应线程

郎子平

2023-03-14

问题内容：

我有一个没有响应的应用程序，似乎处于死锁或类似死锁的状态。请参阅下面的两个线程。请注意，My-Thread@101c线程阻塞了AWT-EventQueue-0@301。但是，My-Thread刚刚致电java.awt.EventQueue.invokeAndWait()。所以AWT-EventQueue-0块My-Thread（我相信）。

My-Thread@101c, priority=5, in group 'main', status: 'WAIT'
     blocks AWT-EventQueue-0@301
      at java.lang.Object.wait(Object.java:-1)
      at java.lang.Object.wait(Object.java:485)
      at java.awt.EventQueue.invokeAndWait(Unknown Source:-1)
      at javax.swing.SwingUtilities.invokeAndWait(Unknown Source:-1)
      at com.acme.ui.ViewBuilder.renderOnEDT(ViewBuilder.java:157)
        .
        .
        .
      at com.acme.util.Job.run(Job.java:425)
      at java.lang.Thread.run(Unknown Source:-1)

AWT-EventQueue-0@301, priority=6, in group 'main', status: 'MONITOR'
     waiting for My-Thread@101c
      at com.acme.persistence.TransactionalSystemImpl.executeImpl(TransactionalSystemImpl.java:134)
        .
        .
        .
      at com.acme.ui.components.MyTextAreaComponent$MyDocumentListener.insertUpdate(MyTextAreaComponent.java:916)
      at javax.swing.text.AbstractDocument.fireInsertUpdate(Unknown Source:-1)
      at javax.swing.text.AbstractDocument.handleInsertString(Unknown Source:-1)
      at javax.swing.text.AbstractDocument$DefaultFilterBypass.replace(Unknown Source:-1)
      at javax.swing.text.DocumentFilter.replace(Unknown Source:-1)
      at com.acme.ui.components.FilteredDocument$InputDocumentFilter.replace(FilteredDocument.java:204)
      at javax.swing.text.AbstractDocument.replace(Unknown Source:-1)
      at javax.swing.text.JTextComponent.replaceSelection(Unknown Source:-1)
      at javax.swing.text.DefaultEditorKit$DefaultKeyTypedAction.actionPerformed(Unknown Source:-1)
      at javax.swing.SwingUtilities.notifyAction(Unknown Source:-1)
      at javax.swing.JComponent.processKeyBinding(Unknown Source:-1)
      at javax.swing.JComponent.processKeyBindings(Unknown Source:-1)
      at javax.swing.JComponent.processKeyEvent(Unknown Source:-1)
      at java.awt.Component.processEvent(Unknown Source:-1)
      at java.awt.Container.processEvent(Unknown Source:-1)
      at java.awt.Component.dispatchEventImpl(Unknown Source:-1)
      at java.awt.Container.dispatchEventImpl(Unknown Source:-1)
      at java.awt.Component.dispatchEvent(Unknown Source:-1)
      at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source:-1)
      at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source:-1)
      at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source:-1)
      at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source:-1)
      at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source:-1)
      at java.awt.Component.dispatchEventImpl(Unknown Source:-1)
      at java.awt.Container.dispatchEventImpl(Unknown Source:-1)
      at java.awt.Window.dispatchEventImpl(Unknown Source:-1)
      at java.awt.Component.dispatchEvent(Unknown Source:-1)
      at java.awt.EventQueue.dispatchEvent(Unknown Source:-1)
      at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source:-1)
      at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source:-1)
      at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source:-1)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source:-1)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source:-1)
      at java.awt.EventDispatchThread.run(Unknown Source:-1)

这里是TransactionalSystemImpl.executeImpl方法：

private synchronized Object executeImpl(Transaction xact, boolean commit) {
    final Object result;

    try {
        if (commit) { // this is line 134
            clock.latch();
            synchronized(pendingEntries) {
                if (xactLatchCount > 0) {
                    pendingEntries.add(xact);
                } else {
                    xactLog.write(new TransactionEntry(xact, clock.time()));
                }
            }
        }

        final TransactionExecutor executor = transactionExecutorFactory.create(
                xact.getClass().getSimpleName()
        );

        if (executor == null) {
            throw new IllegalStateException("Failed to create transaction executor for transaction: " + xact.getClass().getName());
        }

        result = executor.execute(xact);

    } finally {
        if (commit) clock.unlatch();
    }

    return result;
}

有谁知道这里发生了什么或如何解决？

问题答案：

在我认识的Swing开发人员中，这似乎invokeAndWait是有问题的，但这也许不像我想象的那样广为人知。我似乎回想起在文档中看到了关于invokeAndWait正确使用困难的严厉警告，但我很难找到任何东西。我在当前的官方文档中找不到任何内容。我唯一能找到的是来自2005年旧版本的Swing教程的这一行：（网络存档）

如果使用invokeAndWait，请确保在调用发生时，调用invokeAndWait的线程不持有其他线程可能需要的任何锁。

不幸的是，该行似乎已从当前的Swing教程中消失。即使这样，还是轻描淡写。我希望它说的是这样的：“如果使用invokeAndWait，则invokeAndWait
在进行 调用时，所调用的线程不得持有其他线程可能需要的任何锁。”
通常，很难知道在任何给定时间内其他线程可能需要什么锁，最安全的策略可能是确保线程调用invokeAndWait 根本不持有任何锁 。

（这很难做到，这就是为什么我在上面说这invokeAndWait是有问题的。我也知道JavaFX的设计者-
本质上是Swing的替代者-在javafx.application.Platform类中定义了一种runLater在功能上等效的方法到invokeLater，但他们
故意忽略了一个等效的方法invokeAndWait，因为它是非常困难的正确使用。）

从第一原理中得出的理由很简单。考虑一个与OP描述的系统类似的系统，它具有两个线程：MyThread和Event Dispatch
Thread（EDT）。MyThread锁定对象L，然后调用invokeAndWait。这将发布事件E1，并等待EDT处理它。假设E1的处理程序需要锁定L。当EDT处理事件E1时，它将尝试对L进行锁定。MyThread已经拥有了该锁定，它直到EDT处理E1才会放弃它，但是该处理被阻止了。通过MyThread。因此，我们陷入僵局。

这是这种情况的变体。假设我们确保处理E1不需要锁定L。这样安全吗？否。如果就在MyThread调用之前invokeAndWait，将事件E0发布到事件队列中，并且E0的处理程序需要锁定L
，则仍然会发生问题。像以前一样，MyThread持有L的锁定，因此将阻止E0的处理。E1在事件队列中位于E0后面，因此E1的处理也被阻止。由于MyThread在等待E1的处理，并且被E0阻止，而E0在等待MyThread放弃对L的锁定时被阻止，因此我们再次遇到了死锁。

这听起来与OP应用程序中的操作非常相似。根据OP对这个答案的评论，

是的，renderOnEDT在调用堆栈中以某种方式同步，即com.acme.persistence.TransactionalSystemImpl.executeImpl方法已同步。renderOnEDT正在等待输入相同的方法。因此，这就是造成死锁的原因。现在，我必须弄清楚如何修复它。

我们没有完整的图片，但这可能足以继续下去。renderOnEDT是从MyThread调用的，该线程在被阻止时会锁定某个对象invokeAndWait。它正在等待EDT处理事件，但是我们可以看到EDT被MyThread持有的东西阻塞了。我们不能确切地说出这是哪个对象，但这没关系-
EDT显然在MyThread持有的锁上被阻塞，而MyThread显然在等待EDT处理事件：因此，死锁。

还要注意，我们可以肯定地确定EDT当前未处理发布者的事件invokeAndWait（类似于上述情况中的E1）。如果是这样，则每次都会发生死锁。根据OP
对此答案的评论，它似乎仅在某些情况下发生，当用户快速键入时。因此，我敢打赌，EDT当前正在处理的事件是一个按键，该按键在MyThread锁定后但在MyThread调用invokeAndWait将E1
张贴到事件队列之前恰好发布到了事件队列中，因此类似于E0中的E0。我上面的情况。

到目前为止，这可能主要是问题的概述，它与其他答案以及OP对这些答案的评论汇总在一起。在继续讨论解决方案之前，以下是我对OP应用程序所做的一些假设：

它是多线程的，因此必须同步各种对象才能正常工作。这包括来自Swing事件处理程序的调用，该事件处理程序大概基于用户交互来更新某些模型，并且该模型还由工作线程（例如MyThread）处理。因此，他们必须正确锁定此类对象。消除同步肯定会避免死锁，但是由于不同步的并发访问会破坏数据结构，因此还会出现其他错误。
该应用程序不一定在EDT上执行长时间运行的操作。这是GUI应用程序的一个典型问题，但似乎并未在这里发生。我假设该应用程序在大多数情况下都能正常工作，其中在EDT上处理的事件会获取一个锁，先进行更新，然后释放该锁。当由于锁的持有人在EDT上死锁而无法获取锁时，就会发生问题。
更改invokeAndWait到invokeLater是不是一种选择。OP表示这样做会引起其他问题。这并不奇怪，因为更改会导致执行以不同的顺序进行，因此会产生不同的结果。我认为它们是不可接受的。

如果我们无法删除锁，也无法将其更改为invokeLater，那么我们就可以invokeAndWait安全地进行调用了。“安全”是指在调用之前放弃锁。考虑到OP应用程序的组织，这可能很难做到，但是我认为这是唯一的进行方法。

让我们看看MyThread在做什么。这被大大简化了，因为可能在堆栈上有很多中间方法调用，但是从根本上来说是这样的：

synchronized (someObject) {
    // code block 1
    SwingUtilities.invokeAndWait(handler);
    // code block 2
}

当某个事件潜入处理程序前面的队列中并且该事件的处理需要lock时，就会发生问题someObject。我们如何避免这个问题？您不能在一个synchronized块内放弃Java的内置监视器锁之一，因此必须关闭该块，进行调用，然后再次打开它：

synchronized (someObject) {
    // code block 1
}

SwingUtilities.invokeAndWait(handler);

synchronized (someObject) {
    // code block 2
}

如果将锁定someObject从调用移到调用堆栈的上方相当远，则这可能会非常困难invokeAndWait，但是我认为这样做是不可避免的。

也有其他陷阱。如果代码块2依赖于代码块1加载的某个状态，则在代码块2再次获得锁定时，该状态可能已过时。这意味着代码块2必须从同步对象中重新加载任何状态。它不能基于代码块1的结果进行任何假设，因为这些结果可能已过时。

这是另一个问题。假设正在运行的处理程序invokeAndWait需要从共享库中加载一些状态，例如，

synchronized (someObject) {
    // code block 1
    SwingUtilities.invokeAndWait(handler(state1, state2));
    // code block 2
}

您不能只是将invokeAndWait调用迁移到同步块之外，因为这将需要非同步访问才能获得state1和state2。相反，您要做的是在锁定内将此状态加载到局部变量中，然后在释放锁定后使用这些局部变量进行调用。就像是：

int localState1;
String localState2;
synchronized (someObject) {
    // code block 1
    localState1 = state1;
    localState2 = state2;
}

SwingUtilities.invokeAndWait(handler(localState1, localState2));

synchronized (someObject) {
    // code block 2
}

释放锁定后进行 呼叫的 技术称为 开放呼叫 技术。请参见Doug Lea，《 Java并发编程》
（第二版），第2.4.1.3节。Goetz等人也对该技术进行了很好的讨论。等，《 Java Concurrency In Practice》
，第10.1.4节。实际上，第10.1节中的所有内容都相当彻底地涵盖了僵局。我强烈推荐。

总而言之，我相信使用我上面描述的技术或引用的书中的技术，可以正确，安全地解决此死锁问题。但是，我确信这将需要大量的仔细分析和困难的重组。不过，我没有其他选择。

（最后，我应该说，尽管我是Oracle的雇员，但这绝不是Oracle的正式声明。）

更新

我想到了更多可能有助于解决问题的重构方法。让我们重新考虑代码的原始架构：

synchronized (someObject) {
    // code block 1
    SwingUtilities.invokeAndWait(handler);
    // code block 2
}

这将按顺序执行代码块1，处理程序和代码块2。如果将invokeAndWait调用更改为invokeLater，则处理程序将在代码块2之后执行。很容易看出这对于应用程序来说是个问题。相反，我们如何将代码块2
移到，invokeAndWait以便它以正确的顺序执行，但仍在事件线程上执行呢？

synchronized (someObject) {
    // code block 1
}

SwingUtilities.invokeAndWait(Runnable {
    synchronized (someObject) {
        handler();
        // code block 2
    }
});

这是另一种方法。我不确切知道传递给处理程序的invokeAndWait意图是什么。但是可能需要这样做的一个原因invokeAndWait是它从GUI中读取了一些信息，然后使用它来更新共享状态。这必须在EDT上，因为它会与GUI对象交互，并且invokeLater不能使用，因为它会以错误的顺序发生。这建议在进行其他处理invokeAndWait
之前先 进行调用，以便将信息从GUI中读取到临时区域中，然后使用该临时区域执行后续处理：

TempState tempState;
SwingUtilities.invokeAndWait(Runnable() {
    synchronized (someObject) {
        handler();
        tempState.update();
    }
);

synchronized (someObject) {
    // code block 1
    // instead of invokeAndWait, use tempState from above
    // code block 2
}

涉及Swing和AWT-EventQueue的无响应线程

相关阅读

相关文章

相关问答

相关工具

相关文档