Delphi 的 TIdTCPClient 独立线程为何会影响服务端 CPU 负载？

2026-11-06数据小许

结论

把 TIdTCPClient 的网络操作放在线程中执行，可以避免它们直接占用 GUI 主线程。通信和 GUI 活动仍可能相互影响：Windows 会调度各个线程，主线程中的同步调用也可能让工作线程等待。因此，GUI 操作可能改变请求和响应的时间间隔。

客户端窗口移动或文件操作与服务端负载同时变化，并不足以确定原因在客户端。服务端 CPU 负载还取决于 Ethernet task 等待和处理数据的方式，以及空闲时间的测量方法。由于缺少服务端任务代码和负载测量实现，目前无法判断负载升至约 90% 的原因。

这段客户端代码中的等待点

示例使用固定长度数据进行 ping/pong：客户端调用 Write 后将 allow_ethernet_data_to_send 设为 False，等待服务端响应。检测到数据后，客户端调用 ReadBytes 读取 MAX_SIZE_WITH_CRC 字节，然后才允许下一次发送。

FClient.Socket.Write(Generate_Sending_ByteArray(data_to_send));
allow_ethernet_data_to_send := False;

if FClient.Socket.CheckForDataOnSource(CHECK_FOR_DATA_MS) then
begin
  SetLength(Buffer, MAX_SIZE_WITH_CRC);
  FClient.IOHandler.ReadBytes(Buffer, MAX_SIZE_WITH_CRC, False);
  allow_ethernet_data_to_send := True;
end;

通信节奏会受服务端响应时间和客户端读取流程影响。ReadBytes 等待数据时会阻塞；CheckForDataOnSource 如何等待和检查，则需要结合 Indy 版本及参数设置确认。GUI 活动如果改变客户端线程获得 CPU 时间的时机，也可能改变下一次请求的到达时间。每次传输的数据量固定，并不意味着请求间隔也固定。

连接和异常处理路径中还调用了 Synchronize：

Synchronize(
  procedure
  begin
    // some output
  end);

Synchronize 会等待主线程执行指定代码。如果主线程正忙于界面处理或文件操作，这些路径中的同步输出可能延后。不过，从给出的代码看，Synchronize 不在每次收发的循环中，只有连接和异常路径会触发。因此，不能据此断定它导致了每次通信延迟。可以检查 GUI 操作期间是否出现连接失败或异常，导致程序进入这些路径。

建议的排查步骤

记录客户端每次收发的时间。在工作线程中记录 Write 开始和结束、CheckForDataOnSource 返回、ReadBytes 完成的时间，以及是否进入异常处理。将记录与 GUI 操作时间对照，确认请求间隔或响应等待是否变化。
记录服务端的收包和发包时间。负载升高时，检查 Ethernet task 是否运行得更频繁、是否反复轮询，以及实际收发的数据量是否变化。仅看任务数量不足以解释 CPU 占用，任务的等待方式和执行频率也会影响负载。
区分通信时序变化和负载测量问题。核对空闲时间统计的计算周期和采样方法，并确认是否把短时峰值当作整个区间的负载。如果 7% 到 90% 是瞬时读数，可以同时记录同一时间段的累计空闲时间和收发计数。
检查 GUI 主线程的同步依赖。搜索所有 Synchronize 调用，确认文件加载、保存和窗口消息处理期间主线程是否会阻塞。如果通信线程需要频繁更新界面，可以减少同步更新，让通信线程记录状态，再由界面按需读取。具体做法取决于程序结构。
检查客户端的等待策略。如果协议始终返回固定长度的响应，可以评估由读取操作承担主要等待，以减少额外轮询。同时确认超时、断线和 TCP 分包情况下仍能正确处理完整数据。TCP 是字节流，固定长度读取需要与协议长度和错误处理相匹配。

注意事项

线程解决的是代码执行位置问题，无法保证调度时延固定；主线程中的同步调用也不会自动变成异步。服务端负载变化还可能来自服务端的等待或统计实现。要定位这次现象，需要把客户端收发时间戳、服务端任务活动和空闲时间统计放到同一时间线上比较。