Java 为什么谷歌ProtoBuf的性能会逐渐提高

我是谷歌ProtoBuf的新手。我注意到，ProtoBuf的性能随着编码/解码次数的增加而逐渐提高

我有一个用Java编写的测试，它对一个类进行编码并立即解码。同一类被编码/解码1000次

所花费的时间如下所示，第一个数字是编码所花费的时间，第二个数字是解码所花费的时间，以微秒为单位

 Proto: 886 , 993
 Proto: 888 , 997
 Proto: 850 , 1016
 Proto: 861 , 998
 Proto: 851 , 1055
 ......
 ......
 Proto: 469 , 545
 Proto: 469 , 555
 Proto: 403 , 612
 Proto: 421 , 713
 Proto: 374 , 535
 ......
 ......
 Proto: 186 , 477
 Proto: 189 , 473
 Proto: 186 , 476
 Proto: 186 , 700
 Proto: 190 , 483
 Proto: 194 , 464
 Proto: 186 , 397
 .......
 .......
 Proto: 110 , 135
 Proto: 107 , 125
 Proto: 115 , 134
 Proto: 111 , 142
 Proto: 131 , 136
 Proto: 108 , 124
 .......
 .......
 Proto: 82 , 107
 Proto: 79 , 100
 Proto: 78 , 100
 Proto: 85 , 101
 Proto: 69 , 68
 Proto: 67 , 66

 ......
 ......

 Proto: 73 , 69
 Proto: 71 , 69
 Proto: 85 , 83
 Proto: 73 , 68
 Proto: 74 , 72
 Proto: 74 , 68
 Proto: 71 , 68
 Proto: 71 , 76
 Proto: 72 , 68
 ......
 ......

 Proto: 33 , 28
 Proto: 34 , 28
 Proto: 47 , 32
 Proto: 35 , 28
 Proto: 33 , 28
 Proto: 34 , 29
 ......
 ......
 Proto: 36 , 45
 Proto: 44 , 29
 Proto: 34 , 28
 Proto: 34 , 28

这些测试都是独立的。我想知道：

ProtoBuf如何处理这个问题，以及为什么它会逐渐提高性能

为什么它一开始没有达到最佳性能

如何调整ProtoBuf，使其从一开始就达到最佳性能

非常感谢。

这是Java的典型特征：作为虚拟机的一部分，JIT（实时）编译器优化了大量运行的代码，并且可以随着代码运行次数的增加而稳定地应用更详细的优化，VM可以更多地了解代码在实践中的行为。例如，如果

List

变量几乎总是

ArrayList

，JVM可以进行优化，使其在这种情况下表现最佳

---

实际上没有办法改变这一点：编译器无法提前确定一个

条件是否比另一个更可能，JIT需要确定如何最佳优化代码的其他事项。
这很可能是JVM的事情，而不是ProtoBuf的事情。