Java

实际上没有什么用，因为绝大多数的List的size()方法的实现都是有缓存的，没必要自己再缓存size。

字符串连接，在稍微高版本的JDK编译的时候，都会替换成StringBuffer操作，除非是在循环的时候做字符串连接，大多数情况编译器会自动优化“+”的连接字符串操作。

对于异常也有误解：
1.高版本异常性能问题也早已解决。

2.多使用非受控异常，RuntimeException。

3.异常当然可以控制业务流程，难道在Java中使用类似于C的返回代码或者是返回类来处理系统允许的业务分支么？

第6条，如果默认的构造函数构造的是嵌套的对象，默认的浅层clone方法得到的就不是想要的对象，这种很容易出错的优化不用也罢，即使真优化了，也不见得能加快系统性能万分之一。

第10条是伪命题，更多的时候，是由业务来确定某个变量到底是局部变量还是全局变量。

还有就是局部变量在代码维护上更有用，而不是用来提高性能，整体性能提高十万分之一都未必有。

很多時候，我們不需要太苛刻要求性能

更重要的是代碼的可讀性、維護性

严重同意楼上，首先是要照顾人，然后才是机器

再有就是，collection的遍历优先考虑迭代子方式，而不是用索引，get(i)方法更容易导致性能问题。
先看迭代子方式，eclipse中可以通过输入for，然后快捷键宏定义，直接生成：

for (Iterator iterator = collection.iterator(); iterator.hasNext();) {
    Type item = (Type) iterator.next();
}

如果是for-each访问，其本质依然是迭代子方式：

Collection<Type> collection = xxx.getCollection();
for (Type item : collection) {
}

如果乱用get(i)方式，代码如下：

for (int i = 0; i < collection.size; i++) {
    Type item = (Type) collection.get(i);
}

如果collection的实现类是LinkedList或者其他链表结构的类，在个数超过1000的时候，get方法的性能会急剧下降，超过10000就差不多要爆发性能问题了。

hehe,我看着很熟悉，原来楼主讲的都是j2me的优化经验。其实j2se里面根本不用拘泥于这些所谓的优化，为了那一点点的性能提高损失代码可读性没有必要。

楼主说的这几点，java在编译的时候，就优化了。
写java本人感觉更重要的是逻辑上的优化