Eigen库大型矩阵堆内存的释放时机及调试观测方法

Eigen动态矩阵的内存释放逻辑和自研Tensor类没有本质区别，不存在特殊的延迟释放机制，观测不到析构流程本质是调试方法和认知偏差。

调试认知的常见误区 #

• 在VS2019 Debug模式下，打在作用域闭合}上的断点，命中时机是该行可执行指令的最起始位置。编译器会把作用域内所有局部对象的析构代码隐式插入在}对应指令的前面，但断点命中时，这些析构代码还完全没有执行。
• 之前测试自研Tensor时能观测到析构触发，是因为单步跨过}行时，执行流进入了自己编写的析构函数；如果断点停在}上不操作，执行流其实同样还没跑到Tensor的析构逻辑。
• Eigen的析构函数为纯inline实现，VS默认Debug配置下会把这部分代码直接内联展开到调用位置，不会提供跳转到独立析构函数上下文的调试入口，因此单步时无法观测到进入析构的流程。

Eigen动态矩阵的实际内存释放逻辑 #

• MatrixXf这类动态矩阵的内部结构和自研Tensor几乎完全一致：类对象本身仅保存矩阵行列数、以及指向连续堆内存的裸指针，构造时通过new/malloc申请对应大小的堆内存，析构时通过对应的delete/free释放这块内存。
• 代码中m3 = m1 + m2的表达式，Eigen通过表达式模板将计算优化为：仅为m3分配一次堆内存，加法计算结果直接写入这块内存；计算过程中产生的临时加法表达式对象不持有任何堆内存，析构为空操作，无额外内存开销。
• 所有堆内存的释放时机完全遵循C++对象生命周期规则：当对应的MatrixXf对象离开所在作用域，执行完析构函数的瞬间，对应的堆内存就会立刻归还给系统，默认配置下没有内置内存池、缓存或延迟释放逻辑。

正确观测内存释放流程的方法 #

• 直接在Eigen的析构函数内部打断点：定位到Eigen中PlainObjectBase类的析构函数实现位置，在函数体内部打断点，作用域结束时执行流一定会准确停在这个断点上，可以清晰看到每个矩阵对象依次释放内存的过程。
• 用进程内存指标做无调试器验证：在块作用域前后分别读取当前进程的工作集内存大小，可观察到：构造3个300400的float矩阵时，进程内存对应上涨（33004004字节≈14MB），执行流离开块作用域时，这部分内存立刻被释放，回到块之前的内存水平。
• 调整VS调试配置重新编译：在项目Debug设置中关闭“内联函数展开”，重新编译后，原本被内联的Eigen析构函数会成为独立的函数上下文，此时在}位置单步执行，就和观测自研Tensor类一样，能看到执行流依次进入每个矩阵对象的析构函数。

补充提示：自研Tensor类的内存管理存在未定义行为：构造时用new T[len]分配内存，析构时却调用free(data)，VC Debug模式下未触发崩溃只是分配器实现的巧合，应该用delete[] data和new[]匹配才符合标准。

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