当前使用量最大的 Java 版本是 8，所以测试者用 Java 8 与 Java 11 进行对比测试。
GC 是影响 Java 性能的关键因素，所以测试自然也基于 GC，在 G1 GC 和并行 GC 下分别进行了测试，结果如下：
Java 8 vs. Java 11
使用 G1 GC
G1 GC 下每秒分值：
Java 11 在几乎所有测试数据集上都有速度上的提升。
平均而言，仅通过切换到 Java 11 就有 16％ 的改进，这种改进可能是因为 Java 10 中引入了 JEP 307: Parallel Full GC for G1。
使用并行 GC
并行 GC 下每秒分值：
使用并行 GC，结果不如 G1，某些数据集上有所改进，但其它数据集保持不变甚至出现性能下降。平均而言，Java 11 的性能提升了 4％ 以上。
测试者还在 Java 11 上对并行 GC 与 G1 GC 进行对比：
Java 11 上并行 GC vs. G1 GC
结果表明 G1 GC 整体上不如并行 GC。
OptaPlanner 表示，从 Java 8 到 Java 11，G1 GC 的平均速度改进为 16.1％，并行 GC 为 4.5％。
此外虽然并行 GC 面向吞吐量，而 G1 则侧重于低延迟 GC，但是 Java 11 中带来的 G1 显著改进，使得将两者进行直接比较是有意义的。
此外，基于基准测试中的大多数数据集来看，并行 GC 还是更适合 OptaPlanner 的，因为吞吐量对于解决 OptaPlanner 的优化问题更为重要。
拓展
关于OptaPlanner介绍
<code>它本来是一个名叫Geoffrey De Smet的大牛自己写的，
后来他就把它贡献给了JBoss基金会(这里省去了N年的曲折离奇, N >= 10)，
并成为KIE项目组中OptaPlanner项目的负责人。所以OptaPlanner是基于Apache2.0开源协议的，
对商业友好，就是说你想用就尽管用，有问题还可以在他们的讨论组上求助。
/<code>
<code>作用
OptaPlanner用官方的描述就是可以帮你规划出一个用更少的资源做更多更好事情的规划引擎。
如下图列出它可以做的工作领域（这仅仅是OptaPalnner的Example里有的示例，
其实所有关于规则的问题，属于NPC的问题，只要你能把它抽象并建模成OptaPlanner可识别的模型，
你就可以用OptaPlanner来解决）：车辆调度、工作排程、设备排程，Bin Packing(就是用袋子装
石头那个问题啦)及员工排班。/<code>
构架和应用兼容性
<code>原理
那么OptaPlanner是通过什么方法，高效地帮我们在尽量短的时间内，
找到更佳的方案呢？还记得上一任篇老农提到，我们做排程的时候，通常有两种约束条件，
分别是不可违反的硬约束，如果一个计划违反了硬约束，那这个计划就是不可行的，
例如：生产计划中，把产品固定工序的加工次序调乱了，又或者把产品分配到错误的机台上生产
(这些约束条件都是业务上你们自己定义的)，那么OptaPlanner就把它定义为违反了硬约束。
另一类就是软约束，就是那种可以违反，但违反得越多，就会影响越大（影响包括成本、效率、质量等），
所得结果方案的质量越差；违反这种约束，OptaPlanner就把它定义为违反了软约束。
OptaPlanner就是对这两类约束进行打分，硬约束对应的是硬分数，软约束对应的是软分数。
那么得分越高，就表示对应方案的质量越高。在计算这些约束分数的过程中，OptaPlanner会保持优先
优化硬分数、然后在硬分数最优的基础上，再去优化软分数的原则，来寻找最佳方案。
例如：两个方案A、B对比，方案A的硬分数比方案B的硬分数高1分，方案B的软分数比方案A的软高出
10万分。那么OptaPlanner最后还是认为方案A更佳。也就相当于我们写SQL脚本时，
order by子句中前后两个字段的关系了，靠前的字段排序比靠后的字段更优先。
/<code>
这里有篇文章讲：https://www.oschina.net/news/75942/a-decade-of-optaplanner
閱讀更多 達升笑聊IT 的文章
