Android Native 内存泄漏系统化解决方案

简介

因为工作业务涉及到大量的Android机型的C++开发，涉及一些Android平台上 C++ 内存泄漏问题的分析、定位的开发难题。针对解决问题在这里提供一些个人涉及到的解决思路。

Android中Bionic的malloc_debug模块对内存分配函数的监控及统计是比较完善的，但是栈回溯在Android体系下缺乏高效的方式。随着Android的发展，Google也提供了栈回溯的一些分析方法，但是这些方案存在下面几个问题：

1.栈回溯的环节都使用的libunwind，这种获取方式消耗较大，在Native代码较多的情况下，频繁调用会导致应用很卡（主要cpu、内存限制较多），而监控所有内存操作函数的调用栈正需要高频的调用libunwind的相关功能。

2.有ROM要求限制，给日常开发测试带来不便。

3.用命令行或者DDMS进行操作，每排查一次需准备一次环境，手动操作，最终结果也不够直观，同时缺少对比分析。

一、栈回溯加速

Android平台上主要采用libunwind来进行栈回溯，可以满足绝大多数情况。但是libunwind实现中的全局锁及unwind table解析，会有性能损耗，在多线程频繁调用情况下会导致应用变卡，无法使用。

加速原理

编译器的-finstrument-functions编译选项支持编译期在函数开始和结尾插入自定义函数，在每个函数开始插入对__cyg_profile_func_enter的调用，在结尾插入对__cyg_profile_func_exit的调用。这两个函数中可以获取到调用点地址，通过对这些地址的记录就可以随时获取函数调用栈了。

插桩后效果示例：

 

这里需要格外注意，某些不需要插桩的函数可以使用__attribute__((no_instrument_function))来向编译器声明。

如何记录这些调用信息？我们想要实现这些信息在不同的线程之间读取，而且不受影响。一种办法是采用线程的同步机制，比如在这个变量的读写之处加临界区或者互斥量，但是这样又会影响效率了。

能不能不加锁？这时就想到了线程本地存储，简称TLS。TLS是一个专用存储区域，只能由自己线程访问，同时不存在线程安全问题，符合这里的场景。

于是采用编译器插桩记录调用栈，并将其存储在线程局部存储中的方案来实现栈回溯加速。具体实现如下：

1.利用编译器的-finstrument-functions编译选项在编译阶段插入相关代码。

2.TLS中对调用地址的记录采用数组+游标的形式，实现最快速度的插入、删除及获取。

定义数组+游标的数据结构：

typedef struct {
    void* stack[MAX_TRACE_DEEP];
    int current;
} thread_stack_t;

初始化TLS中thread_stack_t的存储key：

static pthread_once_t sBackTraceOnce = PTHREAD_ONCE_INIT;
 
static void __attribute__((no_instrument_function))
destructor(void* ptr) {
    if (ptr) {
        free(ptr);
    }
}
 
static void __attribute__((no_instrument_function))
init_once(void) {
    pthread_key_create(&sBackTraceKey, destructor);
}

初始化thread_stack_t放入TLS中：

get_backtrace_info() {
    thread_stack_t* ptr = (thread_stack_t*) pthread_getspecific(sBackTraceKey);
    if (ptr)
        return ptr;
 
    ptr = (thread_stack_t*)malloc(sizeof(thread_stack_t));
    ptr->current = MAX_TRACE_DEEP - 1;
    pthread_setspecific(sBackTraceKey, ptr);
    return ptr;
}

3.实现__cyg_profile_func_enter和__cyg_profile_func_exit，记录调用地址到TLS中。

void __attribute__((no_instrument_function))
__cyg_profile_func_enter(void* this_func, void* call_site) {
    pthread_once(&sBackTraceOnce, init_once);
    thread_stack_t* ptr = get_backtrace_info();
    if (ptr->current > 0)
        ptr->stack[ptr->current--] = (void*)((long)call_site - 4);
}
 
void __attribute__((no_instrument_function))
__cyg_profile_func_exit(void* this_func, void* call_site) {
    pthread_once(&sBackTraceOnce, init_once);
    thread_stack_t* ptr = get_backtrace_info();
    if (++ptr->current >= MAX_TRACE_DEEP)
        ptr->current = MAX_TRACE_DEEP - 1;
}
}

__cyg_profile_func_enter的第二个参数call_site就是调用点的代码段地址，函数进入的时候将它记录到已经在TLS中分配好的数组中，游标ptr->current左移，待函数退出游标ptr->current右移即可。

逻辑示意图：

 

记录方向和数组增长方向不一致是为了对外提供的获取栈信息接口更简洁高效，可以直接进行内存copy以获取最近调用点的地址在前、最远调用点的地址在后的调用栈。

4.提供接口获取栈信息。

get_tls_backtrace(void** backtrace, int max) {
    pthread_once(&sBackTraceOnce, init_once);
    int count = max;
    thread_stack_t* ptr = get_backtrace_info();
    if (MAX_TRACE_DEEP - 1 - ptr->current < count) {
        count = MAX_TRACE_DEEP - 1 - ptr->current;
    }
    if (count > 0) {
        memcpy(backtrace, &ptr->stack[ptr->current + 1], sizeof(void *) * count);
    }
    return count;
}

5.将上面逻辑编译为动态库，其他业务模块都依赖于该动态库编译，同时编译flag中添加-finstrument-functions进行插桩，进而所有函数的调用都被记录在TLS中了，使用者可以在任何地方调用get_tls_backtrace(void** backtrace, int max)来获取调用栈。

效果对比（采用Google的benchmark做性能测试）：

• libunwind单线程

• TLS方式单线程获取

• libunwind 10个线程

• TLS方式 10个线程

从上面几个统计图可以看出单线程模式下该方式是libunwind栈获取速度的10倍，10个线程情况下是libunwind栈获取速度的50-60倍，速度大幅提升。

优缺点

• 优点: 速度大幅提升，满足更频繁栈回溯的速度需求。
• 缺点: 编译器插桩，体积变大，不能直接作为线上产品使用，只用于内存测试包。这个问题可以通过持续集成的手段解决，每次项目出库将C++项目产出普通库及对应的内存测试库。

总结：其实这就是实现一种打桩的方式，在内存申请和释放时做标记，类似asan的实现。但是需要注意内存池的使用以及一些内存优化组件会影响插桩的结果，导致影响最终统计。