多线程套接字通信中的场景

Question

我有一个socket客户端应用程序，在应用程序启动期间，会创建socket（与服务器建立连接），并启动两个并行运行的线程。

Thread-1：使用read方法连续读取套接字（块，直到收到数据）

Thread-2：连续写入数据。

在写入套接字时，如果线程2接收到IO异常，那么它会丢弃现有的套接字并创建新的套接字并开始通信。由于线程2丢弃套接字，线程1接收空指针异常。我们有什么应对策略吗

Answer 1

您开始遇到与系统设计的proactor风格相关的问题。解决这个问题需要两个线程之间进行一些通信。选择这种交流方式会让事情变得一团糟。它必须能够阻止thread1尝试读取套接字。我不太擅长Java，但在C中，这意味着使用信号。

我建议你避免使用信号，即使Java中也有类似的信号。

一个更好的选择是，在调用select（）（或任何Java等价物）时阻止thread1，等待套接字和管道。当Thread2想要关闭套接字时，它会写入管道，thread1从select（）返回，在管道中写入对Thread2的响应，并再次调用select（），但只在管道上调用。Thread2读取该响应，关闭套接字，打开一个新的套接字，然后沿管道发送其他内容以再次唤醒thread1，thread1现在可以返回到select（），但这次是在管道和新套接字上。这实现了thread1和thread2之间的执行会合；thread2可以关闭旧插座并打开新插座，因为它知道（通过管道通信）thread1何时不使用插座。

这就有些凌乱了。也变得更像Reactor设计模式。在这种情况下，也可以只使用一个线程来选择是否将套接字作为它正在执行的任何循环的一部分来读取。这个单线程将在数据可用时读取数据，而不是希望数据到达时进行阻塞读取。如果套接字写入出错，需要替换套接字，它只是这样做；没有其他线程可以同步。假设您的套接字连接到网络上的远程服务器（而不是同一台机器上的服务），以太网的速度仍然是主要瓶颈；Reactor式系统也不会慢。

一般来说，使用reactor系统样式处理网络故障要容易得多，因为没有线程致力于执行其他线程知道不合适的操作。不幸的是，大多数编程环境都是proactor，例如Windows、Boost ASIO、RabbitMQ等。在出现问题之前，proactor系统是正常的，在这之后，通常有必要扔掉整个过程，因为对于程序员来说，整理所有错误的回调和异步IOs很容易变得极其复杂。

一种选择是如果可以的话使用ZeroMQ。这要求您在任何地方都使用ZeroMQ（也使用服务器），但它使处理网络问题变得容易得多。这是一个Reactor，而不是一个促发剂。

Answer 2

线程2需要在关闭套接字之前关闭套接字进行输入。这将导致线程接收并结束流，这将导致它关闭套接字并退出。然后线程2可以创建另一个套接字并启动另一个读取线程。