C#封装多相似COM对象时Func调用性能与GC引用问题

我正在开发基于.NET的托管应用，程序将加载并运行于COM服务器内部，开发过程中需要与COM服务器提供的多个COM接口/对象进行交互。这些COM接口包含一组签名、行为完全一致的方法，仅内部上下文存在差异，互操作库中的COM接口定义示例如下：

interface IComInterface1 {
    Object GetObject(String str, Int32 someInt);
    // more methods are defined
}
interface IComInterface2 {
    Object GetObject(String str, Int32 someInt);
    // more methods are defined
}

上述COM原生方法需要额外的编码处理（包括资源分配与释放、方法调用时序保证等），且这套处理逻辑对两个COM接口完全相同。

我的开发目标是编写一个统一的C#托管对象，隐藏COM接口的内部处理逻辑，仅暴露业务所需的方法，消除托管类的重复实现。我将该目标拆分为两项任务：

• 创建托管类，将每个共享方法以委托形式存储为私有字段
• 添加面向业务逻辑的公共方法，封装COM特有的处理逻辑（资源分配/释放、调用时序保证等）

两类接口的方法处理逻辑完全一致，初步给出的实现代码如下：

class MyManagedWrapper {
    readonly Func<String, Int32, Object> _getObject;
    // <...> additional funcs for every shared method

    public MyManagedWrapper(IComInterface1 comObj) {
        _getObject = comObj.GetObject;
        // assign more methods to funcs
    }
    public MyManagedWrapper(IComInterface2 comObj) {
        _getObject = comObj.GetObject;
        // assign more methods to funcs
    }

    public String GetUsefulData() {
        // 此处无需感知当前使用的具体COM接口，仅调用存储的委托即可
        // 内部统一封装COM管理逻辑，返回业务逻辑需要的结果
    }
}

该封装对象的生命周期与COM服务器生命周期一致。经确认该方案可正常运行，但当前对接的COM服务器对性能较为敏感，需要确保新增逻辑的性能开销尽可能小，运行时不能使用显式或隐式的反射，现提出以下两个技术问题：

1. 与直接调用COM对象方法相比，Func委托调用是否会产生额外的性能损耗？
2. 在构造函数中将COM对象的方法赋值给委托后，是否仍需要持有传入的COM对象引用，避免其在运行时被垃圾回收？

1. Func委托调用的性能影响 #

委托调用的额外开销极低，完全不会成为该场景下的性能瓶颈，且全程无反射参与，符合性能约束要求：

• .NET中委托是类型安全的函数指针封装，绑定实例方法时会直接存储方法入口点和目标实例引用，调用过程是运行时原生支持的直接跳转，不存在任何反射或动态查找逻辑。
• 委托调用的额外开销仅为单次指针解引用，属于纳秒级损耗，对比COM互操作本身的RCW（运行时可调用包装）封送、跨COM上下文切换的固有开销，占比可以忽略不计。
• 由于委托字段标记为readonly，JIT编译器可以对该调用做进一步优化，部分场景下可以做到接近直接调用的性能表现。

2. COM对象引用的持有问题 #

不需要额外持有传入的COM对象引用，委托本身会自动保证目标对象不会被GC回收：

• 当你将COM实例的方法绑定到Func委托时，委托内部会自动持有目标实例（即对应COM对象的RCW包装）的强引用。只要MyManagedWrapper实例处于存活状态，其内部的_getObject等委托字段没有被回收，该RCW就会始终处于被引用状态，GC不会将其回收。
• RCW本身会正确维护对应COM对象的引用计数，只要RCW不被回收，COM对象就不会提前释放，不会出现调用时对象已失效的问题。
• 由于使用readonly修饰委托字段，构造完成后委托的目标实例不会被修改，不存在引用意外丢失的风险，额外存储COM对象引用属于完全冗余的操作。

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