听起来你遇到的是多线程Socket开发里常见的资源关联或同步问题，我之前做简易聊天工具时也踩过几乎一模一样的坑，给你几个具体的排查方向：

• 检查接收队列的关联逻辑
  大概率是后续客户端的接收线程没有正确绑定到对应的接收队列，或者全局队列的初始化逻辑只执行了一次。比如服务器在第一个客户端连接时创建了全局消息队列，但后续客户端的线程没拿到这个队列的正确引用；或是每个客户端本该有独立的接收队列，但代码里只给第一个客户端分配了。你可以在客户端连接成功时，打印每个线程对应的队列ID或指针，确认后续线程的队列引用是否正确。

• 验证队列访问的线程安全性
  如果用的是全局共享队列处理客户端消息，一定要确保队列的读写操作是线程安全的。比如出队（读取）操作有没有加互斥锁（pthread_mutex_lock/unlock）？如果没加锁，多个线程同时读取队列时，可能只有第一个线程能成功获取数据，其他线程会因为竞争条件被阻塞或读取失败。可以在队列的读写代码前后加上锁，再测试看看问题是否解决。

• 检查服务器端的客户端socket管理
  服务器是不是维护了一个客户端socket列表？看看后续客户端的socket有没有被正确添加到列表里，并且接收线程有没有关联到对应的socket。比如如果用select或epoll监听客户端请求，是不是只有第一个客户端的socket被加入到监听集合中，后续的没加进去？这种情况下服务器根本不会处理后续客户端的发送请求，自然只有第一个能发消息。

• 深入分析netstat的输出
  你提到用netstat查看了消息队列状态，重点关注每个客户端连接的ESTABLISHED状态，以及recv-Q和send-Q的数值：

  • 如果后续客户端的send-Q持续增长，说明客户端已经发送了消息，但服务器没有读取，这指向服务器端的接收线程没处理对应socket的数据；
  • 如果recv-Q有数据但线程没读取，那就是线程和队列/socket的关联出了问题。

另外可以加个小调试技巧：在每个客户端的接收线程里，定时打印线程ID和正在处理的socket描述符，确认线程确实在处理对应客户端的连接，而不是复用了第一个客户端的资源。

内容的提问来源于stack exchange，提问作者Mamsie