我们有一组用Java编写的应用程序，它们通过套接字交换简短的XML消息来相互通信。目前，在开发过程中，我们在同一个工作站上运行所有应用程序。我们的问题是，在每个方向上交换了成千上万条消息后，以某种方式可能会使这些程序之间的套接字连接挂起。
查看Eclipse调试器中的问题，我们发现连接的两端都运行相同代码的单独实例。两端刚刚使用其write（String）调用成功地将基于Socket的有效消息写入BufferedWriter，并且两端似乎在BufferedWriter flush（）调用完成时等待被阻塞。代码并没有什么不寻常之处，它在挂起之前可以完美地运行成千上万条消息。两端都没有抛出异常，等待似乎是无限期的。我们在Linux和Windows平台上运行时都发现了这个问题。
任何人都可以提出可能发生的事情吗？
答案 0 :(得分：2)
两端刚刚使用其write（String）调用成功地将基于Socket的有效消息写入BufferedWriter，并且在完成BufferedWriter flush（）调用时两端似乎都被阻塞等等。
换句话说，两端都在写，没有结束。因此，如果写入溢出发送方的套接字发送缓冲区，如果接收方的套接字接收缓冲区已满，这可能发生，如果接收方未读取，则发生这种情况，发送方将阻塞。这听起来像应用程序协议错误。在一端发送时，另一端应该接收。否则在一端或两端应该有单独的发送和接收线程。
答案 1 :(得分：0)
仔细检查您的消息传递协议以确保socketA写入时，socketB读取，反之亦然。如果有两端同时尝试写入的情况，则表示存在问题。最初的连接（客户端）将消息写入接受端（服务器）是最常见的。然后服务器将写一个响应，希望客户端正在收听。
答案 2 :(得分：0)
谢谢大家的想法。我们已经弄清楚了，一旦我们采取了足够大的视野，它根本就不是很神秘。 EJP走在正确的轨道上。为了提供更多信息，每个应用程序打开的每个套接字实际上都是一个读取线程，它在消息可用时读取套接字，并将它们放在队列中进行进一步处理。这些读取线程在套接字的两端陷入僵局，等待阅读，这就是昨天让事情变得莫名其妙的原因。 今天，经过更好的观察，似乎整个系统都得到了支持;有问题的特定套接字没有被阻止尝试排队新读取的消息，但系统中的其他人是。因为所有应用程序都使用相同的代码进行通信，所以这种“刚性”能够锁定整个系统 我们现在认识到发生了什么，以及如何解决它。再次感谢。
答案 3 :(得分：-1)
在java中进行高效的2路交换套接字编程make put reader＆amp;作家是不同的主题。
哪种方式是在双向通信中实现套接字编程