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 ]
[
下一页 ]