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

亚信联创科技出版的。

1、与log4j有关的性能问题

Logger对象的标准定义方式：

private static transient Logger log=Logger.getLogger(createIndex.class);

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

使用 debug 函数的标准方式：

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

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

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

不要图省事包装一下 ， 提供通用 API， ， 因为你没解决上面提到的形参准备开销问题 ， 比如 ：
/**
* 错误的使用方式
*/
public  static  void debug(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的时候，如果可以最好预估容量。

StringBuilder sb=new StringBuilder();

原因：

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

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

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

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

错误的使用方式：

SimpleDateFormat sdf=new SimpleDateformat("yyyy-MM-dd");
for(...){
  //定义一次使用多次
  sdf.format(new Date());
}

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

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

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

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

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

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

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

不建议：
for(int i=;i<datas.size();i++){
  String distCode=datas.getData(i).getString("Code");
  String distName=datas.getData(i).getString("Name");
  String explain=datas.getData(i).getString("explain");
...
}
建议：
for(int i=,size=datas.size();i<size;i++){
    Data data=datas.getData(i);
  String distCode=data.getString("Code");
  String distName=data.getString("Name");
  String explain=data.getString("explain");
...
}

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

能用ArrayList就尽量不要用Vector

原因：

　　Vector线程安全，慢

能用hashMap就不要用HashTable

原因：

　　hashtable线程安全

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

new ArrayList();

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

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

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

原因：

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

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

将小工具函数标识为final

public static final boolean isBlank(String str){
  if(str==null || "".equals(str.trim())){
     return true;
  }
  return false;
}

原因：

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

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

能使用preparedStatement就不使用statement对象

原因：

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

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

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

10、缓存使用的性能问题

缓存的作用有两个：

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

　　缓存计算

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

11、并发锁带来的问题

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

//正确的计数器写法
private static AutomicInteger count=newAutomicInteger();

public void xxx(){
 //业务处理
 count.getAndIncrement();

}

//不建议的计数器写法：
private static int count=;

public void synchronized xxx(){
  count++;
}

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

12、杂谈

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

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

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

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