[jit即时制]jit即时编译是一种怎样的体验？

小卷现在负责的系统已经达到20万QPS，每天半夜QPS仍然达到一万人。每当系统升级发布时，抖动频繁，上游应用程序方面跑过来问。怎么服务又超时了，还能用吗。小卷只能伴随笑脸的说明。后来给小卷轴增添了优雅，下线了，这次发表应该不错。知道重新发表的话，超时问题仍然存在。小卷轴决定好好分析发表抖动问题的根本原因是什么。

服务抖动问题应根据具体情况进行分析。可能的原因包括：

RedisDB连接初始化需要很长时间，因此启动后接口RT会增加

JIT即时编译需要很长时间，CPU利用率高，接口RT高。

对于高并发应用程序，JIT即时编译是常见的原因。

JIT即时编译是一种运行计算机代码的方法，该方法在程序运行期间执行，而不是在运行程序之前执行。我摘录了维基百科关于JIT历史的内容。

众所周知，Java编译分为两部分。

将文件编译成文件。换句话说，转换为字节代码

解释器将字节码文件解释为机器代码执行

但是，解释执行缺点是明确的，执行速度慢。

Java最初使用解释执行逐个解释字节码，执行缓慢。快速重复调用代码会大大降低执行效率。为了以后解决这些问题，JVM引入了JIT实时编译，经常在Java虚拟机中执行在特定代码块或方法超过设置的阈值时被视为热点代码的代码块或方法。

很容易理解什么是JIT，并提出以下问题：

如何判断属于热点代码？

阈值是如何设置的？

我知道JIT将热点代码编译成机器代码进行缓存。那么，什么代码是热点代码呢？

正确计数，编译超过阈值的触发器

记录在一段时间内调用的次数，超过阈值触发编译

JVM默认使用的第二个方法统计方法调用数。第一个方法计算开销很高，第二个方法与调用时间相关，适用于大多数场景

只有超过上述阈值才能触发编译。阈值设置为多少？

C2编译器：编译时需要收集大量统计数据进行优化，为长期运行的应用程序优化性能的编译器，优化手段复杂，编译时间长，编译后的机器代码的执行效率高。启动时间会变长，为了获得最佳性能，程序需要很长时间才能运行。

JAVA8之后，默认情况下启用分层编译。也就是说，在应用程序启动初期，使用C1编译器缓存热点代码，系统稳定后，使用C2编译器继续优化性能。

可以通过几个参数进行设置

可以查看JVM当前使用的编译模式

方法被调用的次数，在C1模式下，默认阈值为1500次，在C2模式下为10000次，可以通过参数手动设置。对于分层编译，指定的阈值无效，并根据当前要编译的方法数和编译线程数动态调整。如果超过阈值，将触发编译，编译完成后，方法调用门户将更改为最新地址，下次直接使用机器代码。

计数器统计信息是一段时间内的调用数。如果时间限制调用数仍未达到阈值，则该方法的调用数将减少一半，并且不总是累积的。在这段时间内，该方法的统计半衰期称为。可以使用虚拟机参数关闭热衰减。参数设置半衰期的时间；执行热衰减的行为发生在虚拟机上进行垃圾收集时。

上面已经讨论了JIT实时编译。这样就可以理解刚开始的应用程序为什么RT突然提高，CPU利用率也很高。在高并发方案中，一种方法的调用次数激增，立即达到JIT编译的阈值，JVM立即执行编译，将热点代码转换为机器代码。热点代码过多会增加JIT编译压力，导致系统负载上升和CPU利用率提高，从而降低服务的整体性能

这里的小卷列出了一些解决方案，必须根据具体情况具体使用。例如：

流量调度平台的功能允许小流量预热后释放，从而减少JIT编译的影响。这是综合考虑访问成本和促销维护的最佳方案。这里阿里云微服务引擎MSE提供了功能少量预热服务，但是要收费~

我是公众号相同的名字在福报工厂修改福报的小本~