java - Protocol Buffer 首次使用高延迟

Question

在我们的一个 java 应用程序中，我们有很多 Protocol Buffer 类，并且 jar 本质上公开了一个接口(interface)和一个方法，该方法由另一个应用程序使用。我们注意到，第一次调用此方法时，调用时间相当长(>500ms)，而随后的调用要快得多(<10ms)。起初我们认为这与我们的代码有关，但是在分析之后我们无法确认这一点。通过消除过程，很明显它与 Protocol Buffer 有关。

当在不同的应用程序中进一步证实了这一点，该应用程序的工作方式完全不同 - 但也使用 Protocol Buffer - 表现出相同的行为。此外，我们尝试在启动时为所有 proto 缓冲区类创建一个虚拟实例 (XY.newBuilder().build())，对于我们添加的每个类，我们都可以注意到第一次调用下降的开销。

在 .NET 中，我可以找到另一个显示类似问题的问题(Why is ProtoBuf so slow on the 1st call but very fast inside loops?)，但是那里的解决方案似乎是特定于 C# 的预编译序列化程序。到目前为止，我在 Java 中找不到相同的问题。是否有类似上述问题中所示的适用于 java 的解决方法？

Answer 1

JVM 附带即时 (JIT) 编译器，可对您的代码进行大量优化。如果您想进一步了解它，可以深入研究 JVM 内部。会有类加载和卸载、性能配置文件、代码编译和反编译、偏向锁定等。

根据 this article 举个例子，这会变得多么复杂。 ，在 OpenJDK 中有两个编译器(C1 和 C2)，有五个可能的代码编译层:

Tiered compilation has five tiers of optimization. It starts in tier-0, the interpreter tier, where instrumentation provides information on the performance critical methods. Soon enough the tier 1 level, the simple C1 (client) compiler, optimizes the code. At tier 1, there is no profiling information. Next comes tier 2, where only a few methods are compiled (again by the client compiler). At tier 2, for those few methods, profiling information is gathered for entry-counters and loop-back branches. Tier 3 would then see all the methods getting compiled by the client compiler with full profiling information, and finally tier 4 would avail itself of C2, the server compiler.

这里的要点是，如果您需要可预测的性能，您应该始终通过在每次部署后运行一些虚拟请求来预热您的代码。

您使用创建所有使用的 protobuff 对象的虚拟代码做了正确的事情，但您应该更进一步并预热您正在使用的实际方法。