本文探讨了glibc内存分配导致的内存泄露问题，详细介绍了glibc的内存分配机制，包括arena和多线程锁竞争。通过设置`MALLOC_ARENA_MAX`来控制arena数量，缓解了内存增长。然而，这并未完全解决问题，进一步尝试了tcmalloc和jemalloc，最终jemalloc通过优化的内存管理和碎片控制，有效地控制了内存波动。
malloc ? 这是申请内存的函数啊，为什么要申请这么多呢？难道没有释放？ 于是想到用 pmap 命令看一下内存映射情况。
Pmap 提供了进程的内存映射，pmap 命令用于显示一个或多个进程的内存状态。其报告进程的地址空间和内存状态信息
执行了以下命令：
pmap -x 1 | sort -n -k3
复制代码
发现了一些端倪：
有一些 64M 左右的内存分配，且越来越多。
glibc
搞不懂了，于是 google 了一下。发现是有这一类问题由于涉及许多底层基础知识，这里就大概解析一下，有兴趣的读者可以查询更多资料了解：
目前大部分服务端程序使用 glibc 提供的 malloc/free 系列函数来进行内存的分配。
Linux 中 malloc 的早期版本是由 Doug Lea 实现的，它有一个严重问题是内存分配只有一个分配区（arena），每次分配内存都要对分配区加锁，分配完释放锁，导致多线程下并发申请释放内存锁的竞争激烈。arena 单词的字面意思是「舞台；竞技场」
于是修修补补又一个版本，你不是多线程锁竞争厉害吗，那我多开几个 arena，锁竞争的情况自然会好转。
Wolfram Gloger 在 Doug Lea 的基础上改进使得 Glibc 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】
扫一扫
1364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
