jvm代码逆优化导致的cpu升高

背景

我们场景中会有使用ES来进行全文搜索的应用，既有往ES大量写数据的任务，也有直接构造查询条件从ES进行数据查询，但是偶尔ES会表现出system cpu负载很高的现象，而当把对应堆栈打印出来的时候，占用的cpu大头的是代码的逆优化的jvm方法,本文记录下运维查找的问题结果和原因

jvm代码逆优化导致的cpu飙升

jvm正常执行代码时，如果对应代码已经被执行多次，或者if else分支的某个条件一直满足，他就会把这些hotcode或者hot 的分支代码变异成本地机器码，下次执行时直接就是执行机器码就可以了，大大提高执行效率，然而这也会导致一些问题： 比如机器码中只包含了if某个分支的code，但是此时实际上方法的参数变了，实际上应该要执行到else分支，这种情况下，jvm不得不放弃掉这些机器代码，重新开始编译执行，这种极端情况下会导致很大的性能损耗，导致cpu负载升高，本次运维对ES的cpu升高问题的排除原因就是如此，ES中的很多方法逆优化导致的性能下降，进而导致cpu飙升，目前只有临时的解决方案：

-XX:ReservedCodeCacheSize=1G
-XX:PerMethodRecompilationCutoff=10000
-XX:PerBytecodeRecompilationCutoff=10000

这几个参数的目的是尽量减少jvm编译成机器code时去掉暂时不会进入的分支的code，也就是尽量保留所有的code到机器代码中，这样一旦需要进入不同的分支，机器代码中会存在对应分支的机器code，自然也就不需要反优化了.

参考文章：https://trino.io/blog/2021/10/06/jvm-issues-at-comcast.html
https://chriswhocodes.com/hotspot_options_openjdk21.html