Java编程中“为了性能”尽量要做的26点

最近的机器内存又爆满了，除了新增机器内存外，还应该好好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、尽量避免不必要的创建

　　如

 

1. A a = new A();  
2. if(i==1){list.add(a);}

　　应该改为

 

1. if(i==1){  
2. A a = new A();  
3. list.add(a);}

　　15、尽量在finally块中释放资源

　　程序中使用到的资源应当被释放，以避免资源泄漏。这最好在finally块中去做。不管程序执行的结果如何，finally块总是会执行的，以确保资源的正确关闭。

　　16、尽量使用移位来代替'a/b'的操作

　　"/"是一个代价很高的操作，使用移位的操作将会更快和更有效

　　如

 

1. int num = a / 4;  
2. int num = a / 8;

　　应该改为

 

1. int num = a >> 2;  
2. int num = a >> 3;

　　但注意的是使用移位应添加注释，因为移位操作不直观，比较难理解

17、尽量使用移位来代替'a*b'的操作

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

　　如

 

1. int num = a * 4;  
2. int num = a * 8;

　　应该改为

 

1. int num = a << 2;  
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 操作——尽管在没有预先创建异常的情况下就抛出异常是有点不寻常。真正要花代价的是创建异常。幸运的是，好的编程习惯已教会我们，不应该不管三七二十一就 抛出异常。异常是为异常的情况而设计的，使用时也应该牢记这一原则。

评论

27 楼 jiasanshou 2014-09-26  

有的不太准确，不如看看这个面向GC的编程http://ifeve.com/gc-oriented-java-programming/。

26 楼 youngliu_liu 2014-02-17  

不要否定自己，坚持下去。。。没有一个人能够擅长每一领域

25 楼 ijlkdwg 2013-12-09  

有始有终吧，继续。
#24 用缓存，绝对是个慎重的事情，即使技术好，脑子不清晰，也会很危险。绝对不建议脑子发热的人搞这个。
缓存的失效算法， 【cache algorithms (also frequently called replacement algorithms or replacement policies) 】，一般来说，性价比最高的是LRU。个人还真的没见过使用其它算法的实际案例。FIFO想不出来什么场景。至于“FLU”，没听说过。我特意上网搜索了，也没有，比较权威的是这个吧：http://en.wikipedia.org/wiki/Cache_algorithms
能解释下这个是什么么？？难道又是中国的某些SB对IT行业作出了特殊贡献？
#25 “尽量避免非常大的内存分配”，这个又是他妈的鬼扯，Java程序员是不直接接触内存的【NIO除外，那也不是heap内存】，你不能接触，又怎么避免？
大街上那么多男人，每个人都要接受警告，“不能让楼猪的妈怀孕，流产”，但是大家都不能接触到她，警告有什么意义？
#26“慎用异常”，这个又是个无厘头的话。异常是java的一个非常重要的特性，好处许多不说了。异常该来的时候就用，“慎用”什么？
========================

总结说吧，楼猪的SB帖子，就是一个垃圾培训学校抄来的。全篇，除了System.arrayCopy，其它，都是胡说八道，有些编程观点甚至是极其有害的。

24 楼 kely39 2013-12-08  

23 楼 dopic 2013-12-06  

别在这里误人子弟！

22 楼 dopic 2013-12-06  

看得我想吐！

21 楼 fxl545826 2013-12-06  

@ijlkdwg  顶你，我看到这个都没心情一一回复，还是碰触你的G点比较厉害，不过现在这么2的文章出现在首页真是无语

20 楼 luochen512 2013-12-05  

23、尽量使用System.arraycopy ()代替通过来循环复制数组
我不敢苟同。如果源数组中的某个成员 通过强制转换(assignment conversion) 无法被转换(Convert)成为目标数组的对应类型(type)，就会抛出一个ArrayStoreException，就算是正常的，那其中强制转换后问题也是无法预见的

19 楼 ijlkdwg 2013-12-05  

iteye真的是垃圾到极点了，这样通篇错误的东西，居然还推荐！
借个小朋友的帐户来逐条批驳，以正视听。【以下有些内容，也有个别故意抬杠的部分，就是看不顺眼】
A、 #1 #2，是不是矛盾的？一个说尽量使用单实例，我想问下，单实例是绑定在哪里的？不是用static field的方式绑定到class么？#1赞成的，正是#2反对的。
现在程序员的逻辑智商都这样了么？
B、#3，我只能说，基本道理我同意（jdk也缓存了一些东西），但是结论的话“最好能用基本的数据类型或数组来替代对象”，就是狗屁。
面向对象的好处，如果可以用数组来取代，那真的是天下奇闻了。
代码的清晰干净，比一点点的性能提升重要千万倍，如果你读过任何关于性能和重构，代码质量的书，都会听说过。
C、final对于性能是有那么一点点的提升，不过看你信誓旦旦的说优化50%，哈哈，麻烦拿出实证出来好么？
话说回来，如果全部改成final，就可以提升50%性能，那猪都可以做性能优化了，因为他只要去把函数final就可以了。
楼猪，我看见jdk里面还有很多函数没有加final，如果你这么有把握，我可以推荐你来做jdk，真的不骗你。
D、#5 你确定，在函数里面new的对象，都不会进入heap么？如果是，那看来是jvm spi写错了。
不过，回顾#3，又说要尽量少创建对象。这不又是自己打耳光么？
E、关于#6，请告诉我，如果class有个int field，在这个实例产生的时候，这个field是存放在哪个栈里面的？
【逗你傻子玩的啊】，哈哈。
说正经的，基本类型和包装类型在性能上面有个问题是，因为会自动来回转换，有时候没注意，在大循环里面，的确会产生很多cpu时间。
F、#7， “所以synchronize的方法尽量小，并且应尽量使用方法同步代替代码块同步”，我估计抄错了吧。孩子，抄东西要抄懂，要不还会出笑话。
“synchronize方法被调用时，直接会把当前对 象锁 了，在方法执行完之前其他线程无法调用当前对象的其他方法”，你确定么？哈哈，难道又是jvm spi写错了？
G、#8 “尽量使用StringBuilder和StringBuffer进行字符串连接”，又是个笑话。第一，这样的性能提升其实非常有限，选择更正确的表达方式对于代码质量更重要；第二，既然你说要性能优化了，难道就不知道StringBuffer是同步的么？
H、#9，不是说尽量不要用，而是说根本不能用。原因最主要的是，这个方法，依赖于触发时机“不靠谱”的gc。如果你做轻量级的操作，没有必要，如果是重量级的（比如释放什么资源），更不能在这里面做了，因为不知道什么时候发生，还可能因为jvm崩溃而导致无法执行。
这里面还有句话，“尤其是回收Young代内存时，大都会引起应用程序暂停”，实际上是old generation，或者说full gc时候，old generation回收会引起程序暂停。如果你是对的，那这次就是jvm错了。因为它表现的跟你说的不一样。
I、#10 俩个的区别是，下面的多生成一次对象。很多狗屁公司都拿来这个做java面试题。
javap是个很有用的工具，有兴趣的可以去试试。
J、#11 这里你居然知道同步和不同步的区别了，为什么#8里面就不知道呢？抄东西的确不容易理解吧。
既然要欺负sb，就做绝了，连这个也批你。你知道jvm会做同步优化么？回去慢慢查，知道一点再来。
K、#12，你推荐使用 HashMap(int initialCapacity, float loadFactor)，我推荐使用 HashMap(int initialCapacity)，原因很简单，第二个参数，你知道该怎么设置么？
L、#13，你举的这个例子，实际上更应该用for in来做。
M、#14，这个例子也很奇怪，如果一个对象的产生是在if条件里面的，那它本来就应该在if区块里面，跟你的观点屁关系没有。
N、#15，麻烦告诉我什么是java里面的“资源泄露”，我做了这么多年，还是第一次听说这个新名词。
BTW：finally，也不是“尽量”，是“必须”。
O、#16 #17，这俩个建议，我的评价是，够得上活埋了！
又是无谓的性能优化，把代码搞的古里古怪，不好维护。
BTW：如果这个狗屁的优化真的有意义，我估计jvm在运行的时候会自己做。
P、#18，跳过
Q、#19，还是狗屁，如果你的举例成立，那更容易refactor你的代码，martin flower写了很多傻瓜教程，就是为了你们这些人的。
R、#20，“二维数据占用的内存空间比一维数组多得多，大概10倍以上”。这个论据又是什么呢？麻烦说出来？
S、#21，“split由于支持正则表达式，所以效率比较低”，孩子，不同的正则内容，处理的速度也是不一样的，这个你不知道么？
还缓存split结果，你这做过么？有遇到过什么问题么？
缓存这样的建议，不过脑子。
T、#22，懒得说了，看jdk
public interface RandomAccess {
}

懒得写了。

18 楼 fxl545826 2013-12-05  

这里面写的多少东西够浅的，怎么还有这么多盲从者，编程者应该更多知道这些所谓规则的初衷和原因，否则记住这个对你写程序一点好处都没。

17 楼 zhangjian_asi 2013-12-05  

谢谢你的精心整理非常不错,关于自己的代码有待提高。

16 楼 rubyol 2013-12-05  

谢谢整理！
写了这么多年for(int i=0;i<list.size();i++)，没想到也会有性能问题！

15 楼 风云IT天空 2013-12-04  

谢谢

14 楼 高军威 2013-12-04  

终于 有大牛 踩 了

13 楼 caizi12 2013-12-04  

huangsky 写道

2、尽量避免随意使用静态变量

那静态方法呢，如果我有个循环，要多次调用静态方法

指的是随意，一般系统静太变量也不多吧，大部分是常量。

12 楼 huangsky 2013-12-04  

2、尽量避免随意使用静态变量

那静态方法呢，如果我有个循环，要多次调用静态方法

11 楼 wm5920 2013-12-03  

非常不错

10 楼 lenxeon 2013-12-03  

表示代码性能挖掘还远远没有到这此地步，

9 楼 troyconder 2013-12-03  

有很多 JVM 内部都可以优化掉了

8 楼 hngmduyi 2013-12-03