错误的写法：
for(int i=0, n = list.size(); i< n; i++){ CaBill caBill = new CaBill(); caBill.setBillFee(list.get(i)); Date stsDate = DateUtils.getCurrentDate(); caBill.setStsDate(stsDate); list.add(caBill); } 推荐的写法： Date stsDate = DateUtils.getCurrentDate(); for (int i = 0, n = list.size(); i < n; i++) { CaBill caBill = new CaBill(); caBill.setBillFee(list.get(i)); caBill.setStsDate(stsDate); list.add(caBill); }
7) list删除元素，使用迭代器遍历；
for循环优于while循环，迭代器变量作用范围更小。 推荐的写法：
List
Map
26
// JDK 1.5 for (Map.Entry
如果使用的话，一定要注意线程变量的回收，以免由于线程池的使用而造成一个线程跑多笔业务，线程变量重复使用，导致潜在的风险。 错误示例：
public class TestService{ public static ThreadLocal
10) 与log4j有关的性能问题 - Logger对象定义的标准方式： private static transient Logger log = Logger.getLogger(CreateIndex.class);
static: 防止每次构造业务对象时都连带构造一个Logger 对象，Logger 的创建成本较高，
设置成static 后，在后续创建业务对象时能节省几十毫秒开销。 transient: 防止Logger 对象被序列化，占用序列化开销。 11) 与字符串有关的性能问题
- 尽量不要使用java.lang.String中提供的split，replace，replaceAll等方法 原因：
JDK当中是用正则表达式来做匹配的，在频繁使用的场景下，对性能影响很大。
27
替代方案：
使用org.apache.commons.lang.StringUtils中提供的split,replaceChars，性能是JDK实现的3-4倍。
- 用StringBuilder替代StringBuffer
原因：StringBuilder提供的函数是不加锁的，而StringBuffer是加锁的。业务侧代码，绝大部分场景下都无需加锁。
- 在大量字符串拼接时用StringBuilder，避免使用“...” + “...” + “...” - 虽然用了StringBuilder，但没发挥StringBuilder的优点。 错误的使用方式：
StringBuilder sb = new StringBuilder(); sb.append(“111” + “222” + “333”); // 还是在做字符串+ 操作！ sb.append(“444” + “555” + “666”); 正确的使用方式：
StringBuilder sb = new StringBuilder(); sb.append(“111”); sb.append(“222”); sb.append(“333”); sb.append(“444”); sb.append(“555”); sb.append(“666”); - 在构造StringBuilder时，要能预估容量就更好。 比如：
StringBuilder sb = new StringBuilder(20); sb.append(“111”); sb.append(“222”); sb.append(“333”); sb.append(“444”); sb.append(“555”); sb.append(“666”); 原因：防止StringBuilder因预先分配的容量不够而做二次扩充。 12) 与for循环有关的性能问题 - 避免条件判断时调用函数 错误的方式：
for (int i = 0; i < datas.size(); i++) 正确的方式：
28
for (int i = 0, size = datas.size(); i < size; i++) - try...catch要放在循环外面 错误的方式：
for (...) { try { ... } catch (Exception e) { ... } } 正确的方式：
try { for (...) { ... } } catch (Exception e) { ... } - 避免在循环中反复调用同一个结果集的同一个对象 错误的方式：
for (int i = 0; i < datas.size(); i++) { String discntCode = datas.getData(i).getString(“DISCNT_CODE”); String discntName = datas.getData(i).getString(“DISCNT_NAME”); String discntExplain = datas.getData(i).getString(“DISCNT_EXPLAIN”); ... } 正确的方式：
for (int i = 0, size = datas.size(); i < size; i++) { IData data = datas.getData(i); String discntCode = data.getString(“DISCNT_CODE”); String discntName = data.getString(“DISCNT_NAME”); String discntExplain = data.getString(“DISCNT_EXPLAIN”); ... } 13) 与集合类有关的性能问题
- 能用ArrayList就不要用Vector 原因：能不加锁就不加锁。
- 能用HashMap就不要用Hashtable
29
原因：能不加锁就不加锁。
- 能用HashMap就不要用ConcurrentHashMap 原因：能不加锁就不加锁。
- 用ConcurrentHashMap替代Collections.synchronizedMap(new HashMap());
原因：控制锁的粒度尽可能小，前者是多个细粒度的局部锁，后者是一把全局锁。 - 在使用容器时能预设容量，尽量预设 比如：
new ArrayList(30); // 注意，够用就好，不要设置得过大！ new HashMap(30); // 注意，够用就好，不要设置得过大！
原因：防止基于数组实现的ArrayList二次扩充和HashMap的重hash。 14) 与开关有关的性能问题
- 不论是框架开关，还是业务开关，到java端后最好保存为boolean型。 错误的方式：
if (“true”.equals(validate)) { ... } 正确的方式：
if (validate) { ... } 前者开销是后者的几十倍,字符串越长，开销越大。 15) 与工具方法有关的性能问题 - 将小工具函数标识为final 示例：
public static final boolean isBlank (String str) { if (null == str || “”.equals(str.trim())) { return true; } return false; } 原因：JDK在运行一定次数后，JIT有可能将此final类型的函数内联。 16) 与SQL动态绑定有关的性能问题
30