WebUI项目中非阻塞模式下的内存竞争问题分析与解决方案

内存竞争问题的发现

在WebUI项目的非阻塞WebSocket模式(win->ws_block = false)下，WEBUI_WS_DATA处理会在新线程(_webui_ws_process_thread)中进行，该线程会调用_webui_free_mem()函数释放内存。当多个线程同时进行内存释放操作，而主线程同时调用_webui_malloc()进行内存分配时，可能会出现数据竞争(data race)问题，严重时可能导致程序崩溃。

问题根源分析

这种内存竞争问题的本质在于多线程环境下对内存管理函数的并发访问缺乏同步机制。具体表现为：

1. 主线程负责内存分配(_webui_malloc)
2. 工作线程负责内存释放(_webui_free_mem)
3. 两者可能同时操作内存管理系统中的数据结构

虽然现代编译器和运行时库(如使用-pthreads编译时)会提供线程安全的malloc()和free()实现，但WebUI项目使用了自己的内存管理函数_webui_malloc和_webui_free_mem，这些函数目前没有实现线程同步机制。

解决方案设计

最直接的解决方案是为内存管理函数添加互斥锁(mutex)保护。具体实现方式如下：

static void _webui_free_mem(void * ptr) {
    _webui_mutex_lock(&_webui.mutex_mem);
    // 实际释放内存的操作
    _webui_mutex_unlock(&_webui.mutex_mem);
}

static void * _webui_malloc(size_t size) {
    _webui_mutex_lock(&_webui.mutex_mem);
    // 实际分配内存的操作
    _webui_mutex_unlock(&_webui.mutex_mem);
}

技术考量

1. 锁粒度：使用单个互斥锁保护所有内存操作，简单但可能影响性能。对于高频内存操作场景，可能需要考虑更细粒度的锁策略。

2. 死锁预防：确保在内存分配和释放路径上不会形成循环依赖，特别是在内存分配失败处理路径上。

3. 性能影响：虽然加锁会引入一定开销，但在非极端场景下，这种开销是可以接受的，且远优于数据竞争导致的不确定行为。

实施建议

1. 在WebUI全局结构中添加mutex_mem成员
2. 在库初始化时初始化该互斥锁
3. 在所有内存分配和释放路径上加锁
4. 确保异常路径也能正确释放锁

这种解决方案不仅修复了当前已知的数据竞争问题，还能预防未来可能出现的类似并发访问问题，增强了代码的健壮性。