在阅读本文之前，需要先对MT和MD运行时库有所了解，参考：《理解C/C++运行时库》。另外建议先阅读《Windows内存体系》系列文章的前几篇文章，对“虚拟内存”，“堆”，“内存API体系结构”有所了解。


《Windows核心编程 第五版》第19章 DLL基础（511页）中给出了一个建议：“当一个MT版本的模块如果提供一个内存分配函数的时候，它必须同时提供另一个用来释放内存的函数。”。说得更加直白一点就是，“对于MT的模块，不要跨模块进行内存释放。”。但是核心编程这本书上面没有具体分析原因，本文就来分析具体的原因。



一、为什么不同堆分配的内存块不能相互释放？

Windows的堆管理器对每个进程都维护了多个“堆”，我们从每个“堆”中分配处理的内存块的地址都不一样。所以我们不能将从“堆A”中分配出来的内存块拿到“堆B”中，让“堆B”来释放，这样就会导致程序异常。



如上图，通过malloc函数从“堆A”中分配100字节内存块，内存块地址为0x123456；从“堆B”中分配100字节内存块，内存块地址为0x345678. 

如果将0x123456这个地址拿到“堆B”中去释放，势必会导致异常，因为“堆B”中没有这地址。

那么我们是不是可以使用HeapFree函数来释放hHeap参数指定的“堆”中的任何内存块了。答案是：不能。 

回忆前面介绍的HeapFree函数，



BOOL HeapFree(
  HANDLE hHeap,
  DWORD dwFlags,
  LPVOID lpMem
);

这个函数只要求传入了内存块的起始地址指针，但没有要求传入需要释放的内存块的大小，那么该函数是如何知道起始地址指针指向的内存块的大小了？ 

我们可以简单的理解为，HeapAlloc函数每次分配内存块的时候都会额外分配一点空间用于存储一个结构体，该结构体中存储了本次分配的内存块的大小等信息。大致如下图： 


所以，HeapFree函数首先会通过lpMem指针计算出“结构体”的地址，然后从结构体中获取到分配的内存块的具体大小，最后执行释放操作。

基于上面的原因，我们不能在HeapFree函数的lpMem参数中传入随意的地址，因为该地址处可能没有存储用于存放内存块信息的结构体，所以释放操作就会失败。free函数也一样，因为free函数内部也是调用的HeapFree函数。



二、为什么MT模块内存不能相互释放，而MD的却可以？



我们先分析为什么MT模块的内存间相互释放会崩溃。

现在有2个模块（A.dll和B.dll）都是使用MT运行时库，即加载的静态库libcmt.lib（可以参考《理解C/C++运行时库》），在A.dll中使用malloc分配100字节的内存，malloc返回的内存地址为0x123456。然后将该地址传给B.dll，在B.dll中调用free函数来释放这个内存。如图： 


从《Windows内存体系（7） – 堆》我们知道，DLL在启动代码_DllMainCRTStartup中会建立一个“堆”（堆句柄存放在_crtheap变量中），所以A.dll和B.dll中都会有一个crt堆。

为了区分，我们将A.dll中的crt堆称作_crtheap_A，B.dll中的crt堆称作_crtheap_B。

从上面图可以看到，A.dll中malloc的内存拿到B.dll去中去free，就相当于从堆_crtheap_A中分配的内存拿到另一个堆_crtheap_B中的释放。第一节已经解释了为什么不能这样做了。

现在我们分析为什么MD模块的内存间相互释放不会崩溃。

还是2个模块（A.dll和B.dll），但是现在他们都是使用MD运行时库，即加载的动态库msvcr100.dll（可以参考《理解C/C++运行时库》），程序的代码的过程和上面一样，还是在A.dll中使用malloc分配100字节的内存，malloc返回的内存地址为0x123456。然后将该地址传给B.dll，在B.dll中调用free函数来释放这个内存。但是这个时候程序却不会崩溃，通过下面的图我们基本可以明白原因了，如图： 


因为A、B两个dll都是链接的·msvcr100.dll·，同一个dll在一个进程只会被加载一次，所以进程中只会有一个crt堆（_crtheap），malloc和free都是运行时库提供的函数，所以都会调到运行时库里面去，然后从运行时库里面的_crtheap分配和释放内存块。因为分配和释放都是在同一个堆上，所以不会崩溃。

版权所有，转载请注明出处，谢谢！
http://blog.csdn.net/walkinginthewind/article/details/7069176

我们都知道，C语言中要动态申请内存需要调用malloc函数，释放动态内存需要调用free函数。内存的申请与释放都是在堆（Heap）上进行的。当然，所谓的内存，都是虚拟内存。
C语言中的malloc和free，在windows中主要是通过HeapAlloc和HeapFree来实现的。

每个进程在初始化的时候，会调用RtlProcessHeap()函数构造进程的HEAP对象，这个对象用来管理进程的堆内存。

当我们使用malloc申请一段内存时，我们要指定大小，但是使用free释放的时候，只是指定要释放的内存起始地址即可。

如：

int * p = (int*)malloc(100 * sizeof(int)); // 申请100个int大小的一段内存

... // 其他操作

free(p); // 释放p所指向的内存

那么我们必定会产生疑问，系统是怎么知道或记录给定指针所指向的动态内存的大小的呢？

windows的实现方案很简单，就是在每一段动态内存的上部保存该段内存的大小等相关信息，这也就说明了，当我们使用堆内存时，会有额外的系统开销，windows中是通过如下一个结构体来保存相关信息的：

（WRK中的定义，在XP和win7下测试符合，win2000源码中的定义与此不同）
typedef struct _RTL_HEAP_ENTRY {
    SIZE_T Size; // 指示该段内存的大小
    USHORT Flags;
    USHORT AllocatorBackTraceIndex;
    union {
        struct {
            SIZE_T Settable;
            ULONG Tag;
        } s1;   // All other heap entries
        struct {
            SIZE_T CommittedSize;
            PVOID FirstBlock;
        } s2;   // RTL_SEGMENT
    } u;
} RTL_HEAP_ENTRY, *PRTL_HEAP_ENTRY;


因为free释放内存的时候要依赖于该结构体中的信息，所以对于不是malloc返回的地址或已被释放过的地址，该结构的内容一般是不正确的，这也就是free会出错的原因。

如：

int * p = (int*)malloc(100 * sizeof(int)); // 申请100个int大小的一段内存

... // 其他操作

free(p); // 释放p所指向的内存

free(p); // 再次释放已释放的内存，会出错，因为RTL_HEAP_ENTRY已经不再有效。

所以当我们释放指针所指的动态内存后，我们最好将指针赋值为NULL，因为free一个值为NULL的地址，不会有任何错误。

再如：

int * p = (int*)malloc(100 * sizeof(int)); // 申请100个int大小的一段内存

... // 其他操作

//比如我们想释放部分内存

int * q = p + 20;

free(q); // 释放q所指向的内存，会出错，因为地址q所对应的RTL_HEAP_ENTRY结构体信息是无效的

所以free只能释放malloc返回的有效地址。

下面通过一个程序验证一下：
#include<stdio.h>
#include<windows.h>
typedef struct _RTL_HEAP_ENTRY {
    SIZE_T Size;
    USHORT Flags;
    USHORT AllocatorBackTraceIndex;
    union {
        struct {
            SIZE_T Settable;
            ULONG Tag;
        } s1;
        struct {
            SIZE_T CommittedSize;
            PVOID FirstBlock;
        } s2;
    } u;
} RTL_HEAP_ENTRY, *PRTL_HEAP_ENTRY;
int main()
{
	PRTL_HEAP_ENTRY pHeapEntry;
	int *p;
	for(int i = 0; i < 1000; i++)
	{
		p=(int*)malloc(i);
		pHeapEntry=(PRTL_HEAP_ENTRY(p)-1);
		printf("i: %d, size: %d\n", i, pHeapEntry->Size);
		free(p);
	}
	return 0;
}
输出结果是：

i: 0, size: 0

i: 1, size: 1

i: 2, size: 2

...

i: 999, size: 999


总结：本文根据windows源码简单的分析了windows对C库函数free的实现中对内存大小信息的记录方法。

在CentOS7上手动释放内存cache和脚本定时释放

前言

总有很多朋友对于Linux的内存管理有疑问，当在Linux下频繁存取文件后，物理内存会很快被用光，当程序结束后，内存不会被正常释放，而是一直作为caching。这个问题，貌似有不少人在问，不过都没有看到有什么很好解决的办法。

场景介绍

一、通常情况

　　先来说说free命令。

[root@instance-2a85072t ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           1999         152         251          32        1595        1619
Swap:             0           0           0
[root@instance-2a85072t ~]#


提示：

total 内存总数

used 已经使用的内存数

free 空闲的内存数

shared 多个进程共享的内存总额

buffers Buffer Cache和cached Page Cache 磁盘缓存的大小

-buffers/cache (已用)的内存数:used - buffers - cached

+buffers/cache(可用)的内存数:free + buffers + cached

可用的memory=free memory+buffers+cached


有了这个基础后，可以得知，我现在used为152MB，free为251MB，buffer和cached为1595MB。那么我们来看看，如果我执行复制文件，内存会发生什么变化。 

[root@instance-2a85072t ~]# cp -r /etc test/
[root@instance-2a85072t ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           1999         152         187          32        1658        1618
Swap:             0           0           0
[root@instance-2a85072t ~]#

在我命令执行结束后，used为152MB，free为187MB，buff/cache为1658MB，天呐，都被cached吃掉了。别紧张，这是为了提高文件读取效率的做法。

　　为了提高磁盘存取效率，Linux做了一些精心的设计，除了对dentry进行缓存（用于VFS，加速文件路径名到inode的转换），还采取了两种主要Cache方式：Buffer Cache和Page Cache。前者针对磁盘块的读写，后者针对文件inode的读写。这些Cache有效缩短了 I/O系统调用（比如read，write，getdents）的时间。

　　那么有人说过段时间，linux会自动释放掉所用的内存。等待一段时间后，我们使用free再来试试，看看是否有释放？

[root@instance-2a85072t ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           1999         152         187          32        1659        1618
Swap:             0           0           0
[root@instance-2a85072t ~]#

似乎没有任何变化。（实际情况下，内存的管理还与Swap有关）那么我能否手动释放掉这些内存呢？回答是可以的。

手动释放缓存

/proc是一个虚拟文件系统，我们可以通过对它的读写操作做为与kernel实体间进行通信的一种手段。也就是说可以通过修改/proc中的文件，来对当前kernel的行为做出调整。那么我们可以通过调整/proc/sys/vm/drop_caches来释放内存。操作如下：

首先，/proc/sys/vm/drop_caches的值，默认为0。

[root@instance-2a85072t ~]# cat /proc/sys/vm/drop_caches
0
[root@instance-2a85072t ~]#

手动执行sync命令（描述：sync 命令运行 sync 子例程。如果必须停止系统，则运行sync 命令以确保文件系统的完整性。sync 命令将所有未写的系统缓冲区写到磁盘中，包含已修改的 i-node、已延迟的块 I/O 和读写映射文件）

[root@instance-2a85072t ~]# sync

将/proc/sys/vm/drop_caches值设为3

[root@instance-2a85072t ~]# echo 3 > /proc/sys/vm/drop_caches
[root@instance-2a85072t ~]# cat /proc/sys/vm/drop_caches
3
[root@instance-2a85072t ~]#

再来运行free命令，会发现现在的used为150MB，free为1740MB，buff/cache为108MB。那么有效的释放了buffer和cache。

[root@instance-2a85072t ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           1999         150        1740          32         108        1698
Swap:             0           0           0
[root@instance-2a85072t ~]#

深入分析

有关/proc/sys/vm/drop_caches的用法在下面进行了说明。

/proc/sys/vm/drop_caches (since Linux 2.6.16)
Writing to this file causes the kernel to drop clean caches,dentries and inodes from memory, causing that memory to become free.
To free pagecache, use echo 1 > /proc/sys/vm/drop_caches;
to free dentries and inodes, use echo 2 > /proc/sys/vm/drop_caches;
to free pagecache, dentries and inodes, use echo 3 > /proc/sys/vm/drop_caches.
Because this is a non-destructive operation and dirty objects are not freeable, the user should run sync first.

上述说明就长期以来很多用户对Linux内存管理方面的疑问，给出了一个比较“直观”的回复，我更觉得有点像是核心开发小组的妥协。对于是否需要使用这个值，或向用户提及这个值，我是有保留意见的：

从man可以看到，这值从2.6.16以后的核心版本才提供，也就是老版的操作系统，如红旗DC 5.0、RHEL 4.x之前的版本都没有；

　　若对于系统内存是否够用的观察，我还是原意去看swap的使用率和si/so两个值的大小；

　　用户常见的疑问是，为什么free这么小，是否关闭应用后内存没有释放？但实际上，我们都知道这是因为Linux对内存的管理与Windows不同，free小并不是说内存不够用了，应该看的是free的第二行最后一个值：-/+ buffers/cache: 58 191，这才是系统可用的内存大小。

　　实际项目中告诉我们，如果因为是应用有像内存泄露、溢出的问题，从swap的使用情况是可以比较快速可以判断的，但free上面反而比较难查看。相反，如果在这个时候，我们告诉用户，修改系统的一个值，“可以”释放内存，free就大了。用户会怎么想？不会觉得操作系统“有问题”吗？所以说，我觉得既然核心是可以快速清空buffer或cache，也不难做到（这从上面的操作中可以明显看到），但核心并没有这样做（默认值是0），我们就不应该随便去改变它。一般情况下，应用在系统上稳定运行了，free值也会保持在一个稳定值的，虽然看上去可能比较小。

　　当发生内存不足、应用获取不到可用内存、OOM错误等问题时，还是更应该去分析应用方面的原因，如用户量太大导致内存不足、发生应用内存溢出等情况，否则，清空buffer，强制腾出free的大小，可能只是把问题给暂时屏蔽了。

　　我觉得，排除内存不足的情况外，除非是在软件开发阶段，需要临时清掉buffer，以判断应用的内存使用情况；或应用已经不再提供支持，即使应用对内存的时候确实有问题，而且无法避免的情况下，才考虑定时清空buffer。（可惜，这样的应用通常都是运行在老的操作系统版本上，上面的操作也解决不了）。而生产环境下的服务器可以不考虑手工释放内存，这样会带来更多的问题。记住内存是拿来用的，不是拿来看的。不像windows。

　　无论你的真实物理内存有多少，他都要拿硬盘交换文件来读。这也就是windows为什么常常提示虚拟空间不足的原因，你们想想多无聊，在内存还有大部分的时候，拿出一部分硬盘空间来充当内存。硬盘怎么会快过内存，所以我们看linux，只要不用swap的交换空间，就不用担心自己的内存太少。如果常常swap用很多,可能你就要考虑加物理内存了，这也是linux看内存是否够用的标准哦。

定时释放脚本（/root/freemem.sh）

#!/bin/bash
#该脚本用于清理buff/cache，释放内存

used=`free -m | awk 'NR==2' | awk '{print $3}'`
free=`free -m | awk 'NR==2' | awk '{print $4}'`

echo "===========================" >> /var/log/mem.log
date >> /var/log/mem.log
echo "Memory usage | [Use：${used}MB][Free：${free}MB]" >> /var/log/mem.log

#设置free小于900M时就开始进行清理
if [ $free -le 900 ] ; then
        sync && echo 1 > /proc/sys/vm/drop_caches
        sync && echo 2 > /proc/sys/vm/drop_caches
        sync && echo 3 > /proc/sys/vm/drop_caches
        echo "OK" >> /var/log/mem.log
else
        echo "Not required" >> /var/log/mem.log
fi

将脚本添加到crond任务，定时执行。

[root@YUNJIA-02-CENTOS7-MANAGER ~]# echo "*/30 * * * * sh /root/freemem.sh" >> /etc/crondtab
[root@YUNJIA-02-CENTOS7-MANAGER ~]# crontab -l
*/30 * * * * sh /root/freemem.sh

定时任务说明

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

 

windows 系统内存持续增长无法释放

任务管理器中无任何运行程序，但物理内存占用持续增长，关闭运行的任务后，物理内存依然高占用；最终卡死黑屏等情况

运行总和和物理总占用不一致情况。



腾讯杀毒等等杀毒都没用。

解决办法：

建议用卡巴斯基，或者是火绒杀毒全盘杀毒，找到 scmenu64.dll的文件删除对应几个文件即可