java的字节码也是中间代码,为什么它的运行速度高于纯解释型语言呢?
书上都这么写,但给解释原因。

解决方案 »

  1.   

    你去看看java的运行原理就知道了,呵呵
      

  2.   

    JIT Compiler(Just-in-time Compiler) 即时编译
      最早的Java建置方案是由一套转译程式(interpreter),将每个Java指令都转译成对等的微处理器指令,并根据转译后的指令先后次序依序执行,由于一个Java指令可能被转译成十几或数十几个对等的微处理器指令,这种模式执行的速度相当缓慢。
      针对这个问题,业界首先开发出JIT(just in time)编译器。当Java执行runtime环境时,每遇到一个新的类别(class:类别是Java程式中的功能群组),类别是Java程式中的功能群组-JIT编译器在此时就会针对这个类别进行编译(compile)作业。经过编译后的程式,被优化成相当精简的原生型指令码(native code),这种程式的执行速度相当快。花费少许的编译时间来节省稍后相当长的执行时间,JIT这种设计的确增加不少效率,但是它并未达到最顶尖的效能,因为某些极少执行到的Java指令在编译时所额外花费的时间可能比转译器在执行时的时间还长,针对这些指令而言,整体花费的时间并没有减少。
      基于对JIT的经验,业界发展出动态编译器(dynamic compiler),动态编译器仅针对较常被执行的程式码进行编译,其余部分仍使用转译程式来执行。也就是说,动态编译器会研判是否要编译每个类别。动态编译器拥有两项利器:一是转译器,另一则是JIT,它透过智慧机制针对每个类别进行分析,然后决定使用这两种利器的哪一种来达到最佳化的效果。动态编译器针对程式的特性或者是让程式执行几个循环,再根据结果决定是否编译这段程式码。这个决定不见得绝对正确,但从统计数字来看,这个判断的机制正确的机会相当高。事实上,动态编译器会根据「历史资料」做决策,所以程式执行的时间愈长,判断正确的机率就愈高。以整个结果来看,动态编译器产生的程式码执行的速度超越以前的JIT技术,平均速度可提高至50%。
      

  3.   

    我想问的是:
    为什么java设计为首先将源代码编译为class字节码,然后,在由jvm解释字节码来执行,
    为什么不设计成JVM直接解释源程序执行? 字节码存在的原因是什么?
    如果只是为可跨平台,那么直接解释源程序执行就可以了!
      

  4.   

    解释性和高性能当运行Java程序时,它首先被编译成字节码,然后通过Java解释器直接对Java字节码进行解释执行。虽然这个过程是解释执行的,但是由于字节码的设计并不专门针对任何一种特定的机器,而是非常类似于机器指令的指令编码。因而通过Java的虚拟机就可以很容易的直接将字节码转换成对应于特定 CPU的机器码,从而得到较高的性能。这种转换的效率比其他解释性语言如Basic、Perl等要高得多,甚至在非常低档的CPU上也能顺利运行。不过 Java毕竟是解释性的语言,它解释执行的意义在于能够实现程序一经编译便可在众多不同的计算机上执行的跨平台运行。虽然这比C程序慢了许多,但在大多数应用中都是可以接受的。而且,现在Java也已经有了专门的代码生成器,可以很容易使用JIT编译技术将字节码直接转换成高性能的本机代码。值得一提的是,Java运行时系统在提供这个特性的同时仍具有平台独立性,因而“高效且跨平台”对Java来说不再矛盾。性能高的原因是:

    字节码的设计并不专门针对任何一种特定的机器,而是非常类似于机器指令的指令编码。因而通过Java的虚拟机就可以很容易的直接将字节码转换成对应于特定 CPU的机器码,从而得到较高的性能。

    对不?
      

  5.   

    对的吧,对机器语言而言,字节码是一种理想中的形式了
    我认为java既编译又解释,就是取道中庸
      

  6.   

    java是通过jdk将java文件编译成class的字节码文件在jvm中运行,速度当然非一般了。
    你去看看java的运行机制和原理