Java有some degree of reputation for being slow。
答案 0 :(得分：236)
答案 1 :(得分：49)
最初Java并不是特别快，但它也不是太慢。这些天，Java非常快。从我与之交谈过的人们看来，Java缓慢的印象来自两件事：
虚拟机启动时间较慢。与本机应用程序相比，早期的Java实现需要很长时间才能启动并加载require库和应用程序。
网页速度慢。早期Swing很慢。大多数Windows用户发现默认的Metal L＆amp; F丑陋也许没有帮助。
鉴于以上几点，难怪人们得到了“Java缓慢”的印象。
对于用于开发本机应用程序甚至Visual Basic应用程序的用户或开发人员来说，这两点是应用程序中最明显的一点，它是您对应用程序的第一印象（除非它是一个非GUI应用程序，在这种情况下只适用1.）。
当应用程序需要8秒钟启动时，您不会说服用户“它执行代码的速度非常快”与他立即启动的旧Visual Basic应用程序相比 - 即使代码执行和启动时间可能根本没有连接。
破坏第一印象是开始谣言和神话的好方法。谣言和神话很难被杀死。
简而言之，Java并不慢。拥有“Java态度缓慢”的人是基于10多年前对Java的第一印象。
答案 2 :(得分：40)
在阅读了一篇充满评论的页面后，说Java并不慢，我只需回答一个不同的意见。
语言的缓慢很大程度上取决于您对“快速”的期望。如果你认为C＃很快，Java肯定也很快。如果您的问题域与数据库或半实时处理相关，那么Java肯定也足够快。如果您乐意通过添加更多硬件来扩展应用程序，那么Java可能很快就会出现。如果你认为5-10级的常数因子加速并不值得，你可能会考虑Java。
如果对大型数据集进行数值计算，或者绑定到CPU资源有限的执行环境，那么5-10级的常量加速将是巨大的。即使0.5加速也可能意味着计算完成时减少500小时。在这些情况下，Java只是不允许你获得最后一码的性能，你可能会认为Java很慢。
答案 3 :(得分：33)
答案 4 :(得分：16)
这是Java早期（20世纪90年代中后期）的过时信息。与之前的版本相比，Java的每个主要版本都引入了显着的加速。由于Oracle显然将JRockit与Sun的JVM for Java 7合并，这种趋势似乎将继续下去。
与许多其他流行的现代语言（Python，Ruby，PHP）相比，Java在大多数用途中实际上要快得多。它与C或C ++不完全匹配，但对于许多任务而言，它足够接近。真正的性能问题应该是它最终使用多少内存。
答案 5 :(得分：14)
Java肯定很慢，特别是对于量化工作。
我使用R，Python和C / C ++与优化的多线程ATLAS库的组合。在每种语言中，我可以在大约4秒内将矩阵乘以3000乘3000矩阵。在Java中使用Colt和Parallel Colt，相同的操作需要185秒！尽管这些java库本质上是并行的，但令人惊讶。
总而言之，纯Java不适合定量工作。 Jblas似乎是Java中最好的线性代数库，因为它使用ATLAS。
我的机器是HP Core 2 Duo，内存为3 GB。我使用64位Ubuntu 10.04（Lucid Lynx）。
答案 6 :(得分：14)
“长启动时间”的主要罪魁祸首是动态链接。 Java应用程序由已编译的类组成。每个类通过 name 引用其他类（对于参数类型，方法调用...）。 JVM必须在启动时检查并匹配这些名称。它会逐步增加，只在任何给定时间执行它所需的部分，但这仍然是一些工作要做。
在C应用程序中，链接阶段发生在编译结束时。它很慢，特别是对于大型应用程序，但只有开发人员才能看到它。链接产生一个可执行文件，操作系统只需要“按原样”加载到RAM中。
在Java中，每次运行应用程序时都会发生链接。因此启动时间很长。
已经应用了各种优化，包括缓存技术，并且计算机变得更快（并且它们比应用程序“更大”更“快”），因此最近问题的重要性大大降低;但旧的偏见仍然存在。
至于之后的性能，我自己的基于数组访问的紧凑计算基准（主要是散列函数和其他加密算法）通常表明优化的C代码比Java代码快3倍左右;有时C只比Java快30％，有时C可以快4倍，具体取决于实现的算法。由于处理器提供的64x64-> 128乘法操作码但是Java无法使用，因为它的最长整数类型是64位{{1 }}。这是一个边缘案例。在实际条件下，I / O和内存带宽注意事项会阻止C代码真正比Java快三倍。
答案 7 :(得分：10)
对于大多数人与之交互的体验 - Java 很慢。在一些applet出现之前，我们都看到咖啡杯在我们的浏览器上旋转。启动JVM并下载applet二进制文件需要一段时间，这会以一种被注意到的方式影响用户体验。
缓慢的JVM启动和applet下载时间明显地标有Java咖啡杯并没有帮助，因此人们将等待与Java相关联。当Flash需要很长时间才能加载时，“加载”消息的标记由Flash开发人员指定，因此人们不会将Flash技术归咎于整体。
所有这些都与Java在服务器上的性能无关，或者与Java在浏览器外部使用的许多其他方式无关。但这是人们看到的内容，以及非Java开发人员在考虑Java时所记得的内容。
答案 8 :(得分：9)
Java的声誉很慢，因为 很慢。 Java的第一个版本没有或相当差的Just In Time编译。这意味着代码（尽管字节码）正在被解释，因此即使对于最简单的操作（如添加两个整数），机器也必须进行各种比较和指针解引用和函数调用。 JIT编译器一直在不断改进;现在，如果我不小心编写C ++代码和粗略地编写Java代码，Java有时优于 C ++，因为JIT编译器意识到我有一些不必要的指针解除引用并将为此处理它我
如果您想了解JIT编译的差异有多大，请查看Computer Languages Benchmark Game处的解释与非解释基准。 （Pidigits使用外部库进行所有计算，因此基准测试不会改变;其他的显示速度提高6-16倍！）
所以，这是主要原因。还有其他一些不太重要的原因没有帮助：最初，Java启动时间很慢（现在已经修复）; Java中的Web应用程序需要花费很长时间才能下载（现在宽带可以广泛使用，并且需要大量电影等）; UI Swing没有（现在仍然没有）以性能为基础进行编写，因此它比例如同等对应的内容更不敏捷。 C ++。
答案 9 :(得分：6)
斯特凡诺：
我从一开始就使用Java，所以从我的观点来看，缓慢的名声是由非响应和慢的GUI前端（AWT，然后是Swing）和Applet创建的，可能是因为额外的慢启动虚拟机的时间。
Java在VM领域已经规定并推动了大量的研究，并且已经有了相当多的改进，包括垃圾收集（你可以实际调整很多东西;但是，我常常看到只使用默认值的系统）和热点优化（在开始时，在服务器端可能仍然更有效）。
后端的Java和计算级别并不那么慢。 Colt是最好的例子之一：
最新稳定的Colt版本打破了JDK ibm-1.4.1，RedHat 9.0,2x IntelXeon@2.8 GHz的1.9 Gflop / s障碍。
主流Java之外应该考虑许多事情，比如Realtime Java或提高速度的特殊机制，如Javolution，以及Ahead-Of-Time编译（如gcj）。此外，有些IC可以直接执行Java字节码，例如当前iPhone和iPod ARM Jazelle中的那个。
我认为今天一般来说这是一个政治决定（就像iPhone / iPod上没有Java支持一样），并且决定将Java作为一种语言（因为许多人认为它过于冗长）。
然而，现在Java VM还有许多其他语言（例如Python，Ruby，JavaScript，Groovy，Scala等）可能是另一种选择。
我个人继续喜欢它作为一个灵活可靠的平台，具有出色的工具和库可用性，允许用户处理从最小的设备（例如JavaCard）到最大的服务器的所有内容。
答案 10 :(得分：6)
Java在当天还很慢。由于a few generations of performance enhancements，它变得更快。最后我听说，它通常在C＃速度的10％以内 - 有时更快，有时更慢。
Java applet启动仍然很慢，因为你必须启动一个完整的JVM，它必须加载它的所有类。有点像启动另一台电脑。一旦JVM启动它就会非常快，但启动通常是人们记住的。
此外，有at least a few people永远不会相信Java的可行性。
答案 11 :(得分：4)
与其他许多工具相比，锤子在推出面团时要慢得多。不会使锤子“变慢”，也不会对它设计的任务有用。
作为一种通用编程语言，Java与许多（如果不是大多数）编程任务相当。有一些特殊的，微不足道的测试，Java不会在不太复杂的语言中胜过手工编码的解决方案，而是“更接近金属”。
但是当谈到“真实世界的应用程序”时，Java通常是正确的工具。现在，也就是说，没有什么能阻止开发人员使用任何工具制作性能缓慢的解决方案。滥用工具是一个众所周知的问题（只需看看PHP和VB的声誉）。但是，Java（大多数）干净的设计和语法确实可以减少误用。
答案 12 :(得分：3)
Java是一种高级语言，它现在的声誉是与其他类似的高级语言相提并论。
它有dynamic binding个语义。与将非虚拟方法编译为函数调用的C ++相比，即使是世界上最好的Java编译器也必须生成效率较低的代码。但它也是一种更清晰，更高级的语义。
我不记得细节了，但是我在Java的早期就听说每个Java对象都有一个互斥锁，每个方法都可以获取并释放它们。这往往会使它更好地适应并发，但不幸的是，每个对象的互斥锁不会保护您免受竞争或死锁或并发程序中可能发生的任何不良事件的影响。那部分，如果是真的，有点天真，但它来自善意。如果您对这方面有更多了解，请随时填写详细信息。
Java是高级语言的另一种方式是拥有Garbage-Collection。对于一次性分配所需内存并使用它的程序，垃圾收集可能比malloc和free慢。问题是，在没有Garbage-Collection的语言中，程序员倾向于编写 only 程序，这些程序一次性分配他们需要的所有内存，如果发现某些任意最大大小常量已经溢出则会失败。因此，比较是苹果与橘子。当程序员通过在非GC语言中动态分配链式结构来编写和调试程序时，他们有时会发现他们的程序不再比GC语言更快，因为malloc和free不是免费的！它们也有开销...另外，没有GC强制指定谁释放了什么，并且必须指定谁释放什么反过来有时迫使你复制 - 当几个函数需要数据而且不清楚哪个将最后使用它 - 而在GC语言中不需要复制。
答案 13 :(得分：2)
在九十年代中期，Java成为主流，C ++是主流语言，网络仍然相当新。此外，JVM和GC是主流开发中相对较新的概念。早期的JVM有点慢（与在裸机上运行的C ++相比），并且有时还会遭受长时间的垃圾收集暂停，这导致Java的声誉很慢。
答案 14 :(得分：1)
正如Pascal所说，Java与其他高级语言不相上下。但是，作为在Windows 98上使用原始JVM的人，当时我们说Java虚拟机提供的抽象级别是痛苦的。
基本上，它是软件仿真，很少或没有优化，我们今天在JVM中理所当然。
答案 15 :(得分：1)
许多Java桌面应用程序（这些时候：像Eclipse这样的东西）具有糟糕的GUI响应能力，可能是由于内存消耗高以及类加载器可以执行大量IO操作。 它正在改善，但几年前情况更糟。
许多（大多数）人喜欢进行概括，所以他们说“Java很慢”，因为他们认为应用程序在与他们交互时很慢。
答案 16 :(得分：1)
java应用程序的主要问题是，由于库存运行时库的大小，它是 huge 。巨大的程序在内存中占了很大的份额并且倾向于交换，这意味着它们变得很慢。
Sun JVM之所以大，是因为它有一个非常好的字节码解释器，可以跟踪很多事情。这意味着很多数据，这意味着内存。
您可能希望查看jamvm虚拟机，它是一个相当快速的解释器（没有本机代码）并且非常小。它甚至可以快速启动。
答案 17 :(得分：0)
人们通常会走出“它的解释”线。因为很久以前就是这样，并且糟糕的媒体被那些将Java倾倒为“太慢”并且从未返回测试新版本的人传下来。
或许“人是白痴”是一个更好的答案。
答案 18 :(得分：0)
我想有一天，也许不是在不久的将来，JIT编译的语言在任何方面都会胜过编译语言（好吧，也许不是启动时间/内存消耗），因为JIT编译器可能会变重使用运行时行为及其运行的平台。