Chinaunix

标题: 如何写程序就能尽量做到节省内存?或者是提高效率? [打印本页]

作者: kanhfshiys    时间: 2009-11-29 13:26
标题: 如何写程序就能尽量做到节省内存?或者是提高效率?
程序需要注意什么才能尽量做到节省内存或者是提高效率?
作者: cugb_cat    时间: 2009-11-29 13:48
这个问题有点大。。。
你可以去看看算法和数据结构的书。
作者: prolj    时间: 2009-11-29 13:51
线程省内存了,效率烂的一塌糊涂。
设计,是练出来的,多做或者多参与优秀的开源项目。
优秀的,优秀的。
作者: kanhfshiys    时间: 2009-11-29 13:53
标题: 回复 #2 cugb_cat 的帖子
能从C程序的存储空间布局上说吗?
作者: kanhfshiys    时间: 2009-11-29 13:57
标题: 回复 #3 prolj 的帖子
这个好像就不对了吧,在多核环境下,多线程还是效率很高的
作者: kanhfshiys    时间: 2009-11-29 14:04
标题: 回复 #3 prolj 的帖子
去那里参加开源项目
作者: prolj    时间: 2009-11-29 14:09
知道为什么不愿意买Oracle么?因为Oracle搭配4核的机器。知道为什么不愿意买4核的机器么?因为性价比根本不是那么回事儿。
多线程,没写过多线程的代码吧?说多线程高效的就是扯淡,满篇的都是lock,还没跑呢就lock住了,怎么高效啊。
哎,多线程高效,道听途说害人啊。
作者: cugb_cat    时间: 2009-11-29 14:19
原帖由 kanhfshiys 于 2009-11-29 13:53 发表
能从C程序的存储空间布局上说吗?

去看APUE的相关章节
作者: kanhfshiys    时间: 2009-11-29 14:21
标题: 回复 #7 prolj 的帖子
干嘛满篇lock??照你这样说进程池就没有办法用了?也没有 说非要把所有的东西都当作临界区?照你这样说Oracle该倒闭了
作者: prolj    时间: 2009-11-29 14:31
不要混淆视听
我说线程效率根本不高
进程效率其实是很高的
线程不lock?lock少?太可爱了
但是遇上SB的设计,无论是线程还是进程都是没救的
作者: prolj    时间: 2009-11-29 14:35
反正我也需要写数据库,多说一点吧。
一个事务是原子的吧?这里要lock么?
读写的问题呢?同时读,同时写,一个读一个写。DB不是OS,死机了可以人为调整或者重启,DB死了数据就完了,客户就跟你玩儿命。lock不lock?
数据库就那么点儿操作,插入,读取,很多客户的操作要求也都是原子性的,不lock能活么?
池?为了维护数据的统一性,不lock咋办?
呵呵,Oracle的人怎么做的我不知道,我只知道数据库实现上多线程很恶心,那是相当的恶心,不是一般的恶心。
作者: kanhfshiys    时间: 2009-11-29 14:41
标题: 回复 #10 prolj 的帖子
为什么进程高?
作者: prolj    时间: 2009-11-29 14:46
线程的数据相关性太高
进程的数据相关性不会很高
---------------------------------------------
形象的
线程:我的左手想烧水,我的右手想泡茶,我的左脚想进厨房,我的右脚想去卧室,我的屁股想在马桶上。
进程:我去烧水,配偶去准备茶叶和茶具,一起喝完之后,我去拉屎,某人就去睡觉了。
效率是明显的。
作者: kanhfshiys    时间: 2009-11-29 14:58
标题: 回复 #11 prolj 的帖子
数据库当然是你对了!但是数据库 那你应该用到很多进程间通信吧!都说中国没有几个公司能够写出数据库
作者: prolj    时间: 2009-11-29 15:04
OK,大规模Web并发访问,我也不熟,留给熟悉的人吧,JSP/PHP脚本客免谈,一般来说你们是不懂什么叫性能的,性能都在中间件和Server上考虑了。
=======================================================
好像线程不用通信似的,共享变量也是一种通信,何况IPC当中共享内存/pipe的效率不是那么恶心,而且,多进程模型就没有那么多需要通信的情况。
------------------------------------------------------------------------------------------------
国内“自主知识产权”的数据库太多了吧?是个XX大学的教授都自己弄一个。很多 公司/研究所/大学教授 都会“自主知识产权”一下PostgreSQL、MySQL、BerkeleyDB、SQLite或者别的什么。
作者: kanhfshiys    时间: 2009-11-29 15:11
标题: 回复 #15 prolj 的帖子
只是问问  谢谢
作者: drangon    时间: 2009-11-29 15:38
先将程序写正确,然后把代码写的有条理而不是面条式,然后再开始不断迭代优化,积累经验之后,下次可以一开始就选择较好好方案,减少迭代次数。很多时候要不要优化,优化到什么程度,还有很多其他因素影响,不是越优化越好。

优化要具体问题具体分析,有时候是空间换时间,有时候是时间换空间,不同的环境有不同的侧重点,优化要找最瓶颈的地方优化,积累经验后,什么地方是瓶颈会估计的准一些,但大多数情况下还是要做一下profile分析。

提起优化,还没看场合就马上就线程、进程、pool、cache、epoll、框架、模式。。。之类的,通常都是半桶水的
作者: prolj    时间: 2009-11-29 15:42
真无聊,我还要擦屁股
原帖由 kanhfshiys 于 2009-11-29 13:26 发表
程序需要注意什么才能尽量做到节省内存或者是提高效率?

节省内存,线程省了,效率不一定高。
后面引出话题了。
作者: kanhfshiys    时间: 2009-11-29 16:49
标题: 回复 #17 drangon 的帖子
鄙人是空桶。希望满水的多多指教
作者: yulihua49    时间: 2009-11-29 17:10
原帖由 prolj 于 2009-11-29 14:09 发表
知道为什么不愿意买Oracle么?因为Oracle搭配4核的机器。知道为什么不愿意买4核的机器么?因为性价比根本不是那么回事儿。
多线程,没写过多线程的代码吧?说多线程高效的就是扯淡,满篇的都是lock,还没跑呢就 ...

泪如雨下啊,终于找到组织了。孤身奋战多年,控诉多线程的罪恶,没人信啊。
我说过的,好像当年你支持过我:
多线程是平面交通体系,多进程是立体交通体系。
多线程成本低,性能更低。当你在平交路口堵得一塌糊涂时,就知道多线程是多么可恶了。

[ 本帖最后由 yulihua49 于 2009-11-29 17:16 编辑 ]
作者: drangon    时间: 2009-11-29 21:54
标题: 回复 #19 kanhfshiys 的帖子
脱离具体场合,泛泛而谈没什么好谈的

不过想对旁观的群众说句,关于本贴中的线程和进程的评价,个人认为很有问题,讨论有风险,相信要谨慎。
作者: gz80    时间: 2009-11-30 12:04
世上没有绝对的事情,线程和进程的优劣要看场合。
作者: cugb_cat    时间: 2009-11-30 12:41
不同场合不一样,不能一概而论。
作者: kanhfshiys    时间: 2009-11-30 13:36
标题: 回复 #23 cugb_cat 的帖子
都偏离主题了!回答都不是问题了
作者: kanhfshiys    时间: 2009-11-30 13:39
标题: 回复 #22 gz80 的帖子
提高效率,是不是可以依靠编译器的优化,和优化循环语句。
作者: gz80    时间: 2009-11-30 13:49
原帖由 kanhfshiys 于 2009-11-30 13:39 发表
提高效率,是不是可以依靠编译器的优化,和优化循环语句。

编译器的优化你控制不了。
还有我觉得那种为了少一两句比较和跳转语句而把循环展开的做法特sb,为了提高那0.001%的运行效率而增加了99.999%的维护成本
作者: xianliang    时间: 2009-11-30 21:02
<C++ cookbook>里有一段提到代码优化,就一名话:“没有必要”。
你优化代码花的时间、精力、金钱,不如去买个好一些机器。
作者: 小羊咪咪    时间: 2009-11-30 21:52
原帖由 prolj 于 2009-11-29 15:42 发表
真无聊,我还要擦屁股

节省内存,线程省了,效率不一定高。
后面引出话题了。


从来没听说过线程能省内存,线程本身需要的stack空间就让我很不爽了。
作者: langue    时间: 2009-11-30 23:17
我继续跑题。写多线程程序确实全都是锁,而且现在fork()的开销也不那么大了吧,几十个httpd进程也未必真正吃掉那么多内存,至少text段是共享的,剩下的就是尽量reduce memory footprint。
作者: hacktao    时间: 2009-12-01 00:05
需要持续不断学习,才能练成的~
作者: kanhfshiys    时间: 2009-12-01 01:09
还是自己去学习吧!
作者: accessory    时间: 2009-12-01 02:47
基本同意17楼的. 我说下我的理解吧:
优化分成很多层次, 1)设计层次,2)C代码实现,3)汇编代码实现. 其中的3)基本上由编译器做掉了, 程序员可以控制的不多,最多是选下优化策略,比如GCC的O1,O2,O3. 或者VS的速度优先还是节省空间优先.

在优化之前,首先要明确目标. 节省空间和提高效率并不一定可以同时做到,有时还会互相矛盾. 所以你要明确到底是节省空间重要,还是提高速度更重要.

其次,要明确程序的什么地方是效率最低的,需要优化的. 我觉得大多数情况下, 20/80原理基本适用. 也就是说20%的代码占掉了80%的空间或者时间. 所以重点是优化那20%的代码.其他部分没必要太费心. 类似的,程序员要知道那些操作是浪费时间或者空间的. 费时的操作有:I/O, SYSTEM CALL,没用的PRINTF等. 浪费空间的的例子比如一个很大的数组,实际上用到的很少几个元素. 关于如何找到效率最低的代码部分,可以利用各种PROFILE工具.

最后,举1,2个设计阶段优化的例子.
例子1, 假设你的程序要多次处理一个文件,这时有2种做法. 做法1,每次要处理文件时打开文件,处理完关闭. 做法2,只打开一次文件,然后把内容保存到内存里.后面直接对内存里的数据操作,最后再看情况是否写回文件.
做法1节省空间,但是浪费时间. 做法2浪费一些空间但是节省时间. 最后怎么做就看文件的大小以及打开的次数到底多不多来看了.

例子2, 假设你有一个定时器,每过一段时间就做一些事情.那么这个定时器的间隔时间就是一个重要的参数. 间隔1秒和间隔10的差别不言而喻. 在满足设计要求的情况下,间隔时间越长,占用的CPU时间越少.

总之,设计的时候先明确要实现的目标,然后在满足设计目标的前提下进行优化.
作者: canwolf    时间: 2009-12-01 08:36
时间和空间是矛盾。

作者: wolfired    时间: 2009-12-01 10:26
这个问题真要较真,分分钟要说到0和1上去!
经验是在工作中累积的,不断的思考别人写的代码,反思自己写的代码,相信慢慢的会有收获!
没有千篇一律的好代码,更没有绝对的坏代码!特别是现在编译器为我们做了太多事!
作者: jerrymy    时间: 2009-12-01 11:16
原帖由 cugb_cat 于 2009-11-29 14:19 发表

去看APUE的相关章节


APUE关于存储空间的布局讲的不多啊。
作者: hansion3406    时间: 2009-12-01 15:27
说了半天都是废话...
作者: charming72    时间: 2009-12-01 16:26
标题: 回复 #36 hansion3406 的帖子
那我就也多在线程上废点儿话

其实大家恨线程都是在说线程比进程需要更多的管理。不过大家要注意一点就是,管理是需要成本的。就好比领导赚的多了,成本自然增加了
作者: a1406    时间: 2009-12-01 17:01
我真没看懂上面控诉多线程的理由
线程里面lock太多  那也是有并发访问的时候才要lock啊。 你如果多近程并发访问同一个数据,不也要同步么。
如果怕某个线程挂掉影响其他业务而用多进程那我能理解。
而效率上,多进程比多线程怎么会好呢?如果你各个进程可以不用访问临界资源,那我多线程为什么不可以啊。
作者: shingle7720    时间: 2009-12-01 18:13
我也觉得楼上说的有道理,如果线程满篇是lock,那应该也可以说明设计的有问题吧?
作者: shan_ghost    时间: 2009-12-01 18:22
这是个坚硬的软话题……

说它坚硬,不妨来看看这个聊聊几行、却值得写一篇学术论文论证的简短程序:

http://blog.csdn.net/iamlazybone/archive/2009/07/30/4393973.aspx

原创  神秘的0x5f3759df之卡马克的开平方算法  收藏

通过《DOOM启示录》 了解了卡马克和罗梅洛的传奇故事...

这是卡马克的一个开平方算法...

  1. # float kamake_sqr(float number) {     
  2. #     long i;     
  3. #     float x, y;     
  4. #     const float f = 1.5F;     
  5. #     x = number * 0.5F;     
  6. #     y = number;     
  7. #     i = *(long *) &y;     
  8. #     i = 0x5f3759df - (i >> 1);     
  9. #     y = *(float *) &i;     
  10. #     y = y * (f - (x * y * y));     
  11. #     y = y * (f - (x * y * y));     
  12. #     return number * y;     
  13. # }     
  14. #     
  15. # main() {     
  16. #     printf("sqr(100)=%f", kamake_sqr(100.0));     
  17. #     getch();     
  18. # }  
复制代码

输出:sqr(100)=9.999964

算法里面求平方根一般采用的是无限逼近的方法,比如牛顿迭代法,

比如求5的平方根,选一个猜测值比如2,那么我们可以这么算
5/2 = 2.5; 2.5+2/2 = 2.25; 5/2.25 = xxx; 2.25+xxx/2 = xxxx ...

这样反复迭代下去,结果必定收敛于sqrt(5)

卡马克牛就牛在选择了0x5f3759df 这个开始值,使得迭代的时候收敛速度暴涨,对于Quake III所要求的精度10的负三次方,只需要一次迭代就能够得到结果。

附加一个小故事:

普渡大学的数学家Chris Lomont看了以后觉得有趣,决定要研究一下卡马克弄出来的这个猜测值有什么奥秘。Lomont也是个牛人,在精心研究之后从理论上也推导出一个最佳猜测值,和卡马克的数字非常接近, 0x5f37642f。卡马克真牛,他是外星人吗?

传奇并没有在这里结束。Lomont计算出结果以后非常满意,于是拿自己计算出的起始值和卡马克的神秘数字做比赛,看看谁的数字能够更快更精确的求得平方根。结果是卡马克赢了... 谁也不知道卡马克是怎么找到这个数字的。

最后Lomont怒了,采用暴力方法一个数字一个数字试过来,终于找到一个比卡马克数字要好上那么一丁点的数字,虽然实际上这两个数字所产生的结果非常近似,这个暴力得出的数字是0x5f375a86。

Lomont为此写下一篇论文,"Fast Inverse Square Root"。


还有这里: http://tbl.javaeye.com/blog/231425

有兴趣的可以搜下看看相关的论文,看看伟大的卡马克究竟是怎样从这样一些细节开始,把传统的3D算法优化提速10倍之多,以至于我们在486上即可提前享受到3D游戏。

PS:我记得这个游戏最小系统需求好像是486 DX66。
  换句话说,如果没有卡马克,PC上第一款320*240像素的3D游戏需要推迟接近5~8年才能出现——也就是说,到了2000年,你就可以在一台650M以上CPU的电脑上玩320*240像素的全屏3D游戏了。


而这个开平方取倒数算法,不过“仅仅”是把标准库里的 float (1.0/sqrt(x)) 加速了2~4倍而已。

可是,里面用到的那个magic number的选取原理,即便有了专门的论文,我敢说也没几个人能看懂。


那么,这么艰深的话题,有几个人有那么好的牙口,可以啃得动?




可是,另一方面,看看java库当年那个著名的“字符串副本”问题——那么简单,那么低级的小问题,造成了多大的困扰。

这时候,性能/效率问题,又似乎不过是一点点常识而已——是个每个人都可以参与、都可以去捏的软柿子。





于是,不可避免的,又有很多人开始纷纷扰扰: ++i还是i++,究竟怎么写性能才高?一个复杂公式,写成一个表达式快,还是分成几行清晰的写出来快?嵌套if快,还是switch快?for快,还是while快,抑或是do while快?……

一时间,各种各样的“高速”写法闹得一片乌烟瘴气,以至于不得不有人出来高呼: 千万别过早优化,20%的代码占用了80%的处理时间,先写程序,找出那20%代码就好了!



可是,反过来说难道不对吗?一个你意想不到的、极其细微的设计缺陷,就可能导致机器把80%的性能浪费于其上——就如同java那个字符串多次复制bug一样——你怎么敢不在每一个细节上都精打细算?

考虑到越在后面阶段发现的bug将越难修改;那么一个架构设计导致的性能问题,究竟会扯动多么大的一片代码?
(我的亲身经历: 一个已经投入了5000万、开发了的项目,因为数据库设计太差必须返工;而这个数据库设计要返工,那么整个系统就必须从头写,因为所有的模块都和数据库相关!)

甚至于,如果每一万行中,有2000行的的代码可能拖慢2%的性能,而整个软件有100万行代码——这个系统你又该如何优化?
干脆要用户拿3倍的硬件投资来获得和竞争对手一样的性能?
还是回头去优化2000*100=20万行代码?——当然,你还得先在100万行代码中找到这20万行瓶颈代码。

——很多时候,性能问题不是因为一个问题引入的,而是被很多很多罗罗嗦嗦的东西一步步拖累死的。

那么,你为什么不早点做优化?为什么非要拖到性能问题已不可收拾之时?



说白了,性能问题,就是一个人的知识水平问题。

对卡马克等大牛来说,他的代码就是要字斟句酌,就是要在每个细节上都把性能压榨干净——但,看他的代码,有模糊、臃肿、怪异之感吗?
清澈如水。你什么都看的清清楚楚,但,却有很多地方,别人就是给你解释,你都不一定能懂。

相反,对刚刚入门的普通程序员来说,首先把代码写干净、写规范,这个任务就已经很不容易了。
至于性能,将来找热点再优化吧。

至于中高级程序员呢,把代码写干净、写规范已经是很容易的事情了;那么下一步,就是敲入每行代码前都要想一想,看看究竟怎么才会快——但同时又绝对不能影响可读性。


换句话说: 把代码写的干净、整齐、易懂,是一件不需努力就可以做到的事;而把机器的性能充分压榨出来,则需要更多更深刻的知识打底。

你的知识积累越多,做蠢事的机会就越少,敲进去的代码执行速度就越快——没有什么小经验小技巧可以让你一步登天。

而在此之前,必须知道,编码规范不会影响任何人——包括卡马克。
沉迷于炫耀那些立竿见影的、表驱动的switch快于逐次跳转的if之类的“小技巧”“小聪明”,却忽略了包括编码规范在内的基本功,只会让你永远都理解不了卡马克那大白话一般的代码——甚至是断送作为程序员的职业前景。
作者: slow_hand    时间: 2009-12-01 20:38
原帖由 kanhfshiys 于 2009-11-29 13:26 发表
程序需要注意什么才能尽量做到节省内存或者是提高效率?

记得有本书上说"过早优化乃万恶之源",还有一句是"程序员工具箱中最强大的优化技术就是不做优化"。呵呵。

[ 本帖最后由 slow_hand 于 2009-12-1 20:40 编辑 ]
作者: simulight    时间: 2009-12-01 21:25
0)
作者: kanhfshiys    时间: 2009-12-01 23:54
标题: 回复 #41 slow_hand 的帖子
其实归根结底还是自己不断学习不断积累的经验而已。应当作具体问题具体分析。
作者: baopbird2005    时间: 2009-12-02 08:20
哇塞,都是高手啊。
学习了。
作者: deargodzw    时间: 2009-12-02 09:14
干吗要活在时间和空间编织的宇宙
作者: 雨过白鹭洲    时间: 2009-12-02 10:26
空间节省了,通常意味着会降低时间上的运行效率,自己平衡吧

我到目前为止没做过什么非常要求效率的项目,所以没什么系统优化的经验
作者: cookis    时间: 2009-12-02 10:32
少吃馒头多吃菜
作者: charming72    时间: 2009-12-02 10:35
标题: 回复 #40 shan_ghost 的帖子
可惜呀,认真做优化的时代一去不复返了。多数情况下都是用硬件换性能,这都是快餐经济的结果,让人们只认钱,不节约,浪费资源。Java其实从出生就是个浪费的孩子,还有就是现在其他虚拟机技术大行其道,这都是以资源换取所谓的便利,但都是要付出管理成本的。

唉,一言难尽。好的东东不一定都流行
作者: 雨过白鹭洲    时间: 2009-12-02 10:44
标题: 回复 #48 charming72 的帖子
这样才能推动计算机的发展嘛,我没觉得什么不好

本来以硬件换性能就是首选,但这并不意味着你可以忽略系统和架构,还有性能等因素
作者: charming72    时间: 2009-12-02 10:57
原帖由 雨过白鹭洲 于 2009-12-2 10:44 发表
这样才能推动计算机的发展嘛,我没觉得什么不好

本来以硬件换性能就是首选,但这并不意味着你可以忽略系统和架构,还有性能等因素


同意硬件换性能是首选,但这恰恰让很多人忽略系统和架构,以及优化。

可能扯得远了点儿,硬件的过渡发展使得软件的发展有些脱节,计算过剩也是浪费资源的表现。以物质刺激消费带动经济发展,只能让人更贪婪,失去节俭的美德。对不起,真的扯得远了。
作者: wangdan1600    时间: 2009-12-02 11:15
有些时候优化是需要的。

比如我们这有一个DFA程序,即使使用MIPS 12个核跑,也达不到4个G的线速。
作者: maxxfire    时间: 2009-12-02 12:31
线程资源共享了,数据访问简单直接了,但同时带来了资源的一致性和回收的问题。
我觉得lock不是线程最大的问题,lock多不要紧,只要lock的时间尽量的短。
线程较大的问题应该是异常的处理,进程多简单,直接kill掉就好了。但一个线程发生异常要杀死时,必须把它分配的内存释放、打开的句柄回收、以及打开的锁关闭,否则将直接和长期的影响所在的进程。。
作者: wendy0552    时间: 2009-12-02 13:13
从如果节省内存,提高效率提升到程序的优化,然后到线程和进程的孰优孰劣,再到要不要优化,大家都站在比较高的地方来看待这个问题,我是低手,给个实用点的,记得在某本经典教程中看到,说,当你定义一堆变量的时候尽量先从最小的开始定义,如先定义char,再到int,再到struct等,这样据说可以节省空间,至于效率的我只知道尽量少在循环语句中放入过多代码,要短小精悍.
作者: shan_ghost    时间: 2009-12-02 13:17
硬件是换不来性能的。

硬件性能的提升,不过是给了一些人“多掏钱以(在一定程度上)弥补技术差距”或者“多掏钱以便稍微少动点脑筋”的机会而已。


比如我多次提到的那家公司,200多人花了5000多万做了几年,结果一个设计用户2000万的数据库里,仅仅插入了1万条记录,系统一次每日统计就要消耗6个多小时——因为数据库设计渣了,查询复杂度高于O(N^2)。

但,如果修改数据库,那么已有的80%以上代码就得重写。

那么,各位不妨算算,看看这个项目买下全球的所有电脑,能不能弥补这点性能差距。
作者: shan_ghost    时间: 2009-12-02 13:58
1、刚刚知道性能
如果你只知道switch比嵌套if快、++i和i++性能有差异,那么千万不要拿这些知识去优化你的代码

因为,要么编译器比你做得更好;要么你得到的那么一点点性能根本不足以弥补程序可读性、可靠性方面的损失。


2、算法达人
如果你能理解卡马克取X平方的倒数的算法的每一个细节——包括那个魔法数的选择、包括如何利用IEEE浮点数的特点而使用整数运算指令来计算浮点近似值等等——那么,想必你已经对库的实现有了相当程度的了解;这时候,是否该优化,你应该已经有了自己的判断标准,不劳别人饶舌了。


3、理解和用对算法
如果你的知识水平介于以上两者之间,那么,请尽量选择优化更好、更稳定的库,并注意选用库里提供的、更适合你面对问题的算法——这已经足够了。除非情况特殊,不要随便自己动手优化,因为你所能想到的优化方法,库里往往已经有了。

举例来说,对同样一组数据,采用链表、队列、树或者map、hash_map等不同容器来存储,那么再对它进行插入、删除、查找等工作时,性能差异是相当大的——很可能用这种容器快的感觉不到任何延迟;换另一种容器就导致项目失败。




就目前中国的水平来说,能达到“选择合适的容器/算法以配合实际需要”这一步基本已经够用了。能理解和利用卡马克等人的思路改进已有算法的,国内也有几家大游戏公司需要这种人才;至于能挑战卡马克的强人,恐怕中国还没有哪家公司能养得起吧。
作者: hansion3406    时间: 2009-12-02 17:49
跟线程或者进程有什么关系,主要看的是设计上面是不是有什么共享资源的冲突吧.
如果有共享,一样的,进程也不是一样要用得到SHM..
现在的操作系统,线程跟进程的差别,在业务的应用上有这么多区别吗?
效率跟这种系统的内核部件已经没有什么关系了..

所以,废话这么多没有用,还是去想想,为什么会有共享资源冲突,
怎么去解决或者做业务的分离来得更好..
节省内存?我想没有必要吧..现在再烂的服务器,没有个十几G的内存都不好意思跟别人打招呼..


还有什么问题??




欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2