5、使用原始类型和栈
　　上面介绍了来自 jOOQ的例子中使用了大量的泛型，导致的结果是使用了 byte、 short、 int 和 long 的包装类。但至少泛型在Java 10或者Valhalla项目中被专门化之前，不应该成为代码的限制。因为可以通过下面的方法来进行替换：
　　//存储在堆上
　　Integer i = 817598;
　　……如果这样写的话：
　　// 存储在栈上
　　int i = 817598;
　　在使用数组时情况可能会变得更加糟糕：
　　//在堆上生成了三个对象
　　Integer[] i = { 1337， 424242 };
　　……如果这样写的话：
　　// 仅在堆上生成了一个对象
　　int[] i = { 1337， 424242 };
　　小结
　　当我们处于 N.O.P.E. 分支的深处时，应该极力避免使用包装类。这样做的坏处是给GC带来了很大的压力。GC将会为清除包装类生成的对象而忙得不可开交。
　　所以一个有效的优化方法是使用基本数据类型、定长数组，并用一系列分割变量来标识对象在数组中所处的位置。
　　遵循LGPL协议的 trove4j 是一个Java集合类库，它为我们提供了优于整形数组 int[] 更好的性能实现。
　　例外
　　下面的情况对这条规则例外：因为 boolean 和 byte 类型不足以让JDK为其提供缓存方法。我们可以这样写：
　　Boolean a1 = true; // ... syntax sugar for:
　　Boolean a2 = Boolean.valueOf(true);
　　Byte b1 = (byte) 123; // ... syntax sugar for:
　　Byte b2 = Byte.valueOf((byte) 123);
　　其它整数基本类型也有类似情况，比如 char、short、int、long。
　　不要在调用构造方法时将这些整型基本类型自动装箱或者调用 TheType.valueOf() 方法。
　　也不要在包装类上调用构造方法，除非你想得到一个不在堆上创建的实例。这样做的好处是为你为同事献上一个巨坑的愚人节笑话。
　　非堆存储
　　当然了，如果你还想体验下堆外函数库的话，尽管这可能参杂着不少战略决策，而并非乐观的本地方案。一篇由Peter Lawrey和 Ben Cotton撰写的关于非堆存储的很有意思文章请点击： OpenJDK与HashMap——让老手安全地掌握（非堆存储！）新技巧。
　　6、避免递归
　　现在，类似Scala这样的函数式编程语言都鼓励使用递归。因为递归通常意味着能分解到单独个体优化的尾递归（tail-recursing）。如果你使用的编程语言能够支持那是再好不过。不过即使如此，也要注意对算法的细微调整将会使尾递归变为普通递归。
　　希望编译器能自动探测到这一点，否则本来我们将为只需使用几个本地变量能搞定的事情而白白浪费大量的堆栈框架（stack frames）。
　　小结
　　这节中没什么好说的，除了在 N.O.P.E 分支尽量使用迭代来代替递归。
　　7、使用entrySet()
　　当我们想遍历一个用键值对形式保存的 Map 时，必须要为下面的代码找到一个很好的理由：
　　for (K key : map.keySet()) {
　　V value : map.get(key);
　　}
　　更不用说下面的写法：
　　for (Entry<K， V> entry : map.entrySet()) {
　　K key = entry.getKey();
　　V value = entry.getValue();
　　}
　　在我们使用 N.O.P.E. 分支应该慎用map。因为很多看似时间复杂度为 O(1) 的访问操作其实是由一系列的操作组成的。而且访问本身也不是免费的。至少，如果不得不使用map的话，那么要用 entrySet() 方法去迭代！这样的话，我们要访问的仅仅是Map.Entry的实例。
　　小结
　　在需要迭代键值对形式的Map时一定要用 entrySet() 方法。
　　8、使用EnumSet或EnumMap
　　在某些情况下，比如在使用配置map时，我们可能会预先知道保存在map中键值。如果这个键值非常小，我们应该考虑使用 EnumSet 或 EnumMap，而并非使用我们常用的 HashSet 或 HashMap。下面的代码给出了很清楚的解释：
　　private transient Object[] vals;
　　public V put(K key， V value) {
　　// ...
　　int index = key.ordinal();
　　vals[index] = maskNull(value);
　　// ...
　　}
　　上段代码的关键实现在于，我们用数组代替了哈希表。尤其是向map中插入新值时，所要做的仅仅是获得一个由编译器为每个枚举类型生成的常量序列号。如果有一个全局的map配置（例如只有一个实例），在增加访问速度的压力下，EnumMap 会获得比 HashMap 更加杰出的表现。原因在于 EnumMap 使用的堆内存比 HashMap 要少 一位（bit），而且 HashMap 要在每个键值上都要调用 hashCode() 方法和 equals() 方法。
　　小结
　　Enum 和 EnumMap 是亲密的小伙伴。在我们用到类似枚举（enum-like）结构的键值时，应该考虑将这些键值用声明为枚举类型，并将之作为 EnumMap 键。
　　9、优化自定义hasCode()方法和equals()方法
　　在不能使用EnumMap的情况下，至少也要优化 hashCode() 和 equals() 方法。一个好的 hashCode() 方法是很有必要的，因为它能防止对高开销 equals() 方法多余的调用。
　　在每个类的继承结构中，需要容易接受的简单对象。让我们看一下jOOQ的 org.jooq.Table 是如何实现的？
　　简单、快速的 hashCode() 实现方法如下：
　　// AbstractTable一个通用Table的基础实现：
　　@Override
　　public int hashCode() {
　　// [#1938] 与标准的QueryParts相比，这是一个更加高效的hashCode()实现
　　return name.hashCode();
　　}
　　name即为表名。我们甚至不需要考虑schema或者其它表属性，因为表名在数据库中通常是的。并且变量 name 是一个字符串，它本身早已经缓存了一个 hashCode() 值。
　　这段代码中注释十分重要，因继承自 AbstractQueryPart 的 AbstractTable 是任意抽象语法树元素的基本实现。普通抽象语法树元素并没有任何属性，所以不能对优化 hashCode() 方法实现抱有任何幻想。覆盖后的 hashCode() 方法如下：
　　// AbstractQueryPart一个通用抽象语法树基础实现：
　　@Override
　　public int hashCode() {
　　// 这是一个可工作的默认实现。
　　// 具体实现的子类应当覆盖此方法以提高性能。
　　return create().renderInlined(this).hashCode();
　　}
　　换句话说，要触发整个SQL渲染工作流程（rendering workflow）来计算一个普通抽象语法树元素的hash代码。
　　equals() 方法则更加有趣：
// AbstractTable通用表的基础实现：
@Override
public boolean equals(Object that) {
if (this == that) {
return true;
}
// [#2144] 在调用高开销的AbstractQueryPart.equals()方法前，
// 可以及早知道对象是否不相等。
if (that instanceof AbstractTable) {
if (StringUtils.equals(name，
(((AbstractTable<?>) that).name))) {
return super.equals(that);
}
return false;
}
return false;
}
　　首先，不要过早使用 equals() 方法（不仅在N.O.P.E.中），如果：
　　this == argument
　　this“不兼容：参数
　　注意：如果我们过早使用 instanceof 来检验兼容类型的话，后面的条件其实包含了argument == null。我在以前的博客中已经对这一点进行了说明，请参考10个精妙的Java编码佳实践。
　　在我们对以上几种情况的比较结束后，应该能得出部分结论。比如jOOQ的 Table.equals() 方法说明是，用来比较两张表是否相同。不论具体实现类型如何，它们必须要有相同的字段名。比如下面两个元素是不可能相同的：
　　com.example.generated.Tables.MY_TABLE
　　DSL.tableByName(“MY_OTHER_TABLE”)
　　如果我们能方便地判断传入参数是否等于实例本身（this），可以在返回结果为 false 的情况下放弃操作。如果返回结果为 true，我们还可以进一步对父类（super）实现进行判断。在比较过的大多数对象都不等的情况下，我们可以尽早结束方法来节省CPU的执行时间。
　　一些对象的相似度比其它对象更高。
　　在jOOQ中，大多数的表实例是由jOOQ的代码生成器生成的，这些实例的 equals() 方法都经过了深度优化。而数十种其它的表类型（衍生表 （derived tables）、表值函数（table-valued functions）、数组表（array tables）、连接表（joined tables）、数据透视表（pivot tables）、公用表表达式（common table expressions）等，则保持 equals() 方法的基本实现。
　　10、考虑使用set而并非单个元素
　　后，还有一种情况可以适用于所有语言而并非仅仅同Java有关。除此以外，我们以前研究的 N.O.P.E. 分支也会对了解从 O(N3) 到 O(n log n)有所帮助。
　　不幸的是，很多程序员的用简单的、本地算法来考虑问题。他们习惯按部班地解决问题。这是命令式（imperative）的“是/或”形式的函数式编程风格。这种编程风格在由纯粹命令式编程向面对象式编程向函数式编程转换时，很容易将“更大的场景（bigger picture）”模型化，但是这些风格都缺少了只有在SQL和R语言中存在的：
　　声明式编程。
　　在SQL中，我们可以在不考虑算法影响下声明要求数据库得到的效果。数据库可以根据数据类型，比如约束（constraints）、键（key）、索引（indexes）等不同来采取佳的算法。
　　在理论上，我们初在SQL和关系演算（relational calculus）后有了基本的想法。在实践中，SQL的供应商们在过去的几十年中已经实现了基于开销的高效优化器CBOs (Cost-Based Optimisers) 。然后到了2010版，我们才终于将SQL的所有潜力全部挖掘出来。
　　但是我们还不需要用set方式来实现SQL。所有的语言和库都支持Sets、collections、bags、lists。使用set的主要好处是能使我们的代码变的简洁明了。比如下面的写法：
　　SomeSet INTERSECT SomeOtherSet
　　而不是
　　// Java 8以前的写法
　　Set result = new HashSet();
　　for (Object candidate : someSet)
　　if (someOtherSet.contains(candidate))
　　result.add(candidate);
　　// 即使采用Java 8也没有很大帮助
　　someSet.stream()
　　.filter(someOtherSet::contains)
　　.collect(Collectors.toSet());
　　有些人可能会对函数式编程和Java 8能帮助我们写出更加简单、简洁的算法持有不同的意见。但这种看法不一定是对的。我们可以把命令式的Java 7循环转换成Java 8的Stream collection，但是我们还是采用了相同的算法。但SQL风格的表达式则是不同的：
　　SomeSet INTERSECT SomeOtherSet
　　上面的代码在不同的引擎上可以有1000种不同的实现。我们所研究的是，在调用 INTERSECT 操作之前，更加智能地将两个set自动的转化为 EnumSet 。甚至我们可以在不需要调用底层的 Stream.parallel() 方法的情况下进行并行 INTERSECT 操作。
　　总结
　　在这篇文章中，我们讨论了关于N.O.P.E.分支的优化。比如深入高复杂性的算法。作为jOOQ的开发者，我们很乐于对SQL的生成进行优化。
　　每条查询都用的StringBuilder来生成。
　　模板引擎实际上处理的是字符而并非正则表达式。
　　选择尽可能的使用数组，尤其是在对监听器进行迭代时。
　　对JDBC的方法敬而远之。
　　等等。
　　jOOQ处在“食物链的底端”，因为它是在离开JVM进入到DBMS时，被我们电脑程序所调用的后一个API。位于食物链的底端意味着任何一条线路在jOOQ中被执行时都需要 N x O x P 的时间，所以我要尽早进行优化。
　　我们的业务逻辑可能没有N.O.P.E.分支那么复杂。但是基础框架有可能十分复杂（本地SQL框架、本地库等）。所以需要按照我们提到的原则，用Java Mission Control 或其它工具进行复查，确认是否有需要优化的地方。