Java Win api的SendMessage将永远等待

我在windows 7 64位service pack 1上有一个GUI应用程序 我的GUI应用程序中有一些Java，它发送Delphi代码-

最近，升级到多核PC后，我们注意到一些繁重的GUI操作导致GUI卡住。我们只有一个更新GUI的线程

调试之后，我们注意到，偶尔，delphi调用WinAPI的SendMessage会一直等待

然后，我们尝试将程序的亲和性设置为1，问题得到了解决，但这会减慢应用程序的速度

我知道用PostMessage或SendMessageTimeout替换SendMessage是很常见的，但我们在许多地方使用SendMessage+我们也使用同样使用SendMessage的DevXPress组件-我们不可能映射所有这些地方

最奇怪的是，尽管我们的GUI只有一个线程，但将affinity设置为1可以解决系统中还有其他后台线程的问题，但它们都是纯java的，并执行一些数据计算

我的问题是：

有什么已知的方法可以解决这个问题吗？可能是Windows7中已知的bug

有没有可能我发的信息不知怎么丢了？邮件总数或发送速率是否有限制？如果是，我如何增加这些限制

如何获取更多信息-例如：检查windows中的某个地方我的邮件发生了什么-windows在哪里/为什么卡住等。 任何进一步分析这个问题的方法都将不胜感激

非常感谢

SendMessage在跨线程边界发送消息时依赖于目标窗口的消息队列。这是记录在案的行为：

如果指定的窗口是由其他线程创建的，系统将切换到该线程并调用相应的窗口过程。只有当接收线程执行消息检索代码时，才会处理线程之间发送的消息。发送线程被阻塞，直到接收线程处理消息

因此，只有目标线程从其消息队列中检索到消息，然后完全处理该消息，或者在继续处理该消息的同时调用释放SendMessage，SendMessage才会退出

因此，如果SendMessage被卡住，这意味着目标线程没有处理其消息队列，这很好地表明目标线程可能在等待其他消息时处于死锁状态

---

你的应用程序在锁定到1个CPU内核时运行良好，但在允许在多个CPU内核上运行时出现问题，这意味着你的应用程序可能无法以多核安全的方式执行线程间同步。在单核系统中，在任何给定时刻，只有一个线程可以实际运行。由于操作系统使用线程调度和任务切换处理并发的方式，在某些情况下，不安全的同步可能足够安全。但是多个内核可以真正并行运行，因此在不同内核上运行的线程有可能在同一时刻访问内存/资源，因此正确执行线程间同步非常重要，以确保不允许发生这种情况，否则您的应用程序可能会与自身不同步，各种各样的坏事情都可能发生，比如你的死锁。

为什么你认为这个错误在Windows中？为什么你不认为错误在于你的代码？你的程序有一个错误，听起来像死锁，在你接受它之前，你不会取得进展。如果没有代码和详细信息，我们也帮不上什么忙。虽然你说你有一个单线程来更新GUI，但你没有明确说明你的GUI实际上是否是单线程的。换句话说，GUI中的所有窗口是否都属于同一线程？还有一点您没有明确指出：您对SendMessage的呼叫是否跨越线程边界？谢谢你们的回复。我可以接受这是我的问题。所以，我接受了。有什么工具/方法可以深入调查并找出可能的原因吗？例如，可能出现死锁等情况。？是的，我的应用程序是多线程的，但是只有一个线程控制GUI。GUI本身是用delphi编写的——更准确地说，我们使用DevXPress组件和FastMM来管理内存。GUI本身也是多线程的。但是我的控件是单线程的-因此，与其他线程的任何交互都必须是与来自fastMM/delphi/DevXpress的线程的交互。首先，找出应该处理消息的GUI线程在SendMessage挂起时正在做什么。理想情况下，您可以使用调试器来执行此操作，但如果无法做到这一点，您可能只需要开始详细记录相关线程所做的一切。当应用程序挂起时，请闯入其中，并使用线程窗口了解线程正在做什么，查找一个线程等待另一个线程。看看你能不能找到这样的僵局。坦白说，我不理解 还有投票。虽然你所说的一切本身都是正确的，但它基于的假设已不再成立，因为OP回复了要求澄清的评论。值得注意的是，GUI是多线程的这一事实将可能的原因从同步问题转移到了跨线程消息处理上。这篇评论不是针对作者的，而是针对这个网站的快乐成员。