几个月前，我正在阅读Java中的复杂事件处理以及实现低延迟的方法。 在我长达一个小时的研究结束时，我发现即使您的应用程序编写正确并且您的方法主要在0（log n）的时间内运行，并且您正在使用某些前沿的硬件解决方案，但仍会花费一些时间。 VM在解释字节码期间。

从好的方面来说，Java被解释了，它的字节码是跨JVM兼容的，但是我们也知道，因此，我们注定会在某些地方丢失某些东西。 我们的JVM读取解释的字节码并每次运行。 显然，这需要时间。

但是考虑到我们友好的邻居JIT编译器（服务器或客户端）会注意常用的方法，并且发现方法被调用了太多次时 ，它会将其编译为本机代码，而不是依赖JVM，因此它的性能还不错。一直在字节码上。

使用vm参数配置“太多次”的数字

<-XX:CompileThreshold

默认值为1500 。 一个自然的猜测是减少数量将意味着更多的方法更快地转换为本地代码，这意味着更快的应用程序，但事实并非如此。 相当低的数字将意味着服务器由于JIT编译太多方法（毕竟可能很少经常使用）而花费的时间非常慢，并且由于本机代码驻留在内存中，因此您的应用程序将荣获“记忆杀手”奖，并以缓慢的痛苦死亡。 稍作谷歌搜索就可以发现100左右的数字还不错。 同样，这取决于您的应用程序以及使用模式和流量。

忘了提及，成为JIT本机编译候选对象的最小编译单元是一种方法。 不是一个障碍。 因此，长期使用脂肪的方法–祝您好运！

实际上，这种JIT编译并非一go而就。 它有两个整洁的阶段：

1）每次调用方法时，其计数器都会增加1，并在达到阈值后不久，JIT会进行第一次编译 。

2）第一次编译后，计数器将重置为0，然后再次递增。 在第二个周期中，当JIT达到阈值时，它将进行第二轮编译 –这次具有更激进和令人敬畏的优化（对不起–无法在此处提供很多详细信息）

如果您使用的是JDK 7，并且您的计算机在多核上运行（我不知道为什么不这样做），则可以使用以下标志来加快本机编译过程

-server -XX:+TieredCompilation

考虑到可用选项的数量，我不能声称自己是JVM调优的专家。 因此，如果您觉得有用或不正确，请留下您的评论。

别忘了分享！

参考：通过我们的JCG合作伙伴 Arun Manivannan的Rerun.me博客为您的JVM热身-超快速生产服务器和IDE 。