读书，收获，分享
建议后面的五角星仅代表笔者个人需要注意的程度。
Talk is cheap.Show me the code
建议132：提升Java性能的基本方法★☆☆☆☆
- 不要在循环条件中计算，循环一遍就要计算一次，这会降低系统效率。
- 尽可能把变量、方法声明为
finalstatic类型 - 缩小变量的作用范围，其目的是加快
GC的回收。 - 频繁字符串操作使用
StringBuilder或StringBuffer - 使用非线性检索
- 覆写
Exception的fillInStackTrace方法 - 不建立冗余对象
建议133：若非必要，不要克隆对象★☆☆☆☆
一般情况下new生成的对象比clone生成的性能方面要好很多。
建议134：推荐使用“望闻问切”的方式诊断性能☆☆☆☆☆
性能优化是一个漫长的工作，特别是对于偶发性的性能问题，不要期望找到“名医”立刻就能见效，这是不现实的，深入思考，寻根探源，最终必然能找到根源所在。
注意：性能诊断遵循“望闻问切”，不可过度急躁。
建议135：必须定义性能衡量标准★☆☆☆☆
性能衡量标准是技术与业务之间的契约
性能衡量标志是技术优化的目标
性能衡量标准必须在一定的环境下，比如网络、操作系统、硬件设备等确定的情况下才会有意义，并且还需要限定并发数、资源数（如10万数据和1000万的数据响应时间肯定不同）等。
建议136：枪打出头鸟—解决首要系统性能问题★☆☆☆☆
解决性能问题时，不要把所有的问题都摆在眼前，这只会“扰乱”你的思维，集中精力，找到那个“出头鸟”，解决它，在大部分情况下，一批性能问题都会迎刃而解，而且我们的用户关注最多的可能就是系统20%的功能，可能我们解决了这一部分，已经达到了用户的预期目标，也就标志着我们的优化工作可以结束了。
注意：解决性能优化要“单线程”小步前进，避免关注点过多而导致精力分散。
建议137：调整JVM参数以提升性能★☆☆☆☆
-
调整堆内存大小
在JVM中有两种内存：栈内存（Stack）和堆内存（Heap），栈内存的特点是空间比较小，速度快，用来存放对象的引用及程序中的基本类型；而堆内存的特点是空间比较大，速度慢，一般对象都会在这里生成、使用和消亡。
堆内存的调整不能太随意，调整得太小，会导致
Full GC频繁执行，轻则导致系统性能急速下降，重则导致系统根本无法使用；调整得太大，一则是浪费资源（当然，若设置了最小堆内存则可以避免此问题），二则是产生系统不稳定的情况。 -
调整堆内存中各分区的比例
JVM的堆内存包括三部分：新生区（
Young Generation Space）、养老区（Tenure generation space）、永久存储区（Permanent Space），其中新生成的对象都在新生区，它又分为伊甸区（Eden Space）、幸存0区（Survivor 0 Space）和幸存1区（Survivor 1 Space），当在程序中使用了new关键字时，首先在伊甸区生成该对象，如果伊甸区满了，则用垃圾回收器先进行回收，然后把剩余的对象移动到幸存区（0区或1区），可如果幸存区也满了呢？垃圾回收器会再回收一次，然后再把剩余的对象移动到养老区，那要是养老区也满了呢？此时就会触发Full GC（这是一个非常危险的动作，JVM会停止所有的执行，所有系统资源都会让位给垃圾回收器），会对所有的对象过滤一遍，检查是否有可以回收的对象，如果还是没有的话，就抛出OutOfMemoryError错误，系统不干了！ -
变更GC的垃圾回收策略
Java程序性能的最大障碍就是垃圾回收，我们不知道它何时会发生，也不知道它会执行多长时间，但是我们可以想办法改变它对系统的影响，比如启用并行垃圾回收、规定并行回收的线程数量等。
-
更换
JVM目前市面上比较流行的JVM有三个产品：
Java HotSpot VM、Oracle JRockit JVM、IBM JVM，其中HotSpot是我们经常使用的，稳定性、可靠性都不错；JRockit则以效率著称，性能是它的优势，但在决定使用该JVM之前一定要做好全面的系统测试，它的某些行为可能会在JRockit上产生Bug；IBM JVM也比较稳定，而且它在AIX系统上的表现要远远好于其他操作系统。
建议138：性能是个大“咕咚”☆☆☆☆☆
有一部动画片叫《咕咚来了》，其大致剧情是：三只小兔在湖边玩耍，忽然湖中传来“咕咚”一声，这奇怪的声音把小兔们吓了一大跳。小兔们刚想去看个究竟，又听到“咕咚”一声，这可把小兔们吓坏了，“快跑，咕咚来了，快逃呀！”小兔们转身就跑。
狐狸正同小鸟跳舞，与跑来的兔子碰了个满怀。狐狸一听“咕咚来了！”也紧张起来，跟着就跑。它们又惊醒了睡觉的小熊和树上的小猴，小熊和小猴也不问青红皂白，跟着它们跑起来，于是一路上跟着跑的动物越来越多，大象、河马、老虎、野猪……
岸上这阵骚乱，让湖中的青蛙感到十分惊讶，它拦住了这群吓蒙了的伙伴们，问出了什么事，大家七嘴八舌地形容“咕咚”是个多么可怕的怪物。青蛙问：“谁见到了？”大家互相推诿，谁也没有亲眼看见，于是决定回去看看明白。
回到湖边，又听见“咕咚”一声，仔细一看，原来是木瓜掉进水里发出的声音，众动物不禁大笑起来。
某些Javaer一直在质疑Java系统的性能，于是我们自己也跟着怀疑Java的性能—这就是发生在我们身边的真实“咕咚”，Java系统的性能问题本就是子虚乌有的事情，是我们自己吓唬自己，其实，我们可以从四个方面分析该问题：
- 没有慢的系统，只有不满足业务的系统
- 没有慢的系统，只有架构不良的系统
- 没有慢的系统，只有懒惰的技术人员
- 没有慢的系统，只有不愿意投入的系统
注意：对现代化的系统建设来说，性能就是一个大“咕咚”—看清它的本质吧。
