Java jits方法在循环中调用，性能在以后的几次运行中大幅提高

我在看HDFS时注意到它花费了大量的时间来验证校验和，几次之后，它的速度急剧加快。 我正在读取一个1MB文件，它执行crc32c校验和17次，因为该文件被分解为64KB的数据包。 下面是一个时间示例，以秒为单位（最后一个数据包约为16KB）：

我使用

-XX:+UnlockDiagnosticVMOptions-XX:+PrintCompilation运行java，发现它通常在第二次验证校验和调用之前进行jit。
但是，到第6次呼叫开始下降时，仍然需要约5毫秒的时间

我制作了一个单独的Java文件来测试这一点，生成65536字节的随机数据并计算其校验和17次（每次我对512字节的块进行校验和，只是模仿HDFS的行为）。
我刚刚复制了Hadoop的PureJavaCrc32C的源代码（链接如上）。
这是文件

在我的计算机上，我看到了与以前类似的结果（如果我使用
-XX:+UnlockDiagnosticVMOptions-XX:+PrintCompilation
，
PureJavaCrc32C#update
在第二次调用之前与在HDFS上一样获得jit）

在ideone.com上，第一次调用后，时间实际上会立即下降（可能它使用了更激进的编译/执行选项？），但如果我在tutorialspoint.com上运行，我会看到类似的模式，约5毫秒运行，其余的亚毫秒运行

如果我添加
-XX:+printinline
，我看不到任何新内容。
我还注意到，在开始的几次慢时间和其余的几次快时间之间，似乎有一个“中间跑”；在第一组数字中，它从
~5ms->~1ms->~0.7ms
，在我的计算机上的测试文件中，它从
~10ms->~7ms->~0.2ms
，在教程点上，它从
~4ms->~1.5ms->~0.1ms


有人能解释这种行为吗？
JIT似乎与循环中途性能的大幅提升没有明显的关系，尽管其他因素可能在起作用。
我不知道JIT如何工作的细节，也找不到很多好的文章/论文来解释它，但我想也许在JIT编译完函数后，应用程序线程需要一段时间才能看到并使用本机函数？
此外，如果有人能指出一些好的、深入的JIT论文，那也会很感激的
看来JIT显然与大幅度的提高无关，在循环的中途，JIT与此相关。这是它的工作。我说“显然相关”；我相信这是有关联的，但我不明白，我想了解一下为什么JIT如此神秘的部分原因是……有点故意的：它没有具体说明，经常变化，任何文档都可能很快过时。这或多或少有点神奇。关于JIT如何工作的最佳文档是OpenJDK源代码。“其他因素”包括Java和OS的版本、CPU内核的数量、系统内存量等。正如您已经注意到的，行为因系统而异。如果不知道具体的环境，我们无法判断。例如，分层编译、编译器线程数、CPU速度——所有这些都会影响JIT计时。请记住，JIT可能在后台工作，可能在不同的优化级别上运行，并且可能会使先前编译的方法失效和重新编译。JIT似乎与大的性能没有明显的关系。在循环的中途，JIT与此有关。这是它的工作。我说“显然相关”；我相信这是有关联的，但我不明白，我想了解一下为什么JIT如此神秘的部分原因是……有点故意的：它没有具体说明，经常变化，任何文档都可能很快过时。这或多或少有点神奇。关于JIT如何工作的最佳文档是OpenJDK源代码。“其他因素”包括Java和OS的版本、CPU内核的数量、系统内存量等。正如您已经注意到的，行为因系统而异。如果不知道具体的环境，我们无法判断。例如，分层编译、编译器线程数、CPU速度——所有这些都会影响JIT计时。请记住，JIT可能在后台工作，可能在不同的优化级别上运行，并且可能使先前编译的方法无效并重新编译。
0.005154
0.005455
0.005836
0.005837
0.005884
0.001014
0.000741
0.000756
0.000718
0.000712
0.000709
0.000712
0.000718
0.000678
0.000677
0.000700
0.000186

0.010146
0.010859
0.012253
0.006862
0.000237
0.000225
0.000243
0.000244
0.000225
0.000242
0.000241
0.000243
0.000241
0.000241
0.000240
0.000239
0.000241