j2ee项目Java代码性能优化要点（抄书）

亚信联创科技出版的。

1、与log4j有关的性能问题

Logger对象的标准定义方式：

privatestatictransientLoggerlog=Logger.getLogger(createIndex.class);

static:创建一次logger对象，节省开销
transient：避免被序列化，减少序列化开销

使用debug函数的标准方式：

if(log.isDebugEnable()){//一定要记得先判gdebug开关
　　Log.debug(“GDEBUG调试信息”);
}

原因：
没错，确实可通过配置slog4j.properties来控制某类路径下的gdebug开关是否开启，，
但不要忽略在调gdebug函数前，准备形参的开销。

例如：
Datasetdatas=ServiceFactory.call(“QCS_QueryUserInfo”,...);
Log.debug(“输入参数：”+datas);///这里会调datas的toString，相当消耗时间

不要图省事包装一下，提供通用API，，因为你没解决上面提到的形参准备开销问题，比如：
/**
*错误的使用方式
*/
publicstaticvoiddebug(String)xxx){
if(log.isDebugEnable()){
　　　　log.log(xxx);
　　}
}

使用debug部分不是很懂！

2、与字符串有关的性能问题

1）尽量不要使用java.lang.String中提供的split、replace、replaceAll等方法。

原因：

　　JDK中是用正则表达式做匹配的，在频繁使用的场景下，对性能影响很大。

建议使用org.apache.commons.lang.StringUtils中提供的split、replaceChars，是JDK性能的3~4倍。

2）尽量用StringBuilder替代StringBuffer

原因：

　　StringBuffer是线程安全，速度比较慢

StringBuilder的append()方法尽量多次append而不是sb.append("a"+"b");

原因：

　　这样又变成字符串的拼接了

在构建StringBuilder的时候，如果可以最好预估容量。

StringBuildersb=newStringBuilder(20);

原因：

　　防止StringBuilder因为预先分配的容量不够而做第二次扩充。

3、与时间有关的性能问题

避免重复构建SimpleDateFormat对象，SimpleDateFormat对象创建的开销很大。

避免复用SimpleDateFormat对象，因为SimpleDateFormat对象是不可重用的，和C中的不可复用函数一个意思。

错误的使用方式：

SimpleDateFormatsdf=newSimpleDateformat("yyyy-MM-dd");
for(...){
//定义一次使用多次
sdf.format(newDate());
}

建议使用apache提供的：org.apache.commons.lang.time.DateFormatUtils.

这个SimpleDateformat是不可重用的吗？我不清楚啊，没百度到结果。不管。

4、与for循环有关的性能问题

避免条件判断时调用函数：

错误的方式：
for(inti=0;i<arr.length;i++){
...
}
应该写成这样最好：
for(inti=0,len=arr.length;i<len;i++){
...
}

try...catch要放在循环外面。

避免在循环中反复调用同一个结果集的同一个对象：

不建议：
for(inti=0;i<datas.size();i++){
StringdistCode=datas.getData(i).getString("Code");
StringdistName=datas.getData(i).getString("Name");
Stringexplain=datas.getData(i).getString("explain");
...
}
建议：
for(inti=0,size=datas.size();i<size;i++){
Datadata=datas.getData(i);
StringdistCode=data.getString("Code");
StringdistName=data.getString("Name");
Stringexplain=data.getString("explain");
...
}

5、与集合有关的性能问题

能用ArrayList就尽量不要用Vector

原因：

　　Vector线程安全，慢

能用hashMap就不要用HashTable

原因：

　　hashtable线程安全

在使用容器时尽量预设容量，防止扩充的消耗。

newArrayList(30);

6、与开关有关的性能问题

无论框架开关还是业务开关，到Java后端最好保存为boolean类型。

不建议的方式：
if("true".equals(validate)){
...
}
建议的方式：
if(validate){
...
}

原因：

　　前者的开销是后者的几十倍，字符串越长，开销越大

7、与工具方法有关的性能问题

将小工具函数标识为final

publicstaticfinalbooleanisBlank(Stringstr){
if(str==null||"".equals(str.trim())){
returntrue;
}
returnfalse;
}

原因：

　　JDK在运行一定次数后JIT可能将此final类型的函数关联

8、与sql动态绑定有关的性能问题。

能使用preparedStatement就不使用statement对象

原因：

两者的差别就在于编译型语言和脚本语言的差别。

9、与反射调用有关的性能问题

尽量缓存method对象，method对象是反射最消耗性能的地方。

10、缓存使用的性能问题

缓存的作用有两个：

　　将你需要的数据搬到离你更近的地方

　　缓存计算

避免从缓存获取数据后再对数据进行排序过滤等操作，正确的做法是先将数据排序过滤好，再放入缓存。

11、并发锁带来的问题

最好是不用锁，比如cas机制解决并发问题

//正确的计数器写法
privatestaticAutomicIntegercount=newAutomicInteger();

publicvoidxxx(){
//业务处理
count.getAndIncrement();

}

//不建议的计数器写法：
privatestaticintcount=0;

publicvoidsynchronizedxxx(){
count++;
}

在读多写少的情景下，用读写锁，不要用排他锁，比如synchronized

12、杂谈

避免频繁使用instanceof做类型判断，建议拆成多个对象，用多态调用。

能不用正则表达式就不用正则表达式，正则表达式只是更灵活，但特定场景下性能不一定最优

避免重复对象的反复构造，能复用就复用

两数组对拷，注意使用System.arraycopy不要自己写for循环，性能差距非常大