Java性能微基准测试（JMH）
引言
JMH是OpenJDK的JIT团队开发的微基准测试框架，可针对基准方法在吞吐量、响应时间等维度进行纳秒/微秒/毫秒/秒级的性能基准测试。随着虚拟机的逐步优化，过去的一些常见说辞已经不再那么绝对，比如：final 修饰的变量性能更好，对象使用后赋null可以加快GC回收等。因此性能的好坏需要量化比较，JMH正是解决这方面的好工具。
JMH典型应用场景
1、直观比较两个函数的性能高低
2、统计单位时间接口的吞吐量
3、统计规定周期内函数的平均执行时间，计算函数执行时间与输入规模的关联性等
JMH执行方式：
1、通过Maven搭建微基准测试项目，打包项目为.jar的形式执行。（官方推荐做法，测试结果更准确、可靠）
2、在Eclipse环境项目中引入JMH依赖的插件及jar包，以Main方式执行步骤如下。
a、设置依赖
maven-shade-plugin
jmh-depend-jars
b、安装插件，启用maven项目对注解的支持
m2e-apt
样例1：对比各种字符串拼接方式，每秒的吞吐量
代码实现，详见https://github.com/SolodanceMagicq/algorithm_practice/blob/master/src/algo/java/jmh/StringOpt.java
小结：
由基准测试结果可见，性能由高到低为 ：+拼接常量字符串 >StringBuilder>StringBuffer>同步修饰StringBuilder>+拼接变量字符串。
JIT团队对常量拼接进行了优化，+拼接常量字符串的性能最高；其次是StringBuilder，由于构建的字符串对象少，且无同步锁，性能次之；StringBuffer比StringBuilder稍差一些，由两者的原码可见，主要差在锁同步操作上了；+拼接变量字符串，会创建大量StringBuilder中间对象，性能最差；而锁同步的StringBuilder性能比StringBuilder性能差距较大，可见我们当前一个线程情况下，不涉及到并发访问，JVM并没有将不必要的锁同步优化掉。即便相同的代码用不用锁，性能影响也很大。（PS ：之前网上总说，非多线程场景下，JVM会进行锁优化，去掉不必要的同步操作，使之与不使用synchronized关键字一样，至少这个基准测试结果并没反馈。或许我的这个用例没达到JVM优化条件吧？）
样例2：对数组、ArrayList和LinkedList集合的各种迭代方式进行吞吐量对比测试
Collectors
小结：从测试结果反馈，Array和基于数组的集合采用下标迭代的性能最高。链表迭代的性能普遍不高。（引申 ：使用Iterator进行迭代过程中可以对元素进行添加、删除操作，而增强for循环则不可以，会发生fast-fail，阿里规约中规定禁止在增强for循环过程中进行对集合做元素个数变更操作。）
参考：
http://openjdk.java.net/projects/code-tools/jmh/
http://tutorials.jenkov.com/java-performance/jmh.html#writing-good-benchmarks
