一次小项目的思考

百度的开发经理竟然公开表扬CPU,主板生产厂商,看来我们软件是落后硬件很多年了.

让Cpu和IO同时达到95%以上其实很简单,让几个IO操作大的程序进行竞争 绝对IO 100% CPU 100% 估计操作系统缓存也会100%  开个LOADRUNER就做到

有点太弱了吧
1>绝对IO 100% CPU 100% + 估计操作系统缓存也会100% ，自相矛盾
2>开个LOADRUNER就做到，如果你出LOADRUNER一样的软件，那可以说简单
3>我们测试组使用LOADRUNER，没有测试到这个水平，因为我们的后台程序处理能力达不到这个情况

不要告诉我LOADRUNER把客户机达到cpu 100%，io 100%，这是人家LOADRUNER的功劳，你做的后台能达到不？你做的前台能达到不


无知者的狂妄

如果你能写出IO和CPU都占用100%的程序，请指教：
1>你是如何观察到的?观察手段
2>你是让你的进程占用完除操作系统以外的cpu和io，请考虑下面几个因素
   a)多核情况下
   b)操作系统也有进程，也要占用cpu和io

不要告诉你在JVM上就可以达到

我说过要靠竞争 比如NIO 你多注册几个无关事件CPU可以达到很高的  正常如果CPU空转情况下 比如WHILE里面没有休眠基本是100的   IO高这块 你只要通过操作系统写缓存的操作达到  一般在操作系统大量频繁写缓存的时候就会发生了 只要你IO操作的数据量够大并且够频繁

请指教:
1>那个版本的jvm支持多核？
2>JVM只是一个进程，怎么保证一个进程将cpu除操作系统运行和切换后的cpu分配到jvm上？

并不是反驳这个观点 只是比较关注 期待中

我们不能简单地从开源工具Hibernate等以讨论数据库的发展。数据库理论体系是个完整强大的根基，有自己的多年实践形成的业界规范。像Hibernate等只是方便我们助于开发的工具而已，虽然它自己也有规范的东西，毕竟不能和数据库的理论规范相讨论而说明它们哪个不好不足什么的。

1. 我好像还没有用过不支持多核的jvm。。有谁用过可以告诉我。
2. 一个线程的死循环就可以用一个核或者cpu，也就是让一个核或者cpu到100%，或者说让linux系统的负载+1
   两个线程的死循环就可以用两个核或者cpu，也就是让两个核或者cpu到100%，或者说让linux系统的负载+2
   可以累加。



另外我也说个抬杠的话：

这个帖子讨论的人全部老死的时候，估计数据库还活着。

不知道有谁不同意。呵呵

我不同意什么“数据库已死”的说法，但我也不同意在系统设计阶段就让设计数据库的工作掺和进来，我想这也是楼主想说的。

我不止一次地在项目中听到人说：“干嘛折腾什么业务逻辑的设计，把数据库设计好了，你想显示什么，一个sql语句就能搞定。”说这话的人大概没有想过：“干嘛折腾什么高级语言，把汇编学好了，什么软件编不出来。”很多时候，数据库的结构设计好了，并不能表示完成系统设计也指日可待了。若在设计阶段就轻视业务逻辑层面上的面向对象的设计，后续的工作将举步维艰。

举个真实的例子，很多购物系统都会有“order”这么个东西，系统或大或小，或简或繁，但是设计数据表是很轻松的：“分析order从哪来，到哪去，就知道了它需要哪些字段，然后再加上一些额外的字段作为备用，这样不管它将来怎么变，总该万变不离其宗吧！”

数据表都有了，当然该写程序了。当功能即将完工时，客户提出，有些订单项，当它跟另一个订单项在一起时，是可以自动作为赠品的；有一些商品需要捆绑销售，order要打个折扣。

Leader（或者项目经理）觉得这种变更不会影响到数据表，改起来应该很容易，但真正改起来，却牵一发而动全身：系统到处冒bug和exception，程序员的头上也差点要冒烟。

好不容易改好了，客户看完又提出，order可以有多个发货地址。多简单的一句话啊，可是触碰到数据表的修改了，不用说，又是一阵捉虫的恶战。

后来客户又提出，order可以用打折码来打折，可以用礼券来抵价……面对这种屡次三番的修改，以数据库设计为出发点的系统，稳定性能怎样？而一个购物系统的order处理都不稳定，又有谁敢用呢？

这就是重数据库设计，轻对象设计的恶果，因为仅凭数据表和E-R图，很难考虑到对象继承、多态等基本的代码重用设计，更别说设计模式了。我敢说，每天都有软件公司、开发团队发生这样的事。而千万不要说为什么一开始不把需求弄清楚，因为需求的变化是永远存在的。

这样说，岂不是软件开发做不下去了？其实不然，GOF的设计模式就能够很好地面对这些变化，设计模式最强大的地方就是，它虽然不能告诉你需求会怎样变，但它总能够给变化留下空间，让变更的过渡更加容易。

实际上，做应用软件的，就应该以面向对象的系统设计为主，数据库的设计随后跟上。如果有疑问，那么可以想象一下这样的情形：

假设Amazon提供一个数据持久化的服务，不管你使用什么语言，只要你把对象传给它，它就能给你存起来，下次你取出来，还能照样用。这样你就不用管数据库的设计了，想管也管不了了，就可以专心去做面向对象的设计了。经历了若干次的变动和修改，你的软件交付了。直到有一天，Amazon告诉你，其实它们一直是用Mysql存储你的数据的。它们给你一个数据库的备份和一个ORM层的实现，就不用连接它的服务器了。那么各位你一定不会觉得难办，因为你的面向对象的系统设计已是完好的，更换的只是一个存储对象数据的地方而已。

所以我认为，从数据库为主线的系统设计，是有弊端的，重点应该是业务逻辑层的面向对象的设计。但数据库设计也并非不重要，它的表结构的优化，性能的优化，应该在整个软件的生命周期内，持续地进行。

什么叫做“数据库已死”？
当你某天清晨醒来，发现是被老板揪起来的。。。
他说：你怎么又把数据库搞死了？
你说：那不是我搞死的，是大家一起搞死的。。。