转载 原文地址: http://edu.codepub.com/2011/0413/30763.php 向原作者致敬!
java的优化建议
1、rule No1:不要优化代码!
注:必须编写足够可读的代码;
2、rule No2:选定优化目标
注:一般只有20%左右的代码是瓶颈所在
3、通用优化技术
A、操作符简约
注:如把"/=2^n"简化为">>=n";
B、公共表达式提取
注:
double x=d*a*b;
double y=e*a*b;
可以修改为:
c=a*b;
x=d*c;
y=e*c; // 后2句在cpu层次可以并行计算
C、预先计算不变的值
如:
for(int i=0;i<N;i++)
x[i] = Math.PI*Math.cos(y)*i;
可以修改为:
double d = Math.PI*Math.cos(y);
for(int i=0;i<N;i++)
x[i] = d*i;
D、部分展开循环
如:
for(int i=0;i<N;i++)
x[i]=i;
可以修改为:
for(int i=0;i<N;i+=3)
{
x[i]=i;
x[i+1]=i+1;
x[i+2]=i+2;
}
E、try结束循环技术
如:
for(int i=0;i<a.length;i++)
a[i]=i*i;
修改为:
try{
for(int i=0;;i++)
a[i]=i*i;
}catch(Exception nouse)
{
}
注意:这种技术节约了一次判断,只有在循环次数时很大(过千万)时才有效;
4、对基本数据结构的说明
A、数组拷贝,用System.arraycopy
B、Arrays.sort方法在sort对象数组的时候,采用的是稳定的归并排序
C、Arrays.sort方法在sort内嵌类型数组的时候,采用的不是introsort,不要希望它有stl::sort的速度
D、Collections.sort方法会先把List拷贝成Array,然后调用Arrays.sort,速度很慢
E、ArrayList的自增长比例是1.5,即每次不够了自动增长50%(+1)
F、BitSet内部使用long数组来实现,在32位机器上面的速度不高
G、HashMap的默认填充率是0.75
H、PriorityQueue虽然是最小堆的数值实现,但其速度很慢,量大的时候,不如TreeMap
I、Vector和ArrayList都不能用作需要删除操作的数组,如果需要,建议自己实现,可以采用延迟删除策略
J、Map和HashMap都和c++的stl::map和stl::hashtable实现算法一样
K、StringBuilder和StringBuffer的不同点在于后者可以多线程调用(自然速度就更慢)
L、注意String著名的内存泄露问题!对于原始字符串很长时一定注意不要随便调用substring方法,应该直接拷贝
5、对正则表达式的说明
A、千万注意String.split方法,它的效率特别低,每次都需要编译表达式!
B、不要使用:
X+
修改为:
X{1,1024}
原因在于前者在输入为1000个X的时候,会导致堆栈(即函数调用)有1000多层,内存不足;
6、选用最新的jvm和采用-server选项
注:只有采用-server选项后,jvm才会预先编译(否则就看hotspot的心情了)
误区:
1、方法必须加final,并且不能使用任何非final的局部变量,才能被inline
注:所有的方法都能被inline(虽然Jvm可能选择不inline)
2、类必须加上final,才能够让方法可能被inline
注:hotspot的好处就在于它有deoptimize的能力,在检测到方法不应该被inline时,它能够自我更正,重新inline
注:当然了,如果可以加上final,避免hotspot额外工作。