正文
你现在会有第二个 StringBuilder，这个 StringBuilder 本来没有存在的必要，它会消耗堆内存，给 GC 增加负担。你应该这样写：
关键点
在上面的例子中，显式地使用 StringBuilder 实例，和 Java 编译器隐式使用 StringBuilder 实例是没有关联的。但是记住，我们在 N.O.P.E 分支。我们在每个 CPU 周期对 GC 和为 StringBuilder 分配空间所产生的浪费，都会浪费 N x O x P 倍。
总是使用
StringBuilder
，不用 + 运算符是一个不错的规则。如果你的字符串构建起来很复杂，尽可能在多个方法间使用同一个 StringBuilder。这就是你在生成复杂的 SQL 时
jOOQ
所做的事情。只有一个 StringBuilder 在整个 SQL
AST (Abstract Syntax Tree)
中“游走”。
如果你还有
StringBuffer
引用，大声哭吧，把它们换成 StringBuilder，因为你很少需要同步创建一个字符串。[译者注：StringBuffer 与 StringBuilder 的区别就在于 StringBuilder 不是线程安全的，但在同步代码中没必要使用 StringBuffer，它会带来额外的性能开销。]
正则表达式相对便宜和方便。但是如果你在 N.O.P.E 分支，那很糟糕了。如果你必须在计算机密集的代码段中使用正则表达式，至少把
Pattern
的引用缓存下来，避免每次都对其重新编译：
但是如果你的正则表达式真的很简单，就像
… 然后你真的最好诉诸普通的 char[] 或基于索引的操作。例如下面很信读的一段代码做了同样的事情：
… 这也说明了为什么你不应该过早进行优化。与 split() 的版本相比，这简直不可维护。
挑战：请读者们找到更快的方法。
分析
正则表达式很有用，但需要代价。如果你在 N.O.P.E 分支，就必须避免正则表达式的代价。小心使用各种 JDK String 那些使用正则表达式的方法，比如
String.replaceAll()
、
String.split()
等。
请使用像
Apache Commons Lang
这样的知名类库来操作字符串。
这个建议不太适用于常规用例，只适用于 N.O.P.E. 分支，但你也可以用用看。编写 Java-5 风格的 foreach 循环很方便。 你可以完全忽略循环内部变量，并编写：
然而，每当你运行到循环内部时，如果 string 是一个
Iterable
，你就要创建一个新的
Iterator
实例。如果你正在使用
ArrayList
，这将会在堆上分配一个含 3 个 int 的对象：
相反，你可以编写以下代码——等价循环体，并且在栈上仅“浪费”一个 int 值，开销低：
… 或者，你可以选择不改变链表，在数组版本上使用同样的操作：
关键点
从可写性和可读性以及从 API 设计的角度来看，Iterators、Iterable 和 foreach 循环都是非常有用的。但它们在堆上为每次单独的迭代创建一个小的新实例。 如果你运行这个迭代许多次，又想避免创建这个无用的实例，可以使用基于索引的迭代。
讨论
关于上面观点相反的有趣意见（特别是使用索引访问替代迭代器）
已在 Reddit 上讨论研究。
一些方法简单但开销不小。在N.O.P.E.分支示例中，我们没有在叶节点上使用这样的方法，但你可能使用到了。我们假设 JDBC 驱动程序需要耗费大量资源来计算
ResultSet.wasNull()
的值。你可能会用下列代码开发 SQL 框架：
此处逻辑每次都会在你从结果集中获得一个 int 之后立即调用 ResultSet.wasNull()。但getInt() 的约定是：
返回: 列的数目；如果这个值是 SQL NULL，这个值将返回 0。
因此，对上述问题的简单但可能有效的改进将是：
