Tips about writing micro benchmarks from the creators of Java HotSpot :
(有关从Java HotSpot的创建者编写微基准测试的提示：)
Rule 0: Read a reputable paper on JVMs and micro-benchmarking.
(规则0：阅读有关JVM和微基准测试的著名论文。)
A good one is Brian Goetz, 2005 . (很好的人是布莱恩·格茨 （ Brian Goetz），2005年 。)
Do not expect too much from micro-benchmarks; (不要对微观基准期望太高；)
they measure only a limited range of JVM performance characteristics. (它们仅测量有限范围的JVM性能特征。)
Rule 1: Always include a warmup phase which runs your test kernel all the way through, enough to trigger all initializations and compilations before timing phase(s).
(规则1：始终包括一个预热阶段，该阶段一直运行您的测试内核，足以在计时阶段之前触发所有初始化和编译。)
(Fewer iterations is OK on the warmup phase. The rule of thumb is several tens of thousands of inner loop iterations.) (（在预热阶段可以进行较少的迭代。经验法则是数以万计的内循环迭代。）)
Rule 2: Always run with -XX:+PrintCompilation , -verbose:gc , etc., so you can verify that the compiler and other parts of the JVM are not doing unexpected work during your timing phase.
(规则2：始终与-XX:+PrintCompilation ， -verbose:gc等一起运行，因此您可以验证在计时阶段，编译器和JVM的其他部分没有进行意外的工作。)
Rule 2.1: Print messages at the beginning and end of timing and warmup phases, so you can verify that there is no output from Rule 2 during the timing phase.
(规则2.1：在计时和预热阶段的开始和结束时打印消息，因此您可以验证在计时阶段没有规则2的输出。)
Rule 3: Be aware of the difference between -client and -server , and OSR and regular compilations.
(规则3：注意-client和-server以及OSR和常规编译之间的区别。)
The -XX:+PrintCompilation flag reports OSR compilations with an at-sign to denote the non-initial entry point, for example: Trouble$1::run @ 2 (41 bytes) . (-XX:+PrintCompilation标志报告OSR编译，并带有一个at符号表示非初始入口点，例如： Trouble$1::run @ 2 (41 bytes) 。)
Prefer server to client, and regular to OSR, if you are after best performance. (如果您追求最佳性能，则优先选择服务器而不是客户端，并经常选择OSR。)
Rule 4: Be aware of initialization effects.
(规则4：注意初始化效果。)
Do not print for the first time during your timing phase, since printing loads and initializes classes. (在计时阶段不要第一次打印，因为打印会加载并初始化类。)
Do not load new classes outside of the warmup phase (or final reporting phase), unless you are testing class loading specifically (and in that case load only the test classes). (不要在预热阶段（或最终报告阶段）之外加载新的类，除非您正在专门测试类的加载（在这种情况下，仅加载测试类）。)
Rule 2 is your first line of defense against such effects. (规则2是抵御此类影响的第一道防线。)
Rule 5: Be aware of deoptimization and recompilation effects.
(规则5：注意优化和重新编译的影响。)
Do not take any code path for the first time in the timing phase, because the compiler may junk and recompile the code, based on an earlier optimistic assumption that the path was not going to be used at all. (在时序阶段不要第一次采用任何代码路径，因为基于较早的乐观假设，即根本不会使用该路径，编译器可能会垃圾并重新编译代码。)
Rule 2 is your first line of defense against such effects. (规则2是抵御此类影响的第一道防线。)
Rule 6: Use appropriate tools to read the compiler's mind, and expect to be surprised by the code it produces.
(规则6：使用适当的工具来阅读编译器的思想，并期望对其生成的代码感到惊讶。)
Inspect the code yourself before forming theories about what makes something faster or slower. (在形成有关使事物变快或变慢的理论之前，请自己检查代码。)
Rule 7: Reduce noise in your measurements.
(规则7：减少测量中的噪音。)
Run your benchmark on a quiet machine, and run it several times, discarding outliers. (在安静的计算机上运行基准测试，然后运行几次，丢弃异常值。)
Use -Xbatch to serialize the compiler with the application, and consider setting -XX:CICompilerCount=1 to prevent the compiler from running in parallel with itself. (使用-Xbatch可以将编译器与应用程序序列化，并考虑设置-XX:CICompilerCount=1可以防止编译器与其自身并行运行。)
Try your best to reduce GC overhead, set Xmx (large enough) equals Xms and use UseEpsilonGC if it is available. (尽最大努力减少GC开销，将Xmx （足够大）设置为Xms并使用UseEpsilonGC如果可用）。)
Rule 8: Use a library for your benchmark as it is probably more efficient and was already debugged for this sole purpose.
(规则8：将库用于您的基准测试，因为它可能更有效，并且已经针对此目的进行了调试。)
Such as JMH , Caliper or Bill and Paul's Excellent UCSD Benchmarks for Java . (例如JMH ， Caliper或Bill和Paul的Java优秀UCSD基准 。)
