亚信联创科技出版的。
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循环，性能差距非常大