问有没有可能得到一个Java程序比用C编写的相同程序(经过优化)更快？

EN

理论上是这样的。在实践中，这是非常不可能的。

其中一个基本假设是，C/C++针对二进制操作码目标编译一次，而Java针对运行它的特定机器进行编译。这应该会给Java带来一些优势。但现实情况是，即使是C/C++也可以有几个优化路径，在运行时动态选择，并从特定目标编译中获得最大好处。

相反，正如Rekin所说，Java JVM需要动态地分析Java程序，以知道要优化什么以及如何优化。性能分析本身就是一项开销很大的操作，而且这一开销无法从Java JVM上消除。另一方面，为当前工作负载选择正确的优化集可以提供优势。在实践中，大多数C程序(但不是所有:)都针对它们的任务进行了很好的调优，几乎没有什么可以使用性能分析技术进行优化。

Java中还有一些其他的效果，它们完全掩盖了这些编译问题。第一个位置可能是垃圾收集器。

垃圾收集器的首要任务是简化编程，处理和避免C/C++中最糟糕的反复出现的bug之一，即内存泄漏。仅此特性就证明了Java在许多工业环境中大量使用是合理的。

然而，这是有代价的。一个非常大的。根据研究，有必要提供大约5倍的严格必要的内存量，以确保垃圾收集器以最小的开销工作。因此，每当这样的内存量不足时，GC开销就开始变得显著，从而使性能变得非常糟糕。

相反，在某些情况下，释放内存分配费用的算法可能允许更改算法，并采用更好、更快的算法。在这种情况下，Java可以获得优势，并且比C程序更快。

但正如你所猜到的，这并不常见。

事实上，C/C++程序是专门为特定平台编写的，并直接编译成机器代码，因此它们必然更接近于它们运行的软硬件平台。因此，它们会更快。

Java优化内置于JVM中，最佳优化(就程序执行速度而言)是通过处理字节码的即时(JTI)方式实现的。尽管JTI被证明是内存密集型的。

因此，比较这些策略清楚地表明，C/C++本机代码将更快；因为即使使用JTI，JVM将字节码转换为本机代码仍然有一些开销。

但这是为依赖平台和java更易移植而付出的代价。

取自when is java faster than c++ (or when is JIT faster then precompiled)?，我发现了一些Java执行优于C/C++的场景

大量的小内存分配/释放。主要的JVM都有非常高效的内存子系统，垃圾收集可能比要求显式释放更有效(此外，如果它真的想要的话，它还可以移动内存地址等)。

通过方法调用的深层层次结构进行有效访问。JVM非常擅长省略任何不必要的东西，在我的经验中通常比大多数C++编译器(包括gcc和icc)更好。在某种程度上，这是因为它可以在运行时进行动态分析(即，它可能会过度优化，只有在检测到问题时才会取消优化)。

将功能封装到短命的小对象中。

JVM的开销是巨大的。它必须加载几个类，这些类位于zip (jar)文件中，需要提取。

对于加载的每个类，将在其上运行一些静态分析方法，以查看是否存在无法访问的代码、操作数堆栈类型问题和其他问题。

然后，分析器一直在运行以确定代码的哪些部分值得优化，这通常意味着在优化这些方法之前需要调用几千次。

除此之外，你还得到了垃圾收集器。

我真的不能想象一个正确编写的C程序，在运行它的平台上编译的时候，它的性能会比Java等效物更好。也许只有当您遇到一些罕见的情况时，即JVM有一些优化，而C编译器没有实现这种特定的优化。