Windows 对于已被破坏的窗口，挂起的消息会发生什么情况？

当一个窗口被破坏，而仍然有消息等待它时会发生什么

考虑以下场景：

有三个线程，A、B和C。线程C拥有一个窗口

线程A和B使用

SendMessage

将消息发布到窗口。来自A的消息首先到达。当C处理来自A的消息时，它使用

destronWindow

销毁其窗口

来自线程B的消息会发生什么变化？线程B对

SendMessage

的调用是否返回

---

这在内部是如何工作的？

根据，

DestroyWindow

“[…]，刷新线程消息队列[…]。我不确定这是否意味着要处理消息或转储消息，所以我尝试了。结果是后者：所有挂起的已发布消息都从队列中删除并被忽略。至于非排队消息：在我的测试中，挂起的

SendMessage

调用返回并将最后一个错误设置为

error\u INVALID\u参数-87（0x57）

原则上，您建议的操作是不安全的。线程C无法保证线程B已经发送了消息；如果在线程B发送消息之前窗口被破坏，并且在此期间窗口句柄碰巧被重用，那么线程B可能会将消息发送到错误的窗口，而错误的窗口可能位于不同的应用程序中

最佳实践是在调用DestroyWindow之前，确保所有线程都被告知某个特定的窗口句柄已无效

---

然而，实际上，在错误的时间重复使用手柄的风险非常低。如果不可能提前通知其他线程，那么您不太可能因此陷入麻烦。我相信kicsit断言消息不会在线程C的消息队列中等待是正确的，尽管文档并没有明确承诺这一点（据我所知）。

很有趣，但我不会依赖这种行为。可能存在竞争条件，即结果很可能取决于三个线程的调度顺序，因此它可能在99.9%的时间里做一件事，而在其他0.1%的时间里做另一件事。现在我想起来了，我的观点可能没有意义；确实，通过可能已销毁的窗口句柄发送消息本质上是无效的？DestroyWindow不会转储所有消息。它只转储特定于该窗口的消息。如果假设C拥有多个窗口，DestroyWindow将不会刷新线程消息队列。仅删除特定的windows消息。。所以我认为MSDN并不清楚。