项目事故和安全语言

  有个从表面上看起来很奇怪的事实是：司机戴安全带比不带安全带时发生的行车事故要多。不带安全带时，司机死亡率比较高，但是带了安全带时，司机死亡率是降低了，但是行人死亡率却提高了。

  不带安全带时，司机需要谨慎缓慢的开车，带了安全带，司机却会 更快，更放肆地开车。
这个方面的资料 可以看下 Automobile Safety Regulation and the Incentive to Drive Recklessly:Evidence from NASCAR 和Automobile Safety Regulation

  编程语言，从一种不安全语言(比如c/c++)发展到一种相对安全语言(比如C#)时,语言上安全程度提高，并不因此能够大量的减少项目事故，只能减少对开发人员威胁程度而已。而对于客户平均威胁程度却是提高了。

   安全性高的语言，就像司机有了安全带一样，使得原本那些担心做不好而使得自己饭碗不保地不合格开发人员更加-------放肆了。

  同样的项目 用c/c++开发，开发人员知道c/c++极易出错，开发速度故而缓慢，谨慎。尽量避免在开始就出错。项目运行时，初期出错。小错误还好，如果是系统崩溃之类的错误，有麻烦的是开发人员。

  用C#开发，则因为C#和.net平台有各种各样的保证机制。相对不容易出错，比如c/c++中最麻烦的内存，资源回收和指针问题。项目运行初期也很难发现.等运行一段时间之后，出错了很有可能就需要重新设计了。

  开发语言虽安全，请各位"新人司机"缓慢，谨慎驾驶。

评论

19 楼 charon 2006-09-26  

buaawhl 写道

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

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

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

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

18 楼 抛出异常的爱 2006-09-26  

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

17 楼 runes 2006-09-26  

buaawhl 写道

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

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

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

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


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


请教了！！

16 楼 buaawhl 2006-09-26  

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

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

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

15 楼 runes 2006-09-26  

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

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

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

14 楼 ddd 2006-09-26  

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

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

13 楼 robbin 2006-09-26  

ddd 写道

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

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

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

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

12 楼 ddd 2006-09-26  

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

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

11 楼 robbin 2006-09-26  

ddd 写道

robbin 写道

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

你说的这个用c/c++做的系统包含操作系统么?
如果不包括的话,应用程序内存泄露是无所谓的,用不着重起操作系统.

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

就拿我亲身经历来说吧。刚购买这台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++那种直接从操作系统申请的内存要是泄漏掉，就再也找不回来了，危害实在是太大了。

10 楼 jack 2006-09-26  

Lucas Lee 写道

观点有新意，有意思。
从某种角度来说，在对一个改革或新工具作评估时，应该考虑进这个因素，才不至于被推销员蒙晕了。一般来说，能提高数倍生产率的工具，在考虑了成熟度、稳定性、学习曲线、和本文中的开发者思想放松的心理因素后，可能提高的只有50%了。虽则仍不错，但如果预期不准，可能带来信誉、士气等问题。

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

9 楼 jack 2006-09-26  

ddd 写道

robbin 写道

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

你说的这个用c/c++做的系统包含操作系统么?
如果不包括的话,应用程序内存泄露是无所谓的,用不着重起操作系统.

呵呵 俺做的c/c++程序都是24*7的那种，或者努力实现24*7的,内存泄露，内存碎片啥的，头痛的要死

8 楼 jack 2006-09-26  

buaawhl 写道

Jack兄弟，这类比确实很新鲜，可是这也太离谱了吧。

人类很多领域是不容许出错的，一旦出错，后果极其严重，无法挽回。比如，驾驶，建筑，消防，战争 ...

但是，很遗憾（也很幸运），软件开发恰好就不是这些领域。至少在开发阶段，出错是常态，不出错几乎是不可能的。

突然想到而已，所以写在这里大家讨论下。语言安全性问题，对于新加入成员影响是不可避免的。而且一定是负面影响大于正面影响。而对于熟手，则可能由于过往经验影响，反而会善于利用。
比如robbin说的 java项目的内存泄露问题，这些都是在已知情况下，而且有解决办法（定期维护重起）。

7 楼 ddd 2006-09-26  

robbin 写道

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

你说的这个用c/c++做的系统包含操作系统么?
如果不包括的话,应用程序内存泄露是无所谓的,用不着重起操作系统.

6 楼 ddd 2006-09-26  

有点意思,从这个角度说东西.
当然是否正确就不晓得了.

5 楼 BirdGu 2006-09-26  

很多错误不是光靠小心谨慎就能避免的。要靠经验和知识的。

4 楼 buaawhl 2006-09-26  

Jack兄弟，这类比确实很新鲜，可是这也太离谱了吧。

人类很多领域是不容许出错的，一旦出错，后果极其严重，无法挽回。比如，驾驶，建筑，消防，战争 ...

但是，很遗憾（也很幸运），软件开发恰好就不是这些领域。至少在开发阶段，出错是常态，不出错几乎是不可能的。

3 楼 robbin 2006-09-26  

jack 写道

  有个从表面上看起来很奇怪的事实是：司机戴安全带比不带安全带时发生的行车事故要多。不带安全带时，司机死亡率比较高，但是带了安全带时，司机死亡率是降低了，但是行人死亡率却提高了。

  不带安全带时，司机需要谨慎缓慢的开车，带了安全带，司机却会 更快，更放肆地开车。
这个方面的资料 可以看下 Automobile Safety Regulation and the Incentive to Drive Recklessly:Evidence from NASCAR 和Automobile Safety Regulation

  编程语言，从一种不安全语言(比如c/c++)发展到一种相对安全语言(比如C#)时,语言上安全程度提高，并不因此能够大量的减少项目事故，只能减少对开发人员威胁程度而已。而对于客户平均威胁程度却是提高了。

   安全性高的语言，就像司机有了安全带一样，使得原本那些担心做不好而使得自己饭碗不保地不合格开发人员更加-------放肆了。

  同样的项目 用c/c++开发，开发人员知道c/c++极易出错，开发速度故而缓慢，谨慎。尽量避免在开始就出错。项目运行时，初期出错。小错误还好，如果是系统崩溃之类的错误，有麻烦的是开发人员。

  用C#开发，则因为C#和.net平台有各种各样的保证机制。相对不容易出错，比如c/c++中最麻烦的内存，资源回收和指针问题。项目运行初期也很难发现.等运行一段时间之后，出错了很有可能就需要重新设计了。

  开发语言虽安全，请各位"新人司机"缓慢，谨慎驾驶。

我觉得你说的不对。

如果像Java这种运行在VM上面，没有指针操作，比较安全的语言，即使内存泄漏，我都不会有太大担心，大不了重起JVM呗，有JVM作为一个安全的保障，不会危及操作系统。但是C/C++就不一样，这些东西一旦内存泄漏，就根本找不回来了，不重起整个操作系统，根本就没有戏，可以说危害极大。

其实很多Java开发的大型系统都有或轻或重的内存泄漏问题，即使很多大型企业的关键应用都是如此。但是很多大型行业应用，往往在晚上都会停掉AppServer进行备份和数据维护，因此只要你能够保证24小时连续运行内存泄漏不超出物理内存限制，也就不是什么问题了。

但是C/C++开发的系统，内存一旦泄漏，由于没有VM的安全保障，只能等待重起操作系统，但是对于这些行业应用来说，重起操作系统根本就是不可以接受的，你想，光是重起小型机操作系统，往往都要半个小时，你能受的了？

另外我带过一些人做Java，也做VC开发，我就发现他们写Java程序，基本不出大的问题，但是写起来VC程序，到处都是内存泄漏，程序都不堪一用。

你不能指望程序员在使用不同的编程语言的时候，自己提高警觉，这是不现实的。根据我的经验，做VC开发的人出现内存泄漏问题远远超过做Java开发的。

2 楼 potian 2006-09-26  

不知道类型系统专家门是否有这方面的统计数据和研究论文，不知道研究的结果是不是：

有个从表面上看起来很奇怪的事实是：用静态类型系统编写的系统比用动态类型编写的系统bug率更高。用动态类型编写的程序，发生类型错误的情况更多一些，而用静态类型编写的程序，发生逻辑错误的情况更多。

1 楼 LucasLee 2006-09-26  

观点有新意，有意思。
从某种角度来说，在对一个改革或新工具作评估时，应该考虑进这个因素，才不至于被推销员蒙晕了。一般来说，能提高数倍生产率的工具，在考虑了成熟度、稳定性、学习曲线、和本文中的开发者思想放松的心理因素后，可能提高的只有50%了。虽则仍不错，但如果预期不准，可能带来信誉、士气等问题。