Java真的很慢吗？ [英] Is Java really slow?

问题描述

Java已经某种程度的声誉因为速度慢。

• Java真的很慢吗？


• 如果是，为什么？瓶颈在哪里（或曾经）？是因为效率低下的JVM？垃圾收集？纯字节码库而不是JNI包装的C代码？许多其他语言都具有这些功能，但它们没有这种缓慢的声誉。

推荐答案

现代Java是最快的语言之一，即使它仍然是记忆猪。 Java 因为过慢需要启动VM而声名远逊。

Modern Java is one of the fastest languages, even though it is still a memory hog. Java had a reputation for being slow because it used to take a long time for the VM to start up.

如果您仍然认为Java很慢，请参阅基准游戏结果。用提前编译语言（C，Fortran等）编写的紧密优化的代码可以击败它;但是，Java的速度可以超过PHP，Ruby，Python等的10倍。有一些特定领域可以胜过常见的编译语言（如果它们使用标准库）。

If you still think Java is slow, see the benchmarks game results. Tightly optimized code written in a ahead-of-time compiled language (C, Fortran, etc.) can beat it; however, Java can be more than 10x as fast as PHP, Ruby, Python, etc. There are specific areas where it can beat common compiled languages (if they use standard libraries).

现在没有慢Java应用程序的借口。开发人员和遗留代码/库应该归咎于远远超过语言。此外，责怪任何'企业'。

There is no excuse for "slow" Java applications now. Developers and legacy code/libraries are to blame, far more than the language. Also, blame anything 'enterprise.'

• 库通常是为了正确性和可读性而非性能而写的。在我看来，这是Java仍然有一个坏名声的主要原因，尤其是服务器端。这使得String问题呈指数级恶化。一些简单的错误很常见：通常使用对象代替基元，从而降低性能并增加内存使用。许多Java库（包括标准库）将经常创建字符串，而不是重用可变或更简单的格式（char []或StringBuffer）。这很慢并且会产生大量的垃圾以便以后收集。为了解决这个问题，我建议开发人员尽可能使用原始集合，特别是Javalution的库。

• Libraries are often written for "correctness" and readability, not performance. In my opinion, this is the main reason Java still has a bad reputation, especially server-side. This makes the String problems exponentially worse. Some simple mistakes are common: objects are often used in place of primitives, reducing performance and increasing memory use. Many Java libraries (including the standard ones) will create Strings frequently, rather than reusing mutable or simpler formats (char[] or StringBuffer). This is slow and creates tons of garbage to collect later. To fix this, I suggest developers use primitive collections and especially Javalution's libraries, where possible.

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

String operations are a bit slow. Java uses immutable, UTF-16-encoded string objects. This means you need more memory, more memory access, and some operations are more complex than with ASCII (C, C++). At the time, it was the right decision for portability, but it carries a small performance cost. UTF-8 looks like a better choice now.

由于边界检查，数组访问与C相比有点慢，。过去的惩罚很大，但现在很小（Java 7优化了很多冗余边界检查）。

Array access is a bit slower compared to C, due to bounds checks. The penalty used to be big, but is now small (Java 7 optimizes away a lot of redundant bounds checks).

缺少任意内存访问可以使一些I / O和位级处理速度慢（例如压缩/解压缩）。 这是大多数高级语言的安全功能。

Lack of arbitrary memory access can make some I/O and bit-level processing slow (compression/decompression for example). This is a safety feature of most high-level languages now.

Java使用的内存比C多， 如果您的应用程序受内存限制或内存带宽限制（缓存等），则会使速度变慢。另一方面，分配/解除分配的速度非常快（高度优化）。 这是现在大多数高级语言的一个特性，由于对象和 GC 而不是明确的内存分配。加上糟糕的库决策。

Java uses a LOT more memory than C, and if your application is memory bound or memory bandwidth bound (caching, etc.) this makes it slower. The flipside is that allocation/deallocation is blazing fast (highly optimized). This is a feature of most high-level languages now, and due to objects and use of GC rather than explicit memory allocation. Plus bad library decisions.

基于Streams的I / O很慢由于（IMO，选择不当）要求在每次流访问时进行同步。 NIO 解决了这个问题，但使用它很痛苦。可以通过对数组进行读/写而不是一次对元素进行处理来解决这个问题。

Streams-based I/O is slow due to the (IMO, poor choice) to require synchronization on each stream access. NIO fixed this, but it is a pain to use. One can work around this by doing read/write to an array, instead of an element at a time.

Java不提供相同的功能。低级功能C，，因此您不能使用脏内联汇编程序技巧来加快某些操作。 这提供了可移植性，现在是大多数高级语言的一项功能。

Java doesn't provide the same low-level functionality C does, so you can't use dirty inline assembler tricks to make some operations faster. This provides portability and is a feature of most high-level languages now.

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

It is common to see Java applications tied to very old JVM versions. Especially server-side. These old JVMs can be incredibly inefficient, compared to the latest versions.

最后，Java旨在提供以某些性能为代价的安全性和可移植性，以及它所显示的一些非常苛刻的操作。它的缓慢声誉大部分都不再值得。

In the end, Java was designed to provide security and portability at the expense of some performance, and for some really demanding operations it shows. Most of its reputation for slowness is no longer deserved.

• 内存分配和解除分配
  快速又便宜。我见过
  的情况，它比20美元更快（或更多！）到
  分配一个新的，多KB的数组比
  重用缓存的。

• Memory allocation and de-allocation are fast and cheap. I've seen cases where it is 20% FASTER (or more!) to allocate a new, multi-kB array than to reuse a cached one.

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

Object instantiation and object-oriented features are blazing fast to use (faster than C++ in some cases), because they're designed in from the beginning. This is partially from good GC rather than explicit allocation (which is more friendly to lots of small object allocations). One can code C that beats this (by rolling custom memory management and doing malloc efficiently), but it is not easy.

方法调用基本上是免费，在某些情况下比大方法代码更快。 HotSpot 编译器使用执行优化方法调用的信息，并具有非常高效的内联。通过使用额外的执行信息，它有时可以胜过提前编译器甚至（在极少数情况下）手动内联。与C / C ++相比，如果编译器决定不内联，方法调用会带来很小的性能损失。

Method calls are basically free and in some cases faster than large-method code. The HotSpot compiler uses execution information to optimize method calls and has very efficient inlining. By using the additional execution information, it can sometimes outperform ahead-of-time compilers and even (in rare cases) manual inlining. Compare to C/C++ where method calls come with a small performance penalty if compiler decides not to inline.

同步和多线程很容易效率很高。 Java的设计从一开始就是线程感知的，它表明了。现代计算机通常具有多个内核，并且由于线程内置于该语言中，因此您可以非常轻松地利用它。与标准的单线程C代码相比，基本上可以提高100％到300％的速度。 是的，精心编写的C线程和库可以胜过这个，但这对程序员来说是一项额外的工作。

Synchronization and multi-threading are easy and efficient. Java was designed to be thread-aware from the beginning, and it shows. Modern computers usually feature multiple cores, and because threading is built into the language, you can very easily take advantage. Basically an extra 100% to 300% speed boost vs. standard, single-threaded C code. Yes, carefully written C threading and libraries can beat this, but that's a lot of extra work for the programmer.

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

Strings include length: some operations are faster. This beats using null-delimited strings (common in C). In Java 7, Oracle took out the String.subString() optimization, because people were using it stupidly and getting memory leaks.

数组副本是高度优化。在最新版本中，Java使用手动调整的汇编程序进行System.arraycopy。结果是在arraycopy / memcopy-heavy操作中，我看到我的代码在C中以合理的余量超过了等价物。

Array copy is highly optimized. In the lastest versions, Java uses hand-tuned assembler for System.arraycopy. The result is that in arraycopy/memcopy-heavy operations, I've seen my code beat the equivalent in C by reasonable margins.

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

The JIT compiler is smart about using L1/L2 cache. Ahead-of-time compiled programs can't tweak their code in real-time to the specific CPU & system they're running on. JIT provides some very efficient loop transformations this way.

• 在JIT编译之前（Java 1.2 / 1.3），语言只是被解释，而不是编译，因此非常慢。 / li>
  
• JIT编译需要时间才能提高效率（每个版本都有重大改进）


• 多年来，类加载变得更加高效。它在启动过程中效率很低而且很慢。


• Swing 和UI代码没有很好地使用本机图形硬件。


• Swing很糟糕。我责怪AWT和Swing为什么Java永远不会抓住了桌面。


• 在库类中大量使用同步;非同步版本现已可用


• 小程序需要永远加载，因为传输完整的 JAR 并加载虚拟机进行启动。


• 同步用于承担严重的性能损失（这已针对每个Java版本进行了优化） 。但是反思仍然很昂贵。

• Before JIT compilation (Java 1.2/1.3), the language was only interpreted, not compiled, and thus very slow.
• JIT compilation took time to become efficient (major improvements with each version)
• Classloading has become a lot more efficient over the years. It used to be quite inefficient and slow during startup.
• Swing and UI code did not use native graphics hardware very well.
• Swing is just awful. I blame AWT and Swing for why Java never caught on for the desktop.
• Heavy use of synchronization in library classes; unsynchronized versions are now available
• Applets take forever to load, because of transmitting a full JAR over the network and loading the VM to boot.
• Synchronization used to carry a heavy performance penalty (this has been optimized with each Java version). Reflection is still costly, though.

这篇关于Java真的很慢吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！