1700452069
1700452070
new Apple();
1700452071
1700452072
}
1700452073
1700452074
long end=System.nanoTime();
1700452075
1700452076
System.out.println(“new生成对象耗时:”+(end-mid)+“ns”);
1700452077
1700452078
}
1700452079
1700452080
在上面的代码中,Apple是一个简单的可拷贝类,用两种方式生成了10万个苹果:一种是通过克隆技术,一种是通过直接种植(也就是new关键字),按照我们的常识想当然地会认为克隆肯定比new要快,但是结果却是这样的:
1700452081
1700452082
clone方法生成对象耗时:18731431 ns
1700452083
1700452084
new生成对象耗时:2391924 ns
1700452085
1700452086
不用看具体的数字,数数位数就可以了:clone方法花费的时间是8位数,而new方法是7位数,用new生成对象比clone方法快很多!原因是Apple的构造函数非常简单,而且JVM对new做了大量的性能优化,而clone方式只是一个冷僻的生成对象方式,并不是主流,它主要用于构造函数比较复杂,对象属性比较多,通过new关键字创建一个对象比较耗时间的时候。
1700452087
1700452088
注意 克隆对象并不比直接生成对象效率高。
1700452089
1700452090
1700452091
1700452092
1700452094
编写高质量代码:改善Java程序的151个建议 建议134:推荐使用“望闻问切”的方式诊断性能
1700452095
1700452096
“望闻问切”是中医诊断疾病的必经步骤,“望”是指观气色,“闻”是指听声息,“问”是指询问症状,“切”是指摸脉象,合称“四诊”,经过这四个步骤,大夫基本上就能确认病症所在,然后加以药物调理,或能还以病人健康身躯。
1700452097
1700452098
一个应用系统如果出现性能问题,不管是偶发性问题还是持久性问题,都是系统“生病”的表现,需要工程师去诊断,然后对症下药。我们可以把Java的性能诊断也分为此四个过程(把我们自己想象成医生吧,只是我们的英文名字不叫Doctor,而是叫做Trouble Shooter):
1700452099
1700452100
(1)望
1700452101
1700452102
观察性能问题的症状。有人投诉我们开发出的系统性能慢,如蜗牛爬行,执行一个操作,在等待它返回的过程中,用户已经完成了倒水、喝茶、抽烟等一系列消遣活动,但系统还是没返回结果!其实这是个好现象,至少我们能看到症状,从而可以对症下药。性能问题从表象上来看可以分为两类:
1700452103
1700452104
不可(或很难)重现的偶发性问题
1700452105
1700452106
比如线程阻塞,在某种特殊条件下,多个线程访问共享资源时会被阻塞,但不会形成死锁,这种情况很难去重现,当用户打电话投诉时,我们自己赶到现场症状已经消失了,然后1个月内再也没有出现过,当我们都认为“磨合”期已过,系统已经正常运行的时候,又接到了类似的投诉,崩溃呀!对于这种情况,“望”已经不起作用了,不要为了看到症状而花费大量的时间和精力,可以采用后续提到的“闻问切”方式。
1700452107
1700452108
可重现的性能问题
1700452109
1700452110
客户打电话给我们,反映系统性能缓慢,不需要我们赶到现场,自己观察一下生产机就可以发现部分交易缓慢,CPU过高,可用内存较低等问题,在这种情况下我们至少要测试三个有性能问题的交易(或者三个与业务相关而技术无关的功能,或者与技术有关而业务无关的功能),为什么是三个呢?因为“永远不要带两块手表”,这会致使无法验证和校对。
1700452111
1700452112
比如三个不同的输入功能,都是用户输入信息,然后保存到数据库中,但是三个交易的性能都非常缓慢,通过初步的“望”我们就可以基本确认是与数据库或数据驱动相关的问题;若是只有一个交易缓慢,其他两个正常,那就可以大致定位到一个面:该交易的逻辑层出现问题。
1700452113
1700452114
(2)闻
1700452115
1700452116
中医上的“闻”是大夫听(或嗅)患者不自觉发出的声音和气味,在性能优化上的“闻”则是关注项目被动产生的信息,其中包括:项目组的技术能力(主要取决于技术经理的技术能力)、文化氛围、群体的习惯和习性,以及他们专注和擅长的领域等,各位读者可能要疑惑了:中医上“闻”的对象是病人,而为什么这里“闻”的对象却是开发团队呢?
1700452117
1700452118
我们这样来思考该问题,如果是一个人(个体)生病了,找大夫如此处理是没有任何问题的,但是如果是人类(群体)生病了,那如何追寻这个根源呢?假设人是上帝创造的,如果有一群外星生物说“人类都有自私的缺陷”,那是不是应该去观察一下上帝?了解这个缺陷是源于他的习惯性动作还是技能缺乏,或者是“文化传承”。对于一个Java应用来说,我们就是“上帝”,我们创造了他,给了他生命(能够运行),给了他尊严(用户需要它),给了他灵魂(解决了业务问题),那一旦他生病,是不是应该审视一下我们这些“上帝”呢?或者我们得自我反省一下呢?
[
上一页 ]
[ :1.700452069e+09 ]
[
下一页 ]