C++ Builder 中 SOAP Server 的 TRemotable 结构内存管理问题

兄弟，我太懂你这种看着服务器内存一路飙升却束手无策的焦虑了！之前用C++ Builder做SOAP服务的时候，也踩过TRemotable内存管理的大坑，给你唠唠踩坑后总结的解决办法：

首先得搞明白一个核心规则：TRemotable对象的所有权不归你管！ 当你把它作为SOAP方法的返回值返回后，这个对象的生命周期就完全交给SOAP调用框架了。你之前在try/finally里手动调用delete或者Free()触发异常，就是因为你抢了框架的活儿——框架还拿着这个对象的引用呢，你先给释放了，必然会触发内存访问违规。

那为什么你看到ULONG STDMETHODCALLTYPE Release() { return TInvokableClass::_Release()被调用了，内存还是没降下来？大概率是这两个原因：

常见问题1：框架的内存回收是延迟的 #

SOAP框架不会在调用_Release()后立刻释放内存，它可能会把待释放的对象攒成一批，等系统空闲的时候再统一清理。你可以多跑几十上百次请求，或者等个几分钟再看内存，说不定就会正常回落了。

常见问题2：你在TRemotable里自己分配了子资源，框架不会帮你释放 #

这是最容易被忽略的内存泄漏点！框架只会负责TRemotable对象本身的内存，但如果你在自定义的TRemotable子类里加了自己的动态分配资源（比如new出来的子对象、GetMem分配的缓冲区、动态数组），这些框架一概不管，必须你自己在析构函数里手动释放。

举个例子，假设你自定义了一个TUserInfoRemotable，里面有个动态分配的TAddress对象，那你得这么写析构函数：

__fastcall TUserInfoRemotable::~TUserInfoRemotable()
{
    // 释放自己手动分配的子对象
    if (FUserAddress) delete FUserAddress;
    // 如果有动态数组，也要手动释放
    delete[] FUserPhoneNumbers;
    // 手动分配的内存缓冲区也不能忘
    if (FExtraBuffer) FreeMem(FExtraBuffer);
}

给你几个具体的落地建议 #

• 绝对不要手动释放SOAP返回的TRemotable对象：不管是delete、Free()还是其他方式，都别碰！框架会在客户端接收完响应、连接关闭后，自动调用_Release()来处理。
• 确保返回的是堆上分配的TRemotable对象：SOAP方法返回的必须是用new在堆上创建的对象指针，绝对不能返回栈上对象的指针，不然框架根本没法正确管理它的生命周期。比如：

  TUserInfoRemotable* __fastcall TMySoapService::GetUserInfo()
  {
      // 用new创建堆上的对象，框架会接管
      TUserInfoRemotable* result = new TUserInfoRemotable();
      // 给对象赋值...
      result->UserName = L"张三";
      return result;
  }
  

• 调试确认对象是否真的被析构：你可以在TRemotable子类里重写_Release()方法，加个日志或者断点，看看引用计数是不是最终降到0了：

  ULONG STDMETHODCALLTYPE TUserInfoRemotable::_Release()
  {
      ULONG refCount = TRemotable::_Release();
      // 输出调试日志，看引用计数变化
      if (refCount == 0)
      {
          OutputDebugString(L"TUserInfoRemotable 即将被析构");
      }
      return refCount;
  }
  

  如果引用计数一直没到0，说明还有其他地方不小心调用了AddRef()持有了这个对象的引用，得顺着代码找出来。

我当初就是因为在TRemotable里加了个动态数组没在析构里释放，结果内存涨得跟坐火箭似的，改完析构函数后内存就稳定下来了，你可以照着排查试试！

内容来源于stack exchange