为什么一个40亿次迭代的Java循环只需要2 ms?

我在2.7 GHz Intel Core i7笔记本电脑上运行以下Java代码。我打算让它测量用2 ^ 32次迭代完成一个循环需要多长时间，我预计这个循环大约是1.48秒（4 / 2.7 = 1.48）。

但实际上它只需要2毫秒，而不是1.48秒。我想知道这是否是下面的任何JVM优化的结果？

java代码

大致的解释为：1.编译器对代码进行了优化

2.JIT（即时编译器）对代码进行了优化

编译期优化（编译器代码优化）

虚拟机设计把对性能的优化集中到即时编译器（JIT）中，让那些非avac编译器产生的class文件也能得到编译器优化的好处。但是javac做了许多针对编码过程的优化措施来改善程序员的编码风格和提高编码效率。许多新生的java语法特性，都是靠编译器的“语法糖”来实现，而不是依赖虚拟机的底层改进来支持。

所以说，java中即时编译器在运行期间的优化过程对于程序的运行来说更重要，而前端编译器在编译期的优化过程对于程序编码来说关系更加密切。

javac编译过程

运行期优化（JIT代码优化）

在一些商用虚拟机中，java程序最初是通过解释器进行解释执行的，当虚拟机发现某个方法或代码块运行特别频繁，就会把这些代码认定为“热点代码”，为了提高热点代码的执行效率，在运行时，虚拟机就会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器或JIT编译器。

众多主流的虚拟机都同时包含解释器和JIT编译器，解释器与JIT编译器各有优势：当程序需要迅速启动和执行时，解释器可以首先发挥作用，省去编译的时间，立即执行。当程序运行后，随着事件的推移，JIT编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。

会被即时编译器编译的热点代码有两类：

1.被多次调用的方法体；

2.被多次调用的循环体。

判断一段代码是否是热点代码的方式（热点探测）有两种：

1.基于采样的热点探测：

此方法会周期性检查各个线程的栈顶，如果发现某个或某些方法经常出现在栈顶，那么这个方法就是热点方法。此方法的缺点是很难精确地确认一个方法的热度，容易受到诸如线程阻塞等因素影响。

2.基于计数器的热点探测：

此方法会为每个方法甚至是代码块建立计数器，统计方法的执行次数，如果执行次数超过一个阀值就认为它是热点方法。

注：默认设置下，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成。当编译工作完成之后，这个方法的调用入口地址就会被系统自动改写成新的地址，下一次调用该方法时就会使用已编译的版本。也就是说，在编译器还未完成之前，执行引擎仍按照解释方式继续执行，而编译动作则在后台的编译线程中进行。