刚刚看到一篇很好的文章,仔细一看,我犯了其中的很多忌讳,拿出来和大家分享一下,同时欢迎各位补充,或者你的相同的经历,留给后来者的经验,欢迎分享
Java编程中“为了性能”尽量要做到的一些地方
分类: java规范 2012-08-15 09:40 2人阅读 评论(0) 收藏 编辑 删除
 2012年8月15日摘自:http://www.cnblogs.com/dzly/archive/2012/3/11.htmlJava编程中“为了性能”尽量要做到的一些地方最近的机器内存又爆满了,除了新增机器内存外,还应该好好review一下我们的代码,有很多代码编写过于随意化,这些不好的习惯或对程序语言的不了解是应该好好打压打压了。 
下面是参考网络资源总结的一些在Java编程中尽可能要做到的一些地方。1. 尽量在合适的场合使用单例
 
使用单例可以减轻加载的负担,缩短加载的时间,提高加载的效率,但并不是所有地方都适用于单例,简单来说,单例主要适用于以下三个方面:
第一,控制资源的使用,通过线程同步来控制资源的并发访问;
第二,控制实例的产生,以达到节约资源的目的;
第三,控制数据共享,在不建立直接关联的条件下,让多个不相关的进程或线程之间实现通信。2. 尽量避免随意使用静态变量
 
要知道,当某个对象被定义为stataic变量所引用,那么gc通常是不会回收这个对象所占有的内存,如1 public class A{
2    static B b = new B();
3 }此时静态变量b的生命周期与A类同步,如果A类不会卸载,那么b对象会常驻内存,直到程序终止。3. 尽量避免过多过常的创建Java对象
 
尽量避免在经常调用的方法,循环中new对象,由于系统不仅要花费时间来创建对象,而且还要花时间对这些对象进行垃圾回收和处理,在我们可以控制的范围内,最大限度的重用对象,最好能用基本的数据类型或数组来替代对象。
 
4. 尽量使用final修饰符
 
带有final修饰符的类是不可派生的。在Java核心API中,有许多应用final的例子,例如java.lang.String。为String类指定final防止了使用者覆盖length()方法。另外,如果一个类是final的,则该类所有方法都是final的。Java编译器会寻找机会内联(inline)所有的final方法(这和具体的编译器实现有关)。此举能够使性能平均提高50%。
 
5. 尽量使用局部变量
 
调用方法时传递的参数以及在调用中创建的临时变量都保存在栈(Stack)中,速度较快。其他变量,如静态变量、实例变量等,都在堆(Heap)中创建,速度较慢。6. 尽量处理好包装类型和基本类型两者的使用场所
 
虽然包装类型和基本类型在使用过程中是可以相互转换,但它们两者所产生的内存区域是完全不同的,基本类型数据产生和处理都在栈中处理,包装类型是对象,是在堆中产生实例。
在集合类对象,有对象方面需要的处理适用包装类型,其他的处理提倡使用基本类型。7. 慎用synchronized,尽量减小synchronize的方法
 
都知道,实现同步是要很大的系统开销作为代价的,甚至可能造成死锁,所以尽量避免无谓的同步控制。synchronize方法被调用时,直接会把当前对象锁 了,在方法执行完之前其他线程无法调用当前对象的其他方法。所以synchronize的方法尽量小,并且应尽量使用方法同步代替代码块同步。8. 尽量使用StringBuilder和StringBuffer进行字符串连接
 
这个就不多讲了。9. 尽量不要使用finalize方法
 
实际上,将资源清理放在finalize方法中完成是非常不好的选择,由于GC的工作量很大,尤其是回收Young代内存时,大都会引起应用程序暂停,所以再选择使用finalize方法进行资源清理,会导致GC负担更大,程序运行效率更差。
 
10. 尽量使用基本数据类型代替对象
 
String str = "hello";
上面这种方式会创建一个“hello”字符串,而且JVM的字符缓存池还会缓存这个字符串;
String str = new String("hello");
此时程序除创建字符串外,str所引用的String对象底层还包含一个char[]数组,这个char[]数组依次存放了h,e,l,l,o
 
11. 单线程应尽量使用HashMap、ArrayList
 
HashTable、Vector等使用了同步机制,降低了性能。
 
12. 尽量合理的创建HashMap
 
当你要创建一个比较大的hashMap时,充分利用另一个构造函数
public HashMap(int initialCapacity, float loadFactor)
避免HashMap多次进行了hash重构,扩容是一件很耗费性能的事,在默认中initialCapacity只有16,而loadFactor是 0.75,需要多大的容量,你最好能准确的估计你所需要的最佳大小,同样的Hashtable,Vectors也是一样的道理。
 
13. 尽量减少对变量的重复计算
 

for(int i=0;i<list.size();i++)
应该改为
for(int i=0,len=list.size();i<len;i++)
并且在循环中应该避免使用复杂的表达式,在循环中,循环条件会被反复计算,如果不使用复杂表达式,而使循环条件值不变的话,程序将会运行的更快。 
 
14. 尽量避免不必要的创建
 

A a = new A();
if(i==1){list.add(a);}
应该改为
if(i==1){
A a = new A();
list.add(a);}
 
15. 尽量在finally块中释放资源
 
程序中使用到的资源应当被释放,以避免资源泄漏。这最好在finally块中去做。不管程序执行的结果如何,finally块总是会执行的,以确保资源的正确关闭。 
 
16. 尽量使用移位来代替'a/b'的操作
 
"/"是一个代价很高的操作,使用移位的操作将会更快和更有效

int num = a / 4;
int num = a / 8;
应该改为
int num = a >> 2;
int num = a >> 3;
但注意的是使用移位应添加注释,因为移位操作不直观,比较难理解
 
17.尽量使用移位来代替'a*b'的操作
 
同样的,对于'*'操作,使用移位的操作将会更快和更有效

int num = a * 4;
int num = a * 8;
应该改为
int num = a << 2;
int num = a << 3;
 
18. 尽量确定StringBuffer的容量
 
StringBuffer 的构造器会创建一个默认大小(通常是16)的字符数组。在使用中,如果超出这个大小,就会重新分配内存,创建一个更大的数组,并将原先的数组复制过来,再 丢弃旧的数组。在大多数情况下,你可以在创建 StringBuffer的时候指定大小,这样就避免了在容量不够的时候自动增长,以提高性能。 
如:StringBuffer buffer = new StringBuffer(1000);  
 
19. 尽量早释放无用对象的引用
 
大部分时,方法局部引用变量所引用的对象 会随着方法结束而变成垃圾,因此,大部分时候程序无需将局部,引用变量显式设为null。
例如:1 Public void test(){
2    Object obj = new Object();
3    ……
4    Obj=null;
5 }上面这个就没必要了,随着方法test()的执行完成,程序中obj引用变量的作用域就结束了。但是如果是改成下面:1 Public void test(){
2    Object obj = new Object();
3    ……
4   Obj=null;
5    //执行耗时,耗内存操作;或调用耗时,耗内存的方法
6    ……
7 }这时候就有必要将obj赋值为null,可以尽早的释放对Object对象的引用。
 
20. 尽量避免使用二维数组
 
二维数据占用的内存空间比一维数组多得多,大概10倍以上。
 
21. 尽量避免使用split
 
除非是必须的,否则应该避免使用split,split由于支持正则表达式,所以效率比较低,如果是频繁的几十,几百万的调用将会耗费大量资源,如果确实需 要频繁的调用split,可以考虑使用apache的StringUtils.split(string,char),频繁split的可以缓存结果。
 
22. ArrayList & LinkedList
 
一 个是线性表,一个是链表,一句话,随机查询尽量使用ArrayList,ArrayList优于LinkedList,LinkedList还要移动指 针,添加删除的操作LinkedList优于ArrayList,ArrayList还要移动数据,不过这是理论性分析,事实未必如此,重要的是理解好2 者得数据结构,对症下药。
 
23. 尽量使用System.arraycopy ()代替通过来循环复制数组
 
System.arraycopy() 要比通过循环来复制数组快的多 
 
24. 尽量缓存经常使用的对象
 
尽可能将经常使用的对象进行缓存,可以使用数组,或HashMap的容器来进行缓存,但这种方式可能导致系统占用过多的缓存,性能下降,推荐可以使用一些第三方的开源工具,如EhCache,Oscache进行缓存,他们基本都实现了FIFO/FLU等缓存算法。
 
25. 尽量避免非常大的内存分配
 
有时候问题不是由当时的堆状态造成的,而是因为分配失败造成的。分配的内存块都必须是连续的,而随着堆越来越满,找到较大的连续块越来越困难。
 
26. 慎用异常
 
当创建一个异常时,需要收集一个栈跟踪(stack track),这个栈跟踪用于描述异常是在何处创建的。构建这些栈跟踪时需要为运行时栈做一份快照,正是这一部分开销很大。当需要创建一个 Exception 时,JVM 不得不说:先别动,我想就您现在的样子存一份快照,所以暂时停止入栈和出栈操作。栈跟踪不只包含运行时栈中的一两个元素,而是包含这个栈中的每一个元素。
如 果您创建一个 Exception ,就得付出代价。好在捕获异常开销不大,因此可以使用 try-catch 将核心内容包起来。从技术上讲,您甚至可以随意地抛出异常,而不用花费很大的代价。招致性能损失的并不是 throw 操作——尽管在没有预先创建异常的情况下就抛出异常是有点不寻常。真正要花代价的是创建异常。幸运的是,好的编程习惯已教会我们,不应该不管三七二十一就 抛出异常。异常是为异常的情况而设计的,使用时也应该牢记这一原则。

解决方案 »

  1.   

    其实现代的java虚拟机已经做的很好了,上面的观点有些偏激.
    套用Effective java中的一句话:"要试图写好的程序,而不是快的程序",即使在内存资源非常宝贵的环境这一点也适用.
      

  2.   

    如果在写java程序的过程中你有很多担心:用位移替代乘除法效率会不会更高点?枚举比起类型标识变量是不是内存占用更大?过多的拆分出小函数会不会导致因为函数调用而引发的性能问题?一个对象无用了显式置null会不会很快释放内存?每写一行代码是不是都要考虑有没有更好的方式从而让内存占用更小?如果一直纠结于这种问题,那么你绝对写不出一个好的java程序来,相反,我感觉你更适合去用C语言.
    推荐effective java中关于"谨慎地进行优化"一节的阐述:规则1,不要进行优化,规则2,还是不要进行优化.
    还有<重构改善既有代码的设计>一书关于"重构与性能"一节的描述.
      

  3.   

    在功能满足的前提下,考虑性能是应该的一个对象无用了显示置NULL会不会很快释放内存?这要取决于JVM的GC机制,但如楼主举的离子,如果没有显示置NULL GC一定不会回收该对象占用的空间JAVA是一个从宏观,到微观都需要去思考的语言,在一个项目的开发周期中,不同的阶段要关注的点也不同的简单的一排序来说,JAVA API提供了排序方法,但其使用的算法对我们的程序一定是最优的吗?必须我们很确定我们的数组80%以上都是有序的,那选择冒泡排序是不是更好呢引用2楼的话:“如果一直纠结于这种问题,那么你绝对写不出一个好的java程序来”,但如果你从来不考虑这些问题,你一样也写不出好的程序无论是JAVA还C亦或是其他语言。
      

  4.   

    "引用2楼的话:“如果一直纠结于这种问题,那么你绝对写不出一个好的java程序来”,但如果你从来不考虑这些问题,你一样也写不出好的程序无论是JAVA还C亦或是其他语言。"顶
      

  5.   

    很多是不靠谱的。
    像static、final等都应该从设计角度考虑问题,而非所谓的“性能”。
      

  6.   

    好像楼主的东西都是那个 叫effictive java 里的东东。 你还不如买本书去年,这书确实还是有用。特别对于事后的回顾、学习和改进有用
      

  7.   

    很明显,很多是违背Effective Java里的建议的。
      

  8.   

    有些东东在性能调优的时候可以作为参考,不过最好是更改出现性能瓶颈的地方,不然你就可能做无用功了,好的设计一般更重要,不过在兼顾好的设计前提下,想要进行性能调优,单知道几个原则是不够的,还得善于使用性能检测工具和深入了解其中的原理(比如多线程下很多类库都是用了一个叫AbtractQueuedSynchronizer,简称AQS,有多少人了解这个类乃至源码?又有多少人在并发程序调优时想过用ThreadFactory定制线程池?),这样才能更好的性能调优。
    比如多线程的调优,新类库直接深入机器层次了。
    还有我在一些好书上看到一个比较好的开源工具,可以试着用下,FindBugs,执行静态代码检查,会检测出很多丑陋的代码,多看那些上面的建议要好些。Effective Java上面的建议也不错,不过还比较少,才70多条
      

  9.   

     
    同样的,对于'*'操作,使用移位的操作将会更快和更有效

    int num = a * 4;
    int num = a * 8;
    应该改为
    int num = a << 2;
    int num = a << 3;
     
    学习了,,,,, 
      

  10.   

    其实我个人认为,其实更要根据开发环境要求。就比如中国某些大网站,开始页就是个大的Flash啥的,整的网速差的兄弟痛不欲生啊~~~~~~~一方面要漂亮但也要考虑实用性啊!
      

  11.   

        在java的学海里面,有着很多的东西,耐人寻味,引人入胜。
        我在java里也工作3个年头了,不过我觉得自己学的东西仿佛只是java的冰山一角。
    现在一直边工作边学习,在工作的过程中,学会了很多东西,这些都是在书上,在教程当中所学习不到的,特别在项目开发当中的话,觉得"交流"特别重要,不管你个人技术水平有多高,不管你个人全能否,都不外乎需要"交流"。
        Struts1,Struts2,Spring,Hibernate,EJB,Ibabtis等项目经常需要用的框架,我们或者对其已经熟悉的不能再熟悉了,不过,在此又有个很大的弊端,有些工作了些许年的程序员,现在还依旧只知道这些框架怎么去用,但是不知道为什么可以这样去用。说一次我面试的经历,今天老大喊我帮忙去面试个人,我看了下来面试的人的简历,一看工作时间竟然有10年? 我但是心里一颤抖,尽然我这个刚工作3年面试一个10年经验的不过,后面开始面试了,我也稍许淡定了些,不为什么,就因为我觉得对面的10年工作程序员也不过如此。因为,我问了他关于框架的东西,他无所不知,问他一个问题,他可以回答我3个出来,但是我一问java基础,反射,代理模式,单例模式,和这些框架一些底层实现的方法之类的,他竟然像个孩子一样无助的看着我
        我回去之后想了很多,10年的工作经验在开发生涯当中,已经算是"白骨精"(白领,骨干,精英)的境界了,可能说早已经成为管理层的一员了。不过,这位,还依旧在找着编码工作,我并不是有其他的想法,而是我觉得,在很多时候,一件事物的存在时有很多原因的,多方面去关注才能看清楚事物的本质。所以,我想到的就是为什么会这样?第一个,很简单很明显的就是,在工作中,还需要继续的学习。我记得我的以前的老大和我说过一个故事。
         有个面包师,在麦当劳工作了有3年了,每天重复着单一的工作内容,但是在刚开始的觉得过得还不错,因为在那个时候工资待遇不错,工作要求水平也不高,也就这么不错的过着。但是就只在第三年,他的工资依旧没有涨过,他一次和老板提加薪要求,但是被老板一口回绝,并说着:你做的事情每一个不懂的人只需要稍微学习下就行了,你不做自然有人会来做。后来一了解,麦当劳面包师不能说是面包师,而是烹饪师,因为一切的原料都已经做好了,他只需要把那些面包和汉堡之类的放微波炉中,油锅里面热一热,炸一炸就可以出炉了。后来,经人介绍,买下了一个小小的面包作坊,他可能说是自己也了解到自己为什么做了这么久的时间还得不到老板加薪,自己刻苦的钻研着怎么让自己的面包更让顾客喜欢,更吸引别人,后来也就凭着自己的努力,终于做好了自己的品牌,成功了。
         故事说了有点罗嗦,但是你看了之后应该会明白些什么,只有你成为了一个团队,一个生活圈不可或缺的人的时候,你才能活的自由,你才能获得你相应的报酬,如果你是那个获得或缺的人,那你的存在就显得不那么的重要,自然你就不会成为可以主宰的人。
        第二个,怎么继续学习?就像我前面说的,不能只图方便,只图着一时的轻松,周而复始的这么做的,就像说的这个框架你使用的不能再熟练了,但是你还是一样,只是知道怎么使用,但是一个框架的最主要的不是怎么去使用,而是懂得其底层的思想。就想你熟悉的java,如果再让你去学习C#语言,可能不会像你刚学习java的时候那么困难了吧?但是从中,我又想起了一点,不知道是人性的问点,还是个别人的问题。在学习的时候,坚持不了,只会做三分钟先生。包括我,有的时候也有这些看似没多大问题,其实很严重的问题。
       我很困扰,我真的很困扰自己该怎么解决这个问题,难道还请个人来一起学习自己才能学习的上心些么?因为自己在那个时候刚出来,心浮气躁的,根本来说静不下心来说去好好学习。后来由着朋友介绍了一些技术群,和大家一起讨论问题解决问题,我很享受这种感觉,和大家一起学习互相鼓励,后来也懂得一些做人,做事,做学问的方法和道理,就是一个人可能不那么强大,集所有人的力量一定能够解决看似很强大的bug.
        现在我经过了那段热血的但是及其浮躁的年代,现在我想把自己的一些经验告诉大家,而且我也想让大家能够在一起学习,而且是一起互帮互助学习,不管是在工作当中还是在学习,都得明白和大家多交流,一起多学习,而且对于别人的建议和推荐一定要好好考虑!
        我在很多技术论坛都学习过,不过我觉得在很多论坛中学习的资料是很多,但是在某些方面来说的话,并不是很适合每一个人,我觉得在很多时候有想学的但是没有肯教的,所以我想有个能让每一个人都有学的地方就好了,因为在群里聊天的话也只能不太固定的教些东西,而且也不能让所有人参与进来。所以我自己弄了个论坛,www.90cxy.com 90程序员,刚刚起步,不为了名,不为了利,只想有个可以和很多人一起学习的平台,虽然不说很好,但是我想,可以让每个人都不至于空手而归。
      

  12.   

    每次看到性能问题都在反思自己写的代码,08年的时候公司网站确实遇到了极大的性能问题,当时mysql的并发达到400+,任何页面反映都是极慢,跟经理花了一个月的时间去优化,最终解决了。
    之后每次写代码都在担心性能问题,也不断的在研究web性能问题。性能问题最严重的往往是数据库、容器并发、web并发、带宽。至于代码方面的优化,几乎是忽略的。一个一般水平的程序员,和一个满足楼主所说的那些水平的程序员写出的代码,就性能方面而言,差别不大。
      

  13.   

    7. 慎用synchronized,尽量减小synchronize的方法
     
    都知道,实现同步是要很大的系统开销作为代价的,甚至可能造成死锁,所以尽量避免无谓的同步控制。synchronize方法被调用时,直接会把当前对象锁 了,在方法执行完之前其他线程无法调用当前对象的其他方法。所以synchronize的方法尽量小,并且应尽量使用方法同步代替代码块同步这点说的正确,但原理解释有问题。不是 在方法执行完之前其他线程无法调用当前对象的其他方法,而是在方法执行完之前其他线程无法调用当前对象的其他被synchronized的方法
      

  14.   

    《Thinking in Java》中说道:“优化是一个很棘手的问题,最好的策略就是置之不顾,直到你发现需要担心它了”(第四版)P225
      

  15.   

    环境造就人!
    搞服务器开发的,坐拥几十G内存,8核CPU。似乎是不大需要考虑性能。
    像咱这样从J2ME起家的,就不一样啦。不考虑这些,马上就有无数BUG出来陪你玩了。不过现在好了,android,iphone的硬件配置也都提高了。相对来说,对代码的性能要求就少得多了。但是,电子设备层出不穷,java无处不在。谁能保证哪天我们还要碰到一些非常非常瘦的客户端开发呢?比如机顶盒
      

  16.   

    ╮(╯▽╰)╭,只有玩过J2ME的孩子才能理解,优化是件多么悲剧的事情。
      

  17.   

    楼主举得例子是一些“特定”情况下“实际”开发中的一些经验和技巧,刚参加工作的人应该把重心放在完成业务功能上,代码只要不是太糟糕leader一般不会说。
      

  18.   


    支持!明显作者没读过Effective Java,而且很多是YY的结果...