字节码在本地代码上的优点是什么？
看起来你可以用字节码做任何事情，你可以在本地代码中简单快速地做到这一点。 从理论上说，甚至可以通过在字节码中分发程序和库，然后在安装时编译为本地代码，而不是JITing，来保持平台和语言的独立性。
所以一般来说，你想什么时候执行字节码而不是本地的？
SGI的Hank Shiffman说（很久以前，但是直到现在）：
Java使用字节码有三个好处，而不是转到系统的本地代码：
可移植性 ：每种计算机都有其独特的指令集。 虽然有些处理器包含了对其前辈的说明，但在一种计算机上运行的程序通常不会在其他任何程序上运行。 添加操作系统提供的服务，每个系统都以自己独特的方式描述，并且存在兼容性问题。 一般来说，你不能为一种系统编写和编译一个程序，而且在没有很多工作的情况下运行它。 Java通过在应用程序和真实环境（计算机+操作系统）之间插入虚拟机来解决这个限制。 如果一个应用程序被编译成Java字节码，并且字节码在每个环境中都以相同的方式解释，那么你可以编写一个单独的程序，它可以在所有支持Java的不同平台上工作。 （无论如何，这就是理论。实际上，程序员总是存在小小的不兼容问题。）
安全性 ：Java的优点之一就是将其集成到Web中。 将使用Java的网页加载到浏览器中，并自动下载并执行Java代码。 但是，如果代码破坏文件，无论是通过程序员的恶意还是剽窃呢？ Java通过禁止潜在的危险操作阻止下载的applet做任何破坏性的事情。 在它允许代码运行之前，检查它是否绕过安全性。 它会validation数据的使用是否一致：在一个阶段将数据项操作为整数的代码，然后尝试将其作为指针用于稍后将被捕获并阻止执行。 （Java语言不允许指针运算，所以你不能编写Java代码来完成我们刚刚描述的内容，但是，没有什么能够阻止某个人使用hex编辑器自己编写破坏性的字节代码，甚至build立一个Java字节代码汇编程序。）通常不可能在执行之前分析程序的机器代码，并确定它是否有什么不好。 像编写自我修改代码这样的技巧意味着恶意的操作可能直到后来才会存在。 但是Java字节码是为这种validation而devise的：它没有恶意程序员用来隐藏攻击的指令。
大小 ：在微处理器世界中，RISC通常优于CISC。 最好有一个小的指令集，并使用许多快速指令来完成一项工作，而不是将许多复杂的操作作为单个指令来实现。 RISCdevise需要更less的门芯片来实现他们的指令，为pipe道和其他技术提供更多的空间来使每条指令更快。 但在翻译中，这些都不重要。 如果你想根据case子句的数量来实现switch语句的一个单一的指令，那么没有理由不这样做。 事实上，一个复杂的指令集对于一个基于networking的语言来说是一个优势：这意味着同一个程序将会更小（更less复杂性的指令），这意味着更less的时间通过我们的速度限制networking传输。
所以当考虑字节码与本地时，考虑你想在可移植性，安全性，大小和执行速度之间做出哪些折衷。 如果速度是唯一重要的因素，那就去当地。 如果其他人更重要，请使用字节码。
我还要补充一点，为每个发行版维护一系列操作系统和基于体系结构的编译相同的代码库会变得非常繁琐。 在多个平台上使用相同的Java字节码并使之“正常工作”是巨大的胜利。
基本上任何程序的性能都会提高，如果它被编译，执行分析，结果反馈到编译器第二遍。 实际使用的代码path将被更积极地优化，循环展开到正确的程度，并且热指令path被安排为最大化I $命中。
所有的好东西，但它几乎从来没有完成，因为它是经过这么多的步骤来build立一个二进制的烦人。
在将代码编译为本地代码之前，先运行字节码的好处是：分析信息自动可用。 即时编译之后的结果是针对程序正在处理的特定数据的高度优化的本机代码。
能够运行字节码也可以实现比静态编译器可以安全使用的更积极的本地优化。 例如，如果一个函数的某个参数被注意到始终为NULL，那么对于该参数的所有处理可以简单地从本机代码中省略。 将在函数序言中对参数进行一个简短的有效性检查，如果该参数不是NULL，虚拟机将中止返回字节码并再次开始分析。
字节码创build了一个额外的间接级别。
这种额外的间接方式的优点是：
- 平台独立
- 可以创build任意数量的编程语言（语法）并将它们编译成相同的字节码。
- 可以轻松创build跨语言转换器
- x86，x64和IA64不再需要编译为单独的二进制文件。 只有正确的虚拟机需要安装。
- 每个操作系统只需要创build一个虚拟机，它将支持同一个程序。
- 只要及时编译，您就可以通过replace单个修补源文件来更新程序。 （非常有利于网页）
一些缺点：
- 性能
- 更易于反编译
所有好的答案，但我的热键已被击中 – 性能。
如果正在运行的代码花费所有的时间调用库/系统例程（文件操作，数据库操作，发送窗口消息），那么，如果它被打乱，那么它并不重要，因为大部分时间花费在等待那些较低层级别的操作来完成。
但是， 如果代码包含我们通常称之为“algorithm”的东西，那就必须快速，而且不要花太多的时间来调用函数，如果这些东西经常被用来成为性能问题，那么JIT就非常重要。
我想你只是回答了你自己的问题：平台独立。 独立于平台的字节码被生成并分发到其目标平台。 在执行之前，它可以在开始执行之前或者同时（ Just In Time ）快速编译为本机代码。 Java JVM和据推测.NET运行时工作在这个原则上。
这里： http : //slashdot.org/developers/02/01/31/013247.shtml
去看看Slashdot的怪人们要说些什么吧！ 有点过时，但非常好的评论！
理想情况下，你可以使用便携式字节码来编译本地代码。 我认为字节码解释器存在没有JIT的原因主要是因为本地代码编译增加了虚拟机的复杂性。 构build，debugging和维护附加组件需要时间。 不是每个人都有时间或资源来做出这个承诺。
次要因素是安全。 validation解释器不会崩溃比保证本地代码相同要容易得多。
三是performance。 生成机器码通常需要更多的时间，而不是仅仅运行一次的小块代码来解释字节码。
可移植性和平台独立性可能是字节码相对于本地代码最显着的优势。
