何时java有错误的优化？

Question

JIT在10k调用后进行方法优化(-XX:+PrintCompilation)，您可以使用-XX:CompileThreshold对其进行配置。我读到了不降低阈值的原因是JIT优化可能是错误的，或者您优化了很少使用的代码。关于这方面，我有几个问题：

1. 我认为错误的优化(即堆栈上的替换)是由于多态方法的延迟类加载造成的。但是在找到3种实现(我认为)之后，JVM只需进行索引表查找。当然，如果你有更多的多态推动力，速度就会受到影响。多态方法是导致JIT优化错误的唯一原因还是主要原因？如果没有，其他的是什么呢？
2. ，如果我可以强制在运行时加载所有的类，以便JVM可以提前构建这样的索引表，那么提前进行总体优化不是更好吗？优化所有的方法有什么问题？如果我的目标仅仅是速度，那么代价是什么呢?与
3. 相比，如果我的源代码关闭--这意味着没有第三方库，就像那个低延迟系统一样--有没有办法迫使优化提前提高性能，使性能更接近c++?
4. Peter Lawrey在他的甲骨文杂志文章中提到，你可以通过在生产中人为地运行足够的测试数据来启动JIT。这样做似乎是危险的生产环境和一个不幸的，你将被解雇。一定有更好的方法在最小风险的情况下做到这一点。关于这个主题的任何好的参考资料(涉及java & appreciated.

)都是

更新：#3.永远不要期望java比c++更快，只是希望更接近。

Answer 1

是否有一种预先强制优化以提高性能的方法比c++更好？

不是的。这是Java规范中强制执行的语义的基本限制，以及JVM生态系统的工作方式，假设实现和代码的同等质量，它将比C++实现慢。有关更多细节，请查看my existing answer on this subject。