Delphi12.1+Indy10下TIdTCPClient引发FreeRTOS服务器CPU负载异常问询

问题描述 #

我用Delphi 12.1和Indy 10实现了一套客户端/服务器应用：Windows客户端发送固定大小的数据请求后等待服务器响应，基于FreeRTOS+套接字的服务器仅在收到数据时才回复，通信采用固定包长的ping/pong模式。服务器仅运行以太网任务，平时CPU负载稳定在7%左右，但当移动客户端主GUI窗口或进行参数文件读写操作时，服务器CPU负载会骤升至90%。

核心疑问 #

我原本认为TIdTCPClient运行在独立线程，应该不受客户端GUI活动或临时CPU负载影响，想请教：

1. TIdTCPClient是否确实完全独立于主线程？
2. 哪些场景下GUI活动或Windows线程调度会影响网络通信，进而导致服务器CPU负载波动？

客户端Socket线程代码示例 #

procedure TSocketThread.Execute;
var
//definitions
const
//definitions
begin
  allow_ethernet_data_to_send := True;
  SetLength(RecIntegers, TOAL_DATA_SIZE);
  while (not Terminated) do
  begin
    //connect client
    try
      Synchronize(
      procedure
      begin
          //some output
      end);
      FClient.Connect;
    except
      for I := 1 to 5 do//wait 5sec to connect again and give room for a thread termination
      begin
        if Terminated then Exit;
        Sleep(1000);
      end;
      Continue; //try to connect again until thread is terminated
    end;
    //start communication with server
    try
      try
        FClient.Socket.ReadTimeout := READ_TIMEOUT_MS;
        while (not Terminated) do
        begin
          //--------------------------------------------------------------------
          if allow_ethernet_data_to_send then
          begin
             FClient.Socket.Write(Generate_Sending_ByteArray(data_to_send));
             allow_ethernet_data_to_send := False;//only send once and then wait for a receive
          end;
          //--------------------------------------------------------------------
          if FClient.Socket.CheckForDataOnSource(CHECK_FOR_DATA_MS) then
          begin
            //try to read the full packet (MAX_SIZE_WITH_CRC)
            SetLength(Buffer, MAX_SIZE_WITH_CRC);
            FClient.IOHandler.ReadBytes(Buffer, MAX_SIZE_WITH_CRC, False);//this function blocks
            //------------------------------------------------------------------
            //alow a new write:
            allow_ethernet_data_to_send := True;
            //----------------------------------------------------------------
            // Extract buffer
            //------------------------------------------------------------------
          end;
        end;
      except
        on E: Exception do
        begin
          Synchronize(
          procedure
          begin
              //some output
          end);
        end;
      end;
    finally
      FClient.Disconnect;
    end;
  end;
end;

问题分析与解答 #

1. TIdTCPClient的线程独立性 #

TIdTCPClient本身是线程安全的，设计上支持在非主线程中使用，但你的线程实现存在破坏独立性的问题：代码中多次使用Synchronize调用，该方法会强制将指定的代码块同步到主线程执行，阻塞当前Socket线程直到主线程完成代码块的执行。当GUI活动繁忙时（比如移动窗口需要持续处理WM_PAINT消息），主线程消息队列被占满，Synchronize的等待时间会大幅延长，直接导致Socket线程被挂起，无法及时处理网络通信逻辑。

2. GUI活动影响服务器CPU负载的场景 #

结合你的代码和现象，核心原因是客户端Socket线程被阻塞后，引发服务器端的通信逻辑进入忙等待：

• 客户端接收延迟：Socket线程被Synchronize阻塞后，无法及时读取服务器发送的响应包，导致TCP接收窗口被占满。服务器端的以太网任务会不断尝试向客户端发送数据，由于发送缓冲区无法释放，任务会进入高频重试的循环，直接拉高CPU负载。
• 轮询逻辑放大问题：代码中使用CheckForDataOnSource(CHECK_FOR_DATA_MS)进行轮询，若CHECK_FOR_DATA_MS值较小，Socket线程恢复后会进入高频轮询状态，进一步加剧客户端的通信时序混乱，让服务器的重试逻辑持续运行。
• 连接/异常处理的阻塞：连接失败或通信异常时的Synchronize调用，同样会阻塞Socket线程的重连或恢复逻辑，导致服务器端的连接状态处理逻辑出现异常，增加CPU消耗。

优化建议 #

• 替换Synchronize为Queue：Queue不会阻塞Socket线程，仅将UI更新请求放入主线程消息队列，让Socket线程可以持续处理网络通信。
• 移除轮询逻辑：直接依赖ReadBytes的阻塞特性（配合合理的ReadTimeout），让Socket线程在等待数据时进入休眠状态，避免无意义的轮询占用CPU，同时保证及时响应服务器的数据包。
• 优化服务器端逻辑：为服务器的以太网任务添加合适的发送超时和退避机制，避免因客户端无响应而进入无限重试的忙等待循环。
• 隔离UI与网络逻辑：确保Socket线程中仅处理网络相关操作，所有UI交互都通过异步方式触发，彻底避免主线程对网络线程的阻塞。

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