问题描述
我知道，当以极高的性能为目标时，函数式编程/lambdas 并不是 Java 世界的最佳选择。 Kotlin 使用 inline 关键字解决了该问题。
当 Kotlin 被编译并且 lambda 被内联时，它实际上是在创建更大的方法，而 JIT 有一个 N 字节的硬上限来内联到本机代码。考虑到这一点，Kotlin 的 inline 是否会损害 JIT 的内联并因此影响性能？
另外，我注意到 Kotlin 在编译后的代码中添加了很多空检查，这些检查是非常小的方法，肯定是由 JIT 内联的，但是由于调用量很大，这难道不是一个性能问题吗？
那么，如果您的目标是尽可能提高性能，那么 Kotlin 对 JVM 的影响是什么？
副节点：我知道，我知道..“过度优化是万恶之源”，“你不应该关心这个级别的性能”。
解决方法
您可以覆盖用于字节码的内联值的限制。有关详细信息，请参阅 What is the size of methods that JIT automatically inlines? 上的答案。
我很惊讶字节码中有很多空检查。通常 Java 不会这样做，而是让 CPU 以更高的性能自动处理这些。
它们可能会被 JVM 的 JIT 忽略，所以一旦预热可能不会成为问题，但是如果您想要更高的性能，您可能希望让您的服务器通过虚拟数据运行以确保 JIT 预热.没有什么比温暖的 JIT 遇到编译事件并且不得不再次经历这一切更糟糕的了。
如果您注意 JIT 编译事件并注意未使编译或联机的“热方法”消息，那么您可以单独调整这些方法。
不过一般来说，如果你避免使用 lambda，那么你会发现 JVM 不需要做这么多的内联，更糟糕的是不需要做那么多的分配。 Lambda 在意外捕获状态并导致分配发生方面非常糟糕。理想情况下，在高吞吐量/低延迟系统中，您希望避免尽可能多的分配。