Java真的很慢吗？

Question

已锁定 。该问题及其答案被锁定，因为该问题是题外话，但具有历史意义。它目前不接受新的答案或互动。

Java 因其速度慢而享有一定的声誉。

• Java真的很慢吗？
• 如果是，为什么？瓶颈在哪里？是因为JVM效率低下吗？垃圾收集？纯字节码库而不是JNI包装的C代码？许多其他语言都具有这些功能，但是它们并没有因速度慢而享有盛誉。

Answer 1

现代Java是最快的语言之一，即使它仍然是内存消耗大的人。Java的 了 ，因为它曾经花费很长的时间VM启动正在缓慢的声誉。

如果您仍然认为Java运行缓慢
，请参见基准测试结果。用预先编译的语言（C，Fortran等）编写的经过严格优化的代码可以胜过它；但是，Java的速度可以是PHP，Ruby，Python等的10倍以上。在某些方面，它可以击败常见的编译语言（如果它们使用标准库）。

现在没有“慢” Java应用程序的借口。 归咎于开发人员和遗留代码/库，而不仅仅是语言。另外，也要怪任何“企业”。

为了公平地对待“ Java缓慢”人群，以下是仍然缓慢的区域（2013年更新）：

• 库的编写通常是出于“正确性”和可读性，而不是性能。 我认为，这是Java信誉仍然很差的主要原因，尤其是服务器端。这使String问题成倍恶化。一些简单的错误是常见的：对象通常用于代替基元，从而降低性能并增加内存使用量。许多Java库（包括标准库）将频繁创建String，而不是重用可变或更简单的格式（char []或StringBuffer）。这很慢，并且会产生大量垃圾以便以后收集。为了解决这个问题，我建议开发人员在可能的情况下使用原始集合，尤其是Javalution的库。

• 字符串操作有点慢。 Java使用不可变的UTF-16编码的字符串对象。这意味着您需要更多的内存，更多的内存访问权限，并且某些操作比ASCII（C，C ++）更为复杂。当时，这是可移植性的 正确 决定，但性能成本却很小。UTF-8现在看起来是一个更好的选择。

• *由于边界检查 *，与C相比，数组访问要慢一些 。代价过去曾经很大，但是现在很小（Java 7优化了许多多余的边界检查）。

• 缺少任意内存访问可能会使某些I / O和位级处理变慢（例如压缩/解压缩）。 现在，这是大多数高级语言的安全功能。

• Java使用的内存比C多得多， 并且如果您的应用程序受内存限制或内存带宽限制（缓存等），这会使它变慢。不利的一面是分配/取消分配的速度很快（高度优化）。 现在，这是大多数高级语言的功能，并且是由于对象和 GC的使用，而不是显式的内存分配。 加上不好的图书馆决定。

• 基于流的I / O速度很慢 ，这 是 因为（IMO，选择不当）要求在每个流访问上进行同步。NIO修复了这个问题，但是使用起来很麻烦。通过对数组（而不是一次元素）进行读/写操作，可以解决此问题。

• Java没有提供C所提供的低级功能， 因此您不能使用肮脏的内联汇编器技巧来使某些操作更快。 这提供了可移植性，并且是当今大多数高级语言的功能。

• 看到Java应用程序绑定到非常老的JVM版本是很常见的。 特别是服务器端。与最新版本相比，这些旧的JVM效率极低。

最后，Java被设计为提供安全性和可移植性，但以牺牲一些性能为代价，并且显示了某些真正苛刻的操作。其缓慢的大多数声誉不再应有。

但是，在一些地方，Java 比大多数其他语言 都快 ：

• 内存分配和取消分配既快速又便宜。 我见过这样的情况：分配新的多kB阵列比重用缓存的阵列要快20％（或更多！）。

• 对象实例化和面向对象的功能使用起来非常快 （在某些情况下比C ++更快），因为它们是从一开始就设计的。这部分来自良好的GC，而不是显式分配（这对许多小对象分配更友好）。可以编写代码来克服这种情况（通过滚动自定义内存管理并有效地执行malloc），但这并不容易。

• 方法调用基本上是免费的，并且在某些情况下比大方法代码要快。 该热点编译器使用的执行信息来优化方法调用，具有非常高效的内联。通过使用附加的执行信息，它有时可能会比提前编译器甚至在手动插入中（在极少数情况下）都更好。与C / C 相比，在C / C 中，如果编译器决定不内联，则方法调用的性能会受到较小的影响。

• 同步和多线程既简单又高效。 从一开始，Java就被设计为可感知线程的。现代计算机通常具有多个内核，并且由于线程是语言的内置功能，因此您可以轻松利用。与标准的单线程C代码相比，基本上速度提高了100％至300％。 是的，精心编写的C线程和库可以解决这个问题，但这对程序员来说是很多额外的工作。

• 字符串包括长度：某些操作更快。 使用以空分隔的字符串（在C中常见）拍子。在Java 7中，Oracle进行了String.subString（）优化，因为人们愚蠢地使用它并导致内存泄漏。

• 阵列复制已高度优化。 在最新版本中，Java对System.arraycopy使用手动调整的汇编程序。结果是，在大量进行arraycopy / memcopy的操作中，我已经看到我的代码以合理的幅度击败了C语言中的等效代码。

• JIT编译器很聪明地使用 L1 / L2缓存。提前编译的程序无法将其代码实时调整为它们正在运行的特定CPU和系统。JIT通过这种方式提供了一些非常有效的循环转换。

其他一些历史事实促成了“ Java缓慢”的声誉：

• 在JIT编译（Java 1.2 / 1.3）之前，该语言仅被解释，未被编译，因此非常慢。
• JIT编译需要时间才能变得高效（每个版本都有重大改进）
• 多年来，类加载已变得更加高效。在启动过程中，它以前的效率很低而且很慢。
• Swing和UI代码不能很好地使用本机图形硬件。
• 摇摆真可怕。 我将AWT和Swing归咎于Java为什么从不流行于桌面。
• 在库类中大量使用同步；现在可以使用非同步版本
• 由于要通过网络传输完整的JAR并加载VM以进行引导，因此Applet的加载需要花费很长时间。
• 同步曾经带来了沉重的性能损失（每个Java版本都对此进行了优化）。但是，反思仍然是昂贵的。