该编程模式能否解决Excel COM互操作内存泄漏问题？

AI 小北

2026-6-29

Excel VSTO互操作内存管理问题

我不想再加深互联网上关于该话题的神秘感。我看过许多相关文章，有的说绝不调用Marshal.ReleaseComObject，还有所谓的“2点规则”等等。

实际情况是，我的Excel VSTO插件在长时间使用后会变慢甚至崩溃，而我并不经常调用Marshal.ReleaseComObject。我还通过计时器测量发现，通过对象属性获取另一个COM对象时性能大幅下降（例如hyperlink.Name返回极快，hyperlink.Range.Address返回速度慢约214倍），这直观表明必须调用Marshal.ReleaseComObject来处理该COM对象，因为.NET的GC只会回收RCW，而非底层的COM对象。

说了这些，请问采用以下模式的包装类来与Excel互操作，能否让.NET原生GC重新处理所有内存管理工作？请不要提及实现所需的编码工作量（我不在乎，只要能让程序不再变慢崩溃，我就会去做）。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Remoting.Messaging;
using System.Text;
using System.Threading.Tasks;
using Excel = Microsoft.Office.Interop.Excel;
using IRibbon = Microsoft.Office.Core.IRibbonExtensibility;
using App = Microsoft.Office.Interop.Excel.Application;
using Wbs = Microsoft.Office.Interop.Excel.Workbooks;
using Wb = Microsoft.Office.Interop.Excel.Workbook;
using Shs = Microsoft.Office.Interop.Excel.Sheets;
using Ws = Microsoft.Office.Interop.Excel.Worksheet;
using Table = Microsoft.Office.Interop.Excel.ListObject;
using Row = Microsoft.Office.Interop.Excel.ListRow;
using Column = Microsoft.Office.Interop.Excel.ListColumn;
using Cells = Microsoft.Office.Interop.Excel.Range;
using Name = Microsoft.Office.Interop.Excel.Name;
using Chart = Microsoft.Office.Interop.Excel.Chart;
using Shape = Microsoft.Office.Interop.Excel.Shape;
using System.Runtime.InteropServices;

namespace Office.ExcelUtilities
{
    public class ApplicationWrapper
    {
        App _app;
        public ApplicationWrapper(App app)
        {
            _app = app;
        }
        public WorkbookWrapper AddWorkbook()
        {
            Wbs wbs = _app.Workbooks;
            Wb wb = wbs.Add();
            Marshal.ReleaseComObject(wbs);
            return new WorkbookWrapper(wb);
        }
        ~ApplicationWrapper()
        {
            Marshal.ReleaseComObject(_app);
        }
    }
    public class WorkbookWrapper
    {
        Wb _wb = null;
        internal WorkbookWrapper(Wb wb)
        {
            _wb = wb;
        }
        public WorkbookWrapper()
        {
            //just lets client hold this object
            if(_wb == null )
                throw new Exception("You didn't create a workbook right");
        }
        public WorksheetWrapper AddWorksheet(string sheetName)
        {
            Shs wss = _wb.Worksheets;
            Ws ws = wss.Add();
            ws.Name = sheetName;
            Marshal.ReleaseComObject(wss);
            return new WorksheetWrapper(ws);
        }
        ~WorkbookWrapper()
        {
            Marshal.ReleaseComObject(_wb);
        }
    }
    public class WorksheetWrapper
    {
        Ws _ws = null;
        internal WorksheetWrapper(Ws ws)
        {
            _ws = ws;
        }
        public WorksheetWrapper()
        {
            //just lets client hold this object
            if(_ws == null)
                throw new Exception("You didn't create a worksheet right");
        }
        ~WorksheetWrapper()
        {
            Marshal.ReleaseComObject(_ws);
        }
    }
}

显然这并不完整，但您应该明白我的思路。请原谅我对基础互操作类型的重命名。谢谢！

回答

你的包装类模式可以有效将内存管理的负担转移给.NET GC，核心逻辑和优势如下：

即时清理临时COM对象
在包装类的方法中（比如AddWorkbook、AddWorksheet），你已经在使用完临时COM对象（如Wbs、Shs）后立即调用Marshal.ReleaseComObject，避免了这类临时对象的引用计数堆积，从根源上减少底层COM对象的资源占用，这也是解决你观察到的性能下降问题的关键。
通过终结器绑定COM对象生命周期
每个包装类的终结器（如~ApplicationWrapper）会在包装类实例被GC回收时，自动释放对应的根COM对象（如App、Wb、Ws）。只要外部代码不再持有包装类的引用，GC就会在合适时机处理包装类，进而触发底层COM对象的释放，完全符合你依赖.NET原生GC管理内存的需求。
隔离RCW与业务代码
通过包装类封装原生COM对象，外部代码仅持有包装类实例而非直接的RCW引用，让GC可以正常跟踪包装类的生命周期，间接实现对底层COM对象的内存管理，业务代码无需关注Marshal.ReleaseComObject的调用细节。

需要补充的细节优化：

终结器中建议先判断对象是否为null再调用释放，避免重复释放或空引用异常，示例：

~ApplicationWrapper()
{
    if (_app != null)
    {
        Marshal.ReleaseComObject(_app);
        _app = null;
    }
}

后续扩展包装类时，所有从COM对象获取的临时子对象（如Range、Hyperlink等）都要遵循相同的即时释放规则，避免遗漏导致的资源泄漏。

这种模式本质上是将手动释放COM对象的逻辑封装到包装类内部，让业务代码完全依赖GC的生命周期管理来处理内存问题，能够有效解决你的插件变慢、崩溃的问题。

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

该编程模式能否解决Excel COM互操作内存泄漏问题？

回答 #

回答