free释放内存后，内存空间的疑问

Question

1.free一段内存后，为什么还可以对这段内存进行读写。。。按照网上以及书上的说法，释放内存后，这段内存就不应该使用了，操作系统就可以分配给其他任务。。
我的疑问是，释放内存后，这段内存资源还是否属于当前进程？？？
如果属于当前进程，那么读写访问无可厚非。
可是，操作系统可以再次利用这段内存并分配给其他人,那么这里的“其他”只是限定在当前进程中吗，只是给当前进程其他代码中的内存申请来使用么？
2.局部的数组，在函数运行完毕后，应该释放，但是为什么依然可以读写其中的数据？

Answer 1

十几年前上学的时候，计算机还是紧缺资源，在没有购买个人电脑之前，我们通常会去学校的计算机室上机。计算机室有专人管理，规矩诸多，其中包括“不要随意修改系统配置文件”，“不要做和学习无关的事情”等等。而我们经常会很开心地先把autoexec.bat/config.sys大改一气（很没出息是吧，不久几十K字节的事儿么，:))，然后再往机器上拷贝个金庸群侠传之类的，偷偷玩上半个小时。第二天再去上机的时候，直奔昨天保存文件的目录。运气好的时候，文件还在，于是大喜，接着进度继续玩；运气不好的时候，不但文件已经被删，而且还发现机器上新增的病毒好厉害，->_->。说这个陈芝麻烂谷子，也许你已经明白我的意思。其实我想说的就是两点：1.你可以不遵守规则，但不等于没有规则。2.不遵守规则而产生的后果是不可预测的(undefined)。楼主没有明确说明为什么会认为free的内存仍然可用，以及为什么认为局部变量的数据仍然可用。为了说明问题，我假设以下的程序：#include#includeint*lvret(void){intret=5;return&ret;}intmain(void){int*p=lvret();printf("%d\n",*p);}编译运行这个程序的结果很可能是5。所以函数结束后，局部变量的数据仍然可用是吗？再来考虑下面这个程序：#include#includeint*lvret(void){intret=5;return&ret;}voidmod(void){inta=7;}intmain(void){int*p=lvret();mod();printf("%d\n",*p);}这个程序运行的结果很可能是7。显然，这个内存地址现在变得不那么可靠了。(编译器还是会给出警告，比如gcc4.8）warning:functionreturnsaddressoflocalvariable[-Wreturn-local-addr]return&ret;所以这个例子告诉我们，你能够访问到的内存空间并不总是安全的。换句话说，你发现释放后的内存数据或者局部变量占用的内存仍然可以读写，只不过是偶然的情况--刚好没有被别的程序动过而已。C语言并不是一个内存安全的语言。C++也不是，但C++11已经好很多了(接纳了smartpointer)。补充以上主要说明楼主描述的操作为什么从根本上是需要避免的。再来补充回答一下楼主的疑问：问题1：是Heap(堆)的管理。楼主的潜台词应该是“既然内存释放了，那么在访问的时候为什么不出现segmentationfault”。回答是--这是C运行库实施层面的问题。大多数运行库的实施不会试图去识别那些已经被"free"的内存块，并把它们退回系统(所谓退回系统，就是取消在进程地址空间上的映射)。因此，在访问这些地址的时候，segmentationfault没有如预料中出现。但并不全是这样，也有例外，比如说OpenBSD就是一个。访问wiki，你可以看到如下描述：Onacalltofree,memoryisreleasedandunmappedfromtheprocessaddressspaceusingmunmap.ThissystemisdesignedtoimprovesecuritybytakingadvantageoftheaddressspacelayoutrandomizationandgappagefeaturesimplementedaspartofOpenBSD'smmapsystemcall,andtodetectuse-after-freebugs—asalargememoryallocationiscompletelyunmappedafteritisfreed,furtherusecausesasegmentationfaultandterminationoftheprogram.这也从侧面证明了楼主观察到的现象是不可靠的。(至于为什么多数运行库要采取这样的内存管理策略，又是另一个话题了)问题2：是Stack(栈)的管理。@精英王子已经说明了。