是否有可能比 C 中的相同程序(优化）更快地获得 Java 程序

理论上是的。实际上，这是极不可能的。

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

相反，正如Rekin所说，Java JVM需要动态地分析Java程序，以了解要优化的内容以及如何优化。性能分析本身就是一个昂贵的操作，这种开销无法从Java JVM上消除。另一方面，为当前工作负载选择正确的优化集可以带来优势。在实践中，大多数C程序（但不是全部:)针对他们的任务进行了很好的调整，并且几乎没有什么可以使用分析技术进行优化。

Java中还有其他影响，使这些编译问题完全相形见绌。可能排在第一位的是垃圾收集器。

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

但是，这是有代价的。一个非常大的。根据研究，有必要提供大约 5 倍的严格必要内存量，以确保垃圾收集器以最小的开销工作。因此，每当缺少如此多的内存时，GC 开销就会开始变得很大，从而使性能变得异常活跃。

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

但正如您可以猜到的那样，这并不常见...

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

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

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

但这是为依赖关系中的平台和Java更具可移植性而付出的代价。

从Java什么时候比C ++快（或者什么时候JIT比预编译更快）？，我发现了一些Java执行可能优于C/C++

大量少量内存分配/解除分配。主要的 JVM 有极其高效的内存子系统，垃圾回收可以比要求显式释放更有效（而且它可以转移内存地址等，如果它真的想要的话）。

通过方法调用的深层层次结构进行高效访问。JVM 是非常善于省略任何不必要的事情，通常最好我的经验比大多数C++编译器（包括GCC和ICC）。部分地这是因为它可以在运行时进行动态分析（即它可以过度优化，仅在检测到问题时才取消优化）。

将功能封装到小型短期对象中。

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

对于每个加载的类，都会在其上运行一些静态分析方法，看看是否有无法访问的代码、操作数栈类型问题等。

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

除此之外，您还可以获得垃圾收集器。

我真的无法想象一个正确编写的C程序，为它运行的平台编译，被Java等价物所超越。也许只有当你遇到一些罕见的极端情况时，JVM有一些优化，而C编译器没有实现特定的优化。

我看到Java运行得比C快的地方是资源有限，上市时间更重要。 在这种情况下，您没有像在 C 中那样高效地编写代码C++最终可能会做一些效率低于 JVM 为您做的事情。也就是说，如果你需要JVM已经做的事情，它可以更快。

如果你有一台拥有足够资源的机器，开发人员的时间会更昂贵/更关键，你可以在更短的时间内得到一个工作、稳定的系统，并且有时间进行剖析/优化，而 C 团队可能仍在修复所有核心转储。 您的里程会有所不同。

对于资源有限的设备，C 仍然占主导地位，因为您可以控制资源分配。 顺便说一句，大多数手机现在都可以很好地运行Java（或objective-C）。