下面是以前（大概2003、2004年吧）在某BBS上的一场关于内存泄漏的讨论。我先原样贴出当时存档的，如果C友友兴趣，我再整理成文章。

发信人: tianshangfei(天上飞的猪), 信区: C
标  题: 什么叫做内存泄漏，谁能定义一下呢
: 说说看～

发信人: RobbieZ(RobbieZ), 信区: C
个人理解：申请的内存空间，在进程运行结束后未被释放。

发信人: xreborner(xreborner), 信区: C
进程结束了你不释放系统都会帮你释放啦，不是指运行结束后未被释放的拉
【 在 RobbieZ 的大作中提到: 】
: 个人理解：申请的内存空间，在进程运行结束后未被释放。

发信人: RobbieZ(RobbieZ), 信区: C
我觉得系统帮你释放就是内存泄露

发信人: sleepsheep(知耻而后勇后勇而后生), 信区: C
进程结束时的确会释放所有资源，那内核进程呢？内核进程使用的堆空间要是你在使用后不释放的话
就象俺们以前用win98，没事就要重启来找速度
对于堆里的空间，没有释放，就会有内存泄漏。win下还有使用的资源也是需要维护的，如，dll加载到内核空间，要是狂加不放，你的app会把服务器给搞死的。不要把释放的事情交给别人
【 在 xreborner (xreborner) 的大作中提到: 】
: 进程结束了你不释放系统都会帮你释放啦，不是指运行结束后未被释放的拉

发信人: xreborner(xreborner), 信区: C
我只是说内存泄漏并不是指进程结束后未被释放的空间而已，哪里说把释放的事情交给别人啊？
【 在 sleepsheep 的大作中提到: 】
: 进程结束时的确会释放所有资源，那内核进程呢？

发信人: DancingCode(连接错误~The Server Side), 信区: C
no 
all the resource will be released after the process ends
but we can not depend on this, we should release by ourselves.
【 在 RobbieZ (RobbieZ) 的大作中提到: 】
: 个人理解：申请的内存空间，在进程运行结束后未被释放。

发信人: DancingCode(连接错误~The Server Side), 信区: C
no 
some dll should be released after a proecess ends. u know nothing about that 
actually, like the mfc71.dll
RobbieZ (RobbieZ) 的大作中提到: 】
: 我觉得系统帮你释放就是内存泄露

发信人: beepbug(自说自话), 信区: C
进程在运行中申请的内存（即所谓的动态分配），在使用后没有申请回收。
Memory Leak：还是翻译成“内存遗漏”，比较容易理解。
【 在 tianshangfei 的大作中提到: 】
: 说说看～

发信人: godsarmy(上帝武装), 信区: C
有些情况下，比如你启动了大量socket而没有关掉，还要好玩呢
【 在 beepbug (自说自话) 的大作中提到: 】
: 进程在运行中申请的内存（即所谓的动态分配），在使用后没有申请回收。
: Memory Leak：还是翻译成“内存遗漏”，比较容易理解。

发信人: lingjiexyz(owl), 信区: C
呵呵，我来说个说法吧，其实所谓的内存泄漏并不是申请空间在程序运行时候没被是释放，不，这是内存泄漏的的直接结果，而非事物的内容呢？那么什么是内存泄漏呢？ 到目前为止，我看到的最经典的解释是effective c++条款10上的这么一句：引起内存泄露的原因在于内存分配后指向内存的指针丢失了。如果没有垃圾处理或其他语言之外的机制，这些内存就不会被收回。
换而言之，我们在堆上动态申请了一块内存，但在程序运行过程中我们丢掉了这个内存的控制权，这样就出现了内存泄漏。也许你会说我在整个程序中都控制着这个内存的指针，只是在程序的最后忘了free
他，但是，我的朋友，请不要忘记指针本身是stack变量。他会随着main的结束而消失，而负责释放内存的os发现本该释放的内存因为指针的提前消失而失踪了
【 在 godsarmy (上帝武装) 的大作中提到: 】
: 有些情况下，比如你启动了大量socket而没有关掉，还要好玩呢
: 【 在 beepbug (自说自话) 的大作中提到: 】
: : 进程在运行中申请的内存（即所谓的动态分配），在使用后没有申请回收。
: : Memory Leak：还是翻译成“内存遗漏”，比较容易理解。

发信人: DancingCode(连接错误~The Server Side), 信区: C
you qi yi
【 在 lingjiexyz (owl) 的大作中提到: 】
: 呵呵，我来说个说法吧，其实所谓的内存泄漏并不是申请空间在程序运行时候没被

发信人: lingjiexyz(owl), 信区: C
哦，请指教
【 在 DancingCode (连接错误~The Server Side) 的大作中提到: 】
: you qi yi

发信人: typedef(C plus plus), 信区: C
前面两段说得很不错，很到位。最后一段没看懂你想表达什么 
【 在 lingjiexyz (owl) 的大作中提到: 】
: 呵呵，我来说个说法吧，其实所谓的内存泄漏并不是申请空间在程序运行时候没被

发信人: lingjiexyz(owl), 信区: C
呵呵，我是说写出这样的代码的人会认为自己没有丢失对内存的控制权，这是很多人误解内存泄漏的原因所在、、、
int main()
{
int *p = new int(100);
cout << *p << endl;
}

【 在 typedef (C plus plus) 的大作中提到: 】
: 前面两段说得很不错 很到位
: 最后一段没看懂你想表达什么 

发信人: typedef(C plus plus), 信区: C
恩 看来我没有误解你的意思 哈哈
这样的代码没有问题啊 
【 在 lingjiexyz (owl) 的大作中提到: 】
: 呵呵，我是说写出这样的代码的人会认为自己没有丢失对内存的控制权，这是很多

发信人: lingjiexyz(owl), 信区: C
哦？你是说没有内存泄漏？
【 在 typedef (C plus plus) 的大作中提到: 】
: 恩 看来我没有误解你的意思 哈哈

发信人: typedef(C plus plus), 信区: C
如果代码很长，而且这个内存在中途就应该释放而没有释放，那么即便指针没有丢失也属于内存泄露。这个代码的应该不算吧
【 在 lingjiexyz (owl) 的大作中提到: 】
: 哦？你是说没有内存泄漏？

发信人: lingjiexyz(owl), 信区: C
恩，这个说法值得思考，几乎是存在一点歧义呢
【 在 typedef (C plus plus) 的大作中提到: 】
: 如果代码很长 而且这个内存在中途就应该释放而没有释放

发信人: typedef(C plus plus), 信区: C
hehe 怎么讲？？比如说你写了一段很庞大的代码，并且代码里面，只有new，而没有任何一个delete，那么，即便你的每一个new出来的指针都保存得很好，也是存在着严重的内存泄露问题。所以说内存泄露就是指，本来应该释放的内存没有释放。至于我们通常说的指针丢失是导致内存泄漏的最常见的情况。因为稍微有一点经验的程序员都知道new出来的指针是要delete的，所以如果指针没有丢失，那么它就会在适当的地方delete。那么就不会造成泄漏。但是如果指针丢失了，导致程序员本身没有能力在归还内存，这就造成了泄露。
但是如果程序员本身没有释放的概念也会造成严重的泄漏。所以说指针丢失的情况是泄露，但是泄漏指的并不是指针丢失，而是内存没有在不再使用的时候释放这样一个问题。
【 在 lingjiexyz (owl) 的大作中提到: 】
: 恩，这个说法值得思考，几乎是存在一点歧义呢

发信人: lingjiexyz(owl), 信区: C
恩，有点新意。那么这里有个关键问题，是不是所有堆上分配的内存都必须油程序员自己负责释放，如果没有释放是否会内存泄漏。我不知道DC说的歧义指的是什么？
【 在 typedef (C plus plus) 的大作中提到: 】
: hehe 怎么讲？？

发信人: typedef(C plus plus), 信区: C
个人感觉理论上最好这样子。尤其是在没有把握的情况下，最好养成主动释放的好习惯。至于有了经验之后，应该怎么做自己心中有数就好。
其实你不释放，程序结束的时候系统也会统一回收。所以内存泄露影响的是程序运行期的系统效率，不会延续到程序结束的。
【 在 lingjiexyz (owl) 的大作中提到: 】
: 恩，有点新意。那么这里有个关键问题，是不是所有堆上分配的内存都必须油程序

发信人: lingjiexyz(owl), 信区: C
【 在 typedef (C plus plus) 的大作中提到: 】
～～～～～～～～～～～～～～～～～～～  ～‘
: 不会延续到程序结束的
～？～～～～～～～这个看来是说到关键了，不错，看来有些东西还是需要讨论的

发信人: beepbug(自说自话), 信区: C
人家要的是定义。如果在一个没有指针的世界，那effective c++条款10上的最经典的解释就不行了。而且这个解释也不经典。只是从C角度看Memory leak的表像而已。
【 在 lingjiexyz 的大作中提到: 】
: 呵呵，我来说个说法吧，其实所谓的内存泄漏并不是申请空间在程序运行时候没被

发信人: lingjiexyz(owl), 信区: C
c的角度？那么c++的角度该如何呢？
【 在 beepbug (自说自话) 的大作中提到: 】
: 人家要的是定义。如果在一个没有指针的世界，那effective c++条款10上的最经典的解释

发信人: beepbug(自说自话), 信区: C
“程序结束的时候系统也会统一回收”吗？系统静态分配给进程的内存空间，在进程结束时，系统会整块回收的。这我知道。那动态分配的呢？也会在进程结束时回收吗？凭我的经验（仅仅是经验），好像不会。哪位能给个明确的结论？
【 在 typedef 的大作中提到: 】
: 个人感觉理论上最好这样子

发信人: typedef(C plus plus), 信区: C
你有什么经验？？？？
【 在 beepbug (自说自话) 的大作中提到: 】
: “程序结束的时候系统也会统一回收”吗？系统静态分配给进程的内存空间，在进程结束

发信人: typedef(C plus plus), 信区: C
你的经验是在什么系统上的？？？？
【 在 beepbug (自说自话) 的大作中提到: 】
: “程序结束的时候系统也会统一回收”吗？系统静态分配给进程的内存空间，在进程结束

发信人: typedef(C plus plus), 信区: C
btw 你是什么专业的 几年级？做过什么东西么？？只是想了解一下
【 在 beepbug (自说自话) 的大作中提到: 】
: “程序结束的时候系统也会统一回收”吗？系统静态分配给进程的内存空间，在进程结束

发信人: DancingCode(连接错误~The Server Side), 信区: C
The answer is YES
【 在 beepbug (自说自话) 的大作中提到: 】
: “程序结束的时候系统也会统一回收”吗？系统静态分配给进程的内存空间，在进程结束

发信人: typedef(C plus plus), 信区: C
bingo hoho
【 在 DancingCode (连接错误~The Server Side) 的大作中提到: 】
: The answer is YES

发信人: beepbug(自说自话), 信区: C
动态空间的分配和回收，不是C++扩充的东西。malloc()等在最早的C版本里就已存在。尽管后来有了new和delete，但是这不会改变内存遗漏的定义。
我在以前的回帖里曾提出过，同静态一样，动态空间的分配和回收也是系统的事。在C（C++）里，进程做的仅仅申请分配和申请回收而已。因此，脱离系统，光用某语言表述它们的定义，是不妥的。C不行，C++也不行。
【 在 lingjiexyz 的大作中提到: 】
: c的角度？那么c++的角度该如何呢？

发信人: xiaoxuan(小轩), 信区: C
内存泄露是应用程序没有处理好内存管理。和操作系统回收垃圾有什么关系? 何必去扯上系统。
【 在 beepbug (自说自话) 的大作中提到: 】
: 动态空间的分配和回收，不是C++扩充的东西。malloc()等在最早的C版本里就已存在。尽

发信人: lingjiexyz(owl), 信区: C
没必要那么复杂，这个不利于问题的解决，
【 在 beepbug (自说自话) 的大作中提到: 】
: 动态空间的分配和回收，不是C++扩充的东西。malloc()等在最早的C版本里就已存在。尽

发信人: xsync(没有蛀牙), 信区: C
建议typedef同学还要多看看C++
【 在 typedef (C plus plus) 的大作中提到: 】
: 恩 看来我没有误解你的意思 哈哈

发信人: beepbug(自说自话), 信区: C
在UNIX上用C(C++)对系统多做一点试验，或许会多少同意一点我的意见。
【 在 xiaoxuan 的大作中提到: 】
: 内存泄露是应用程序没有处理好内存管理.

发信人: beepbug(自说自话), 信区: C
SCO Xenix release 3.1.2吧。是现在SCO OpenServer 5.0的前身。说是经验，是由于自己也吃不准。可能是误解。
【 在 typedef 的大作中提到: 】
: 你的经验是在什么系统上的？？？？

发信人: xiaoxuan(小轩), 信区: C
暂时不敢苟同。
从我的理解，内存泄漏是针对应用程序没有管理好内存而言的。至于系统是否在应用程序结束以后回收应用没有释放的内存，这是另外一回事。虽然你的UNIX是回收的，但我的系统不一定回收。
无论如何，在应用程序没有结束以前，用C写的代码是要自己管理内存的，但lisp或者java不用.
内存泄漏这个概念是C语言特有的, 与系统无关。与你的理解正好相反.
【 在 beepbug 的大作中提到: 】
: 在UNIX上用C(C++)对系统多做一点试验，或许会多少同意一点我的意见。

发信人: godsarmy(上帝武装), 信区: C
【 在 xiaoxuan (小轩) 的大作中提到: 】
: 暂时不敢苟同。
: 
: 从我的理解，内存泄漏是针对应用程序没有管理好内存而言的。
: 至于系统是否在应用程序结束以后回收应用没有释放的内存，
: 这是另外一回事。虽然你的UNIX是回收的，但我的系统不一定回收。
:                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
值得探讨，也许有些环境不回收~~ 

发信人: DancingCode(连接错误~The Server Side), 信区: C
其实java也有
【 在 xiaoxuan (小轩) 的大作中提到: 】
: 暂时不敢苟同。

发信人: namespace(Cfront), 信区: C
en 3ku 我还在努力中 hoho
【 在 xsync (没有蛀牙) 的大作中提到: 】
: 建议typedef同学还要多看看C++

发信人: phiobos(Phiobos), 信区: C
是个系统都会有内存泄漏问题。可以说没有完美的解决方案
【 在 DancingCode (连接错误~The Server Side) 的大作中提到: 】
: 其实java也有

发信人: xiaoxuan(小轩), 信区: C
汗 ... 其实俺没有用过java, 也没有用过lisp.
【 在 DancingCode (连接错误~The Server Side) 的大作中提到: 】
: 其实java也有

发信人: phiobos(Phiobos), 信区: C
Java里面的memery leak产生比较特殊，没有C++那么严重
【 在 xiaoxuan (小轩) 的大作中提到: 】
: 汗 ... 其实俺没有用过java, 也没有用过lisp.

发信人: beepbug(自说自话), 信区: C
学过一点，也做过一点，但档次都很低，不说也罢。不过是想大家一起议议，使自己多一点正确，少一点谬误罢了。你又不是公安，就别查户口了。
【 在 typedef 的大作中提到: 】
: btw 你是什么专业的 几年级？做过什么东西么？？

发信人: beepbug(自说自话), 信区: C
你弄错了。我的感觉也是系统没有回收。但没吃准。
“用C写的代码是要自己管理内存的”，要加一个定语“动态”。不管静态那一块。
但凡与内存分配与回收有点牵连的，都别撇开系统去讨论。
【 在 xiaoxuan 的大作中提到: 】
: 暂时不敢苟同。

发信人: xiaoxuan(小轩), 信区: C
通常在处理list, string, map之类的时候会遇到memory leak，我的感觉是java等高级语言提供了这些数据类型，所以程序员在内存管理上就比较轻松了。而C则到处是陷阱。
等过两年俺把C语言学好了以后，也要看看java长进一下。
从字面上解释的话，
p = malloc(100);
p = NULL;
这样的代码就是典型内存泄漏。但是实际应用中，是在处理list, string, map，
或者自定义的数据块时才会遇到它。然后再手工或者借肋工具来排除错误。
【 在 phiobos (Phiobos) 的大作中提到: 】
: Java里面的memery leak产生比较特殊

发信人: xiaoxuan(小轩), 信区: C
俺再跟你辩辩。
正好周五我这边是例会，都等着开会喝茶聊天，闲得慌。
首先要说明一点，DancingCode说过的话，我绝大部分是赞同的。
既然都已经明确回答过你，系统是回收内存的，怎么还不相信别人呢。
UNIX，Windows，或者说微型计算机上使用的通用OS，都是回收垃圾的。
我说我的系统不一定回收，其实是故意说的，实际上它很可能也是回收的。
目前我在目标平台上面用的OS，是基于ITRON标准的一个RTOS，它支持静态
内存分配(固定长度块)与动态内存分配(可变长度块)，但是不回收内存。
在我这里，BOOT代码在进行C语言初使化时对C静态内存的分配(DATA和BSS)，
与OS初使化之后提供的静态和动态内存分配，是两级不同的概念。
在我这里，
* C语言比OS更加底层，它支持动态和静态内存分配，由BOOT代码
来实现，我没有让BOOT支持C动态内存分配，C静态内存永远常驻。
* OS层支持静态内存分配和动态内存分配。但是我没有让它回收静态
或动态内存块。
* 我没有让OS回收任何其它资源，比如应用结束后未关闭串口。
如果你真的理解了系统。我想你大概不会把应用的责任推给系统了。
我再最后强调一点：内存泄露是应用程序的事，与系统无关。
(虽然，整个系统也可以理解为一个应用程序，但这与问题的本质不相关。)
【 在 beepbug (自说自话) 的大作中提到: 】
: 你弄错了。我的感觉也是系统没有回收。但没吃准。

发信人: stuarthu(stuarthu), 信区: C
嗯。我觉得你们两个辩论的东西是两个概念。bb的静态动态ms是指c语言里面static和用malloc分配的两种内存。其实经过编译器处理以后对系统来说都是动态分配的。xx说的静态动态是OS层面的
【 在 xiaoxuan (小轩) 的大作中提到: 】
: 俺再跟你辩辩。

发信人: xiaoxuan(小轩), 信区: C
bb的静态动态是OS层面的，实际上都是系统(OS)分给他的。
我的分两级：
a) 裸机层面(针对C语言)：静态和动态。
b) OS层面：静态和动态。与bb看到的相同。
我们把编译器这个概念忽略掉，与它无关。剩下两者，系统(OS)和应用(application)。
同样是C语言程序。
对于应用来说：static和malloc，实际上都是由OS来分给它的。
对于系统来说：static常驻，malloc从static中再分(我是这样理解的)。
我们回归到应用。
static和malloc都是OS分的。都由系统回收。
【 在 stuarthu (stuarthu) 的大作中提到: 】
: 嗯。我觉得你们两个辩论的东西是两个概念

发信人: ajax(埃阿斯·乐在棋中), 信区: C
I think u r right.
【 在 typedef (C plus plus) 的大作中提到: 】
: hehe 怎么讲？？

发信人: beepbug(自说自话), 信区: C
没拿出令人信服的依据，凭什么让人相信呢？
第一，内存遗漏与内存动态分配有关。你同意吗？
第二，内存分配是系统管的事，无论是静态还是动态，你同意吗？
第三，如果一与二成立，那讨论leak就要涉及系统，你同意吗？
【 在 xiaoxuan 的大作中提到: 】
: 俺再跟你辩辩。

发信人: xiaoxuan(小轩), 信区: C
内存泄漏是内存管理不当的结果，包括分配，(使用，)与回收。
涉及到资源管理，确实是一件挺麻烦的事。从系统(OS层)的角度，它要做好两件事，
1) 管理好有效资源
2) 使资源管理对应用透明。
从应用(通常的driver层)的角度，它要做一件事，
o) 协肋系统管理好资源。
针对内存管理，这两个角色分别是，
*) OS，管理系统内存
*) malloc & free，协助系统内存管理。
我们是应用程序(application)，我们看到的是malloc和free。我想我们不应该去考虑我调2次malloc和1次free会不会造成系统内存泄漏。因为我们的系统(比如UNIX)会回收垃圾。我们的内存泄漏是针对应用角度的，我们管好我们申请到的内存。当然，如果你要做OS的设计，比如OS的内存分配与回收算法，那么你的角度可能会和我不一样。
【 在 beepbug (自说自话) 的大作中提到: 】
: 没拿出令人信服的依据，凭什么让人相信呢？

发信人: lingjiexyz(owl), 信区: C
nod, he is right
【 在 ajax (埃阿斯·乐在棋中) 的大作中提到: 】
:     I think u r right.

发信人: beepbug(自说自话), 信区: C
我自认为对静态分配有点了解，可对动态分配实在吃不准。希望与大家一起商讨，共同求得认识上的进步。
【 在 xiaoxuan 的大作中提到: 】
: 内存泄漏是内存管理不当的结果，包括分配，(使用，)与回收。
Memory leak不“是内存管理不当的结果”，而是内存使用不当的结果。管理（即分配与回收）在system侧，使用在application一侧。
: 涉及到资源管理，确实是一件挺麻烦的事。
: 从系统(OS层)的角度，它要做好两件事，
:  1) 管理好有效资源
:  2) 使资源管理对应用透明。
: 从应用(通常的driver层)的角度，它要做一件事，
:  o) 协肋系统管理好资源。
: 针对内存管理，这两个角色分别是，
:  *) OS，管理系统内存
:  *) malloc & free，协助系统内存管理。
: 我们是应用程序(application)，我们看到的是malloc和free。
我也是从application看的。但是，leak与系统的存储分配有关，且有很大的关系，确实无法回避。
: 我想我们不应该去考虑我调2次malloc和1次free会不会造成
: 系统内存泄漏。因为我们的系统(比如UNIX)会回收垃圾。
我也希望“我们的系统(比如UNIX)会回收垃圾”。这样，我们也不必操那份心了。但是，当进程终止时，系统能自动判断garbage的存在吗？能自动地、正确无误地collecting garbage吗？
: 我们的内存泄漏是针对应用角度的，我们管好我们申请到的内存。
对！我们使用好“我们申请到的内存”，就不会有leak了。
: 当然，如果你要做OS的设计，比如OS的内存分配与回收算法，
: 那么你的角度可能会和我不一样。

发信人: woailvzi(红拂夜奔|say goodbye to MH), 信区: C
大家的讨论让我受益匪浅阿...多谢多谢
【 在 typedef (C plus plus) 的大作中提到: 】
: hehe 怎么讲？？

发信人: lingjiexyz(owl), 信区: C
呵呵，你几乎所有的问题都从os的角度思考，尽管思想是没错。但总是把一些简单的问题复杂化了，内存泄漏主要影响的是程序本身运行的效率，是程序本身运行过程中内存管理不当的结果，os管理的是程序需要的资源，不该干预程序本身的资源管理，因此这个问题完全没必要从os的角度来看资源的管理。
【 在 beepbug (自说自话) 的大作中提到: 】
: 我自认为对静态分配有点了解，可对动态分配实在吃不准。希望与大家一起商讨，共同求

发信人: xiaoxuan(小轩), 信区: C
进程中止时所有登记占用的设备全部释放。
操作系统如果做不到这点那实在是太让人失望了。
【 在 beepbug (自说自话) 的大作中提到: 】
: 我自认为对静态分配有点了解，可对动态分配实在吃不准。希望与大家一起商讨，共同求

发信人: lingjiexyz(owl), 信区: C
呵呵，如果os直接参与程序的内存管理同样让人失望
【 在 xiaoxuan (小轩) 的大作中提到: 】
: 进程中止时所有登记占用的设备全部释放。

发信人: beepbug(自说自话), 信区: C
我是“几乎所有的问题都从os的角度思考”吗？不会吧？我又不是搞系统的。
可这问题能脱离O.S.来谈吗？在高级语言里，确实有许多问题可以自圆其说而不涉及系统，也确实有许多问题不涉及系统就理不清。为什么学应用的也要先学系统呢？大概也是这个道理吧。
休战吧。一些基本概念有大分歧，没法一致对leak本质的理解。
大家一起来关注一下曾成为2003年热点之一的garbage问题吧。
很明显，大家的学识比我强得多，向大家学习。支持lingjiexyz当版副。希望C版更火。
【 在 lingjiexyz 的大作中提到: 】
: 呵呵，你几乎所有的问题都从os的角度思考，，尽管思想是没错，。但总是把一些

发信人: Checkthat(Checkthat), 信区: C
不可能再被访问却又被操作系统认为已被占据，比如没有任何指针指向的一块已分配的内存空间
【 在 tianshangfei (天上飞的猪) 的大作中提到: 】
: 说说看～

发信人: lingjiexyz(owl), 信区: C
作为一个技术版面当鼓励不同意见，和纯技术性的争论。我们这些人都需要从争论中学到东西，因此你不必为自己的观点没被同意感到遗憾，同时就我本人而言十分欢迎你一如既往的提出自己的见解。保持这种氛围，对谁都有好处
【 在 beepbug ( 自说自话) 的大作中提到: 】: 我是“几乎所有的问题都从os的角度思考”吗？不会吧？我又不是搞系统的。

发信人: cppprimerer(aha), 信区: C
其实不光是内存，只要是资源都会泄漏，比如handle,socket。因为c++的资源管理设计思想是谁获得资源谁管理。所以资源应该在其生命期结束的时候由获取它的主体释放。而生命期什么时候结束是由程序员决定的。即使最终在程序结束之前释放了，或者结束后由系统释放了，只要是没有在其生命期应该结束的时候释放，就应该算资源泄漏。
有时候写多媒体程序的时候，即使后来把资源都释放了，但是由于释放不及时，也会导致资源消耗严重性能不可接受，这样也应该算资源泄漏。
好在现在都去做虚拟机了，把程序员从释放资源的责任中解放出来了。lisp scheme python没有资源泄漏是因为以他们语言本身的动态性，根本不需要程序员动态的管理资源。
【 在 tianshangfei 的大作中提到: 】
: 说说看～

发信人: beepbug(自说自话), 信区: C
对。系统分配给进程，进程用毕而系统未成功回收。
【 在 Checkthat 的大作中提到: 】
: 不可能再被访问却又被操作系统认为已被占据，比如没有任何指针指向的一块已分配内存空间