使用自定义malloc实现配合Intel MKL时的内存分配拦截异常问题

兄弟，我之前踩过几乎一模一样的MKL内存分配坑，给你梳理几个大概率能解决问题的方向：

1. 先确认mkl_disable_fast_mm()的调用时机绝对正确 #

MKL的快速内存管理模块是在第一次调用MKL函数时就完成初始化的，如果你在调用任何MKL矩阵操作（比如cblas_dgemm之类的函数）之后才调用mkl_disable_fast_mm()，那完全没用——MKL已经初始化了自己的内存池，后续分配都会走它内部的逻辑。

正确的姿势是：把mkl_disable_fast_mm()放在程序的最开头，比如main()函数的第一行，甚至早于任何全局变量的初始化（如果你的全局变量会隐式调用MKL的话）。

2. 用环境变量强制禁用MKL快速内存管理 #

有时候代码里的函数调用可能因为编译优化、MKL版本兼容性等原因不生效，这时候直接用环境变量来强制禁用更靠谱：

export MKL_DISABLE_FAST_MM=1

启动程序前先设置这个环境变量，再运行你的程序，看看MKL的内存分配会不会触发你的自定义malloc。

3. 检查--wrap是否真的覆盖了所有malloc入口 #

有些情况下MKL可能直接调用了底层系统调用（比如mmap、sbrk）而不是标准malloc，或者编译器在高优化级别下把malloc调用内联了，导致你的--wrap没生效。你可以用strace跟踪一下程序的系统调用，看看MKL到底在调用什么分配函数：

strace -e trace=memory ./your_program

如果发现MKL用的不是malloc，那你可能需要同时包装那些底层调用，或者换用MKL官方的内存替换接口。

4. 改用MKL官方支持的内存分配替换方案 #

其实MKL本身就提供了自定义内存分配的接口，比 linker 的--wrap更可靠，不会出现绕开的情况。你只需要实现自己的mkl_malloc和mkl_free，然后告诉MKL用你的版本：

#include "mkl_service.h"

void* my_custom_malloc(size_t size) {
    // 这里写你的自定义内存分配逻辑
    return ...;
}

void my_custom_free(void* ptr) {
    // 这里写你的自定义内存释放逻辑
    ...;
}

int main() {
    // 先设置自定义内存分配器
    mkl_set_memory_library(my_custom_malloc, my_custom_free);
    // 再调用任何MKL函数
    ...
    return 0;
}

这种方法是MKL官方推荐的，兼容性拉满，绝对不会出现MKL绕开你的分配器的情况。

备注：内容来源于stack exchange，提问作者daroo