释放 Solaris/Linux 中分配的内存

Question

我编写了一个小程序，并在 Solaris/Linux 平台下编译它，以测量将此代码应用于我的应用程序的性能。

程序是这样编写的，最初使用sbrk(0)系统调用，我获取了堆区域的基地址。之后，我使用 malloc 系统调用分配了 1.5 GB 内存，然后使用 memcpy 系统调用将 1.5 GB 内容复制到分配的内存区域。然后，我释放了分配的内存。

释放后，我再次使用sbrk(0)系统调用来查看堆大小。

这是我有点困惑的地方。在 Solaris 中，即使我释放了分配的内存（接近 1.5 GB），进程的堆大小仍然很大。但我在Linux中运行相同的应用程序，释放后，我发现进程的堆大小等于分配前的堆内存大小1.5 GB。

我知道 Solaris 不会立即释放内存，但我不知道如何调整 Solaris 内核以在 free() 系统调用后立即释放内存。

为什么我在Linux下没有遇到同样的问题？

Answer 1

我得到了我提出的问题的答案。

应用程序内存分配器：

C 和 C++ 开发人员必须手动管理内存分配和释放内存。默认内存分配器位于 libc 库中。

库
请注意，执行 free() 后，释放的空间可供应用程序进一步分配，而不返回给系统。仅当应用程序终止时，内存才会返回给系统。这就是应用程序的进程大小通常永远不会减小的原因。但对于长时间运行的应用程序，应用程序进程大小通常保持稳定状态，因为释放的内存可以重用。如果情况并非如此，则应用程序很可能正在泄漏内存，也就是说，分配的内存已被使用，但不再使用时从未释放，并且应用程序不会跟踪指向分配的内存的指针 - 基本上丢失了。

当频繁发生并发 malloc 或 free 操作时，libc 中的默认内存分配器不适合多线程应用程序，特别是对于多线程 C++ 应用程序。这是因为创建和销毁 C++ 对象是 C++ 应用程序开发风格的一部分。当使用默认的 libc 分配器时，堆由单个堆锁保护，导致默认分配器由于 malloc 或 free 操作期间的严重锁争用而无法针对多线程应用程序进行扩展。使用 Solaris 工具很容易检测到此问题，如下所示。

首先，使用 prstat -mL -p 查看应用程序是否在锁上花费了很多时间；看看LCK栏目。例如：

-bash-3.2# prstat -mL -p 14052
   PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID
 14052 root     0.6 0.7 0.0 0.0 0.0  35 0.0  64 245  13 841   0 test_vector_/721
 14052 root     1.0 0.0 0.0 0.0 0.0  35 0.0  64 287   5 731   0 test_vector_/941
 14052 root     1.0 0.0 0.0 0.0 0.0  35 0.0  64 298   3 680   0 test_vector_/181
 14052 root     1.0 0.1 0.0 0.0 0.0  35 0.0  64 298   3  1K   0 test_vector_/549
 ....

它表明应用程序花费了大约 35% 的时间来等待锁。

然后，使用 plockstat(1M) 工具查找应用程序正在等待的锁。例如，跟踪进程 ID 14052 的应用程序 5 秒，然后使用 c++filt 实用程序过滤输出以分解 C++ 符号名称。 （c++filt 实用程序随 Sun Studio 软件提供。）如果应用程序不是 C++ 应用程序，则不需要通过 c++filt 进行过滤。

-bash-3.2#  plockstat -e 5 -p 14052 | c++filt
Mutex block
Count     nsec   Lock                         Caller
-------------------------------------------------------------------------------
 9678 166540561 libc.so.1‘libc_malloc_lock   libCrun.so.1‘void operator 
 delete(void*)+0x26

 5530 197179848 libc.so.1‘libc_malloc_lock   libCrun.so.1‘void*operator 
 new(unsigned)+0x38

......

从前面的内容可以看出，堆锁 libc_malloc_lock 的竞争非常激烈，并且很可能是导致扩展问题的原因。 libc 分配器的扩展问题的解决方案是使用改进的内存分配器，例如 libumem 库。

另请访问：http://developers.sun.com/solaris/articles/solaris_memory.html

感谢所有尝试回答我的问题的人，
桑托什。