项目事故和安全语言

  还有一个方面，就是你在什么样的环境中学会了这种安全语言应用。如果项目组环境很是严谨经验也很多，那么负面影响会少些。反过来，则只看到了优点的环境，难免会有些想不到的负面影响

当然有所谓，而且大有所谓！

就拿我亲身经历来说吧。刚购买这台AMD64服务器，安装Linux x86_64之后，我在上面编译安装好PHP4，就发现内存一直泄漏(那时候还没有迁移到JavaEye2.0)，一天下来物理内存有超过2GB被泄漏掉了，纵然我有4GB物理内存，也搞到操作系统不得不使用swap，无论你怎么重起apache都不管用，就是把服务器上面所有程序全部关掉，物理内存仍然只剩下不到1GB，那3GB物理内存不翼而飞了，这就叫内存泄漏！搞的我每天晚上不得不重起一次服务器，否则只要连续跑上48小时，物理内存就一点不剩，服务器就得失去响应了，我根本就束手无策。

后来迁移到JavaEye2.0，停掉PHP，改用ruby，并且重起了一次服务器之后，就一切恢复正常了，我后来推测可能是PHP4和x86_64操作系统兼容性不好导致的内存泄漏。这种内存泄漏，要是搁在Java，我每天晚上重起一下tomcat，也没啥大不了，Java的内存泄漏仅仅造成JVM崩溃，不会殃及整个操作系统的内存管理，要是C/C++那种直接从操作系统申请的内存要是泄漏掉，就再也找不回来了，危害实在是太大了。

apache不可能直接分配属于内核的内存，它malloc的都是用户态的内存，你如果把所有进程都杀了还占用成这个样子，应该这些内存都是内核申请的了，胡乱推测一下：一是僵尸进程太多，php应该是一个连接一个进程。二是某个内核驱动程序出问题了，占用过多内存。不过似乎无论什么情况都不关apache或者php的事情，出事了也是内核出事了。即使kill后，apache或php占用的内存没回收，也是内核的问题。
内核倒肯定是c+asm的，不过这个就不能比较了。

总之我觉得应用程序被kill了以后还出现内存大量占用应该和这个程序用什么语言无关。

那为什么我停了PHP，就好了呢？同样的程序又为什么以前在Linux x86_32上面跑就没有内存泄漏呢？

BTW:不是冒犯，但是我怀疑你不懂C编程，否则怎么会连C程序导致操作系统内存泄漏的基本常识都不知道？

实话说，我也搞不懂停了php为什么会好了。
我对这个的论断还是坚持内核问题。
至于应用程序的malloc，在内核描述进程的数据结构中写点东西（这话不精确，因为还要涉及好几个数据结构，但在这里能通过一些指针找到那些东西），一旦进程结束了，就根据这个数据结构中的这些信息统统释放掉。
这个你可以实验一下，一个c程序malloc一堆内存，但不free就直接退出程序，看看退出后还占不占用内存。

其实上面的话还是不精确，为了叙述简单起见。

robbin 所指的“但是C/C++就不一样，这些东西一旦内存泄漏，就根本找不回来了，不重起整个操作系统，根本就没有戏，可以说危害极大。"

想请教一下robbin，难道当进程结束时，该进程申请的内存不会释放？？？

jvm不也就是一个进程吗？重起一下tomcat不也是为了结束以前的tomcat进程吗？

忍不住了.
难道现在的学校都不教 C 语言了？

如果进程申请的堆空间，能够自动释放，java的GC还有什么可吹嘘的呢？
GC = Gabage Collection。

Java等vm语言为了做到GC，还是做了很多工作的。直接影响了语言的运行效率。是一个巨大的牺牲。

大哥你那个堆空间 也是 本进程的，和 C 语言了 关系大吗？ 操作系统 啊。


这样说吧， 你在windows 下面 开个 cmd, 写个不释放 内存的cpp 程序，run 完已后，把这个dos
窗口关闭了，刚才不释放 内存的cpp 程序还会对os 有影响？


请教了！！

是的
你以为病毒是怎么写的？

老大，GC的内存释放是动态的，程序照样在跑，而进程退出时的内存释放则是另外一回事情，要释放内存必须频繁启动/关闭程序，这个就比较e了。
进入真正的多进程操作系统时代之后，杀掉进程，这个进程相关的所有资源都会被干掉(当然对于fork出来的子进程某些情况下会有麻烦，但是子进程本身也是可以被kill掉的).系统资源被占用的原因多数是存在大量僵尸进程或孤儿进程.