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(20);
原因:
防止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=0;i<arr.length;i++){ ... } 应该写成这样最好: for(int i=0,len=arr.length;i<len;i++){ ... }
try...catch要放在循环外面。
避免在循环中反复调用同一个结果集的同一个对象:
不建议: for(int i=0;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=0,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(30);
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=0; public void synchronized xxx(){ count++; }
在读多写少的情景下,用读写锁,不要用排他锁,比如synchronized
12、杂谈
避免频繁使用instanceof做类型判断,建议拆成多个对象,用多态调用。
能不用正则表达式就不用正则表达式,正则表达式只是更灵活,但特定场景下性能不一定最优
避免重复对象的反复构造,能复用就复用
两数组对拷,注意使用System.arraycopy不要自己写for循环,性能差距非常大