c++ cin.getline 的问题

Java代码的静态编译和动态编译中的问题是什么？

Java 应用程序的性能经常成为开发社区中的讨论热点。因为该语言的设计初衷是使用解释的方式支持应用程序的可移植性目标，早期 Java 运行时所提供的性能级别远低于 C 和 C++ 之类的编译语言。 尽管这些语言可以提供更高的性能，但是生成的代码只能在有限的几种系统上执行。在过去的十年中，Java 运行时供应商开发了一些复杂的动态编译器，通常称作即时（Just-in-time，JIT）编译器。 程序运行时，JIT 编译器选择将最频繁执行的方法编译成本地代码。运行时才进行本地代码编译而不是在程序运行前进行编译（用 C 或 C++ 编写的程序正好属于后一情形），保证了可移植性的需求。有些 J...全部

  Java 应用程序的性能经常成为开发社区中的讨论热点。因为该语言的设计初衷是使用解释的方式支持应用程序的可移植性目标，早期 Java 运行时所提供的性能级别远低于 C 和 C++ 之类的编译语言。
  尽管这些语言可以提供更高的性能，但是生成的代码只能在有限的几种系统上执行。在过去的十年中，Java 运行时供应商开发了一些复杂的动态编译器，通常称作即时（Just-in-time，JIT）编译器。
  程序运行时，JIT 编译器选择将最频繁执行的方法编译成本地代码。运行时才进行本地代码编译而不是在程序运行前进行编译（用 C 或 C++ 编写的程序正好属于后一情形），保证了可移植性的需求。有些 JIT 编译器甚至不使用解释程序就能编译所有的代码，但是这些编译器仍然通过在程序执行时进行一些操作来保持 Java 应用程序的可移植性。
   由于动态编译技术的多项改进，在很多应用程序中，现代的 JIT 编译器可以产生与 C 或 C++ 静态编译相当的应用程序性能。但是，仍然有很多软件开发人员认为 —— 基于经验或者传闻 —— 动态编译可能严重干扰程序操作，因为编译器必须与应用程序共享 CPU。
  一些开发人员强烈呼吁对 Java 代码进行静态编译，并且坚信那样可以解决性能问题。对于某些应用程序和执行环境而言，这种观点是正确的，静态编译可以极大地提高 Java 性能，或者说它是惟一的实用选择。
  但是，静态地编译 Java 应用程序在获得高性能的同时也带来了很多复杂性。一般的 Java 开发人员可能并没有充分地感受到 JIT 动态编译器的优点。 本文考察了 Java 语言静态编译和动态编译所涉及的一些问题，重点介绍了实时 (RT) 系统。
  简要描述了 Java 语言解释程序的操作原理并说明了现代 JIT 编译器执行本地代码编译的优缺点。介绍了 IBM 在 WebSphere Real Time 中发布的 AOT 编译技术和它的一些优缺点。
  然后比较了这两种编译策略并指出了几种比较适合使用 AOT 编译的应用程序领域和执行环境。要点在于这两种编译技术并不互斥：即使在使用这两种技术最为有效的各种应用程序中，它们也分别存在一些影响应用程序的优缺点。
   执行 Java 程序 Java 程序最初是通过 Java SDK 的 javac程序编译成本地的与平台无关的格式（类文件）。可将此格式看作 Java 平台，因为它定义了执行 Java 程序所需的所有信息。
  Java 程序执行引擎，也称作 Java 运行时环境（JRE），包含了为特定的本地平台实现 Java 平台的虚拟机。例如，基于 Linux 的 Intel x86 平台、Sun Solaris 平台和 AIX 操作系统上运行的 IBM System p 平台，每个平台都拥有一个 JRE。
  这些 JRE 实现实现了所有的本地支持，从而可以正确执行为 Java 平台编写的程序。 事实上，操作数堆栈的大小有实际限制，但是编程人员极少编写超出该限制的方法。JVM 提供了安全性检查，对那些创建出此类方法的编程人员进行通知。
   Java 平台程序表示的一个重要部分是字节码序列，它描述了 Java 类中每个方法所执行的操作。字节码使用一个理论上无限大的操作数堆栈来描述计算。这个基于堆栈的程序表示提供了平台无关性，因为它不依赖任何特定本地平台的 CPU 中可用寄存器的数目。
  可在操作数堆栈上执行的操作的定义都独立于所有本地处理器的指令集。Java 虚拟机（JVM）规范定义了这些字节码的执行（参见 参考资料）。执行 Java 程序时，用于任何特定本地平台的任何 JRE 都必须遵守 JVM 规范中列出的规则。
   因为基于堆栈的本地平台很少（Intel X87 浮点数协处理器是一个明显的例外），所以大多数本地平台不能直接执行 Java 字节码。为了解决这个问题，早期的 JRE 通过解释字节码来执行 Java 程序。
  即 JVM 在一个循环中重复操作： ◆获取待执行的下一个字节码； ◆解码； ◆从操作数堆栈获取所需的操作数； ◆按照 JVM 规范执行操作； ◆将结果写回堆栈。 这种方法的优点是其简单性：JRE 开发人员只需编写代码来处理每种字节码即可。
  并且因为用于描述操作的字节码少于 255 个，所以实现的成本比较低。当然，缺点是性能：这是一个早期造成很多人对 Java 平台不满的问题，尽管拥有很多其他优点。 解决与 C 或 C++ 之类的语言之间的性能差距意味着，使用不会牺牲可移植性的方式开发用于 Java 平台的本地代码编译。
   编译 Java 代码 尽管传闻中 Java 编程的 “一次编写，随处运行” 的口号可能并非在所有情况下都严格成立，但是对于大量的应用程序来说情况确实如此。另一方面，本地编译本质上是特定于平台的。
  那么 Java 平台如何在不牺牲平台无关性的情况下实现本地编译的性能？答案就是使用 JIT 编译器进行动态编译，这种方法已经使用了十年． 使用 JIT 编译器时，Java 程序按每次编译一个方法的形式进行编译，因为它们在本地处理器指令中执行以获得更高的性能。
  此过程将生成方法的一个内部表示，该表示与字节码不同但是其级别要高于目标处理器的本地指令。（IBM JIT 编译器使用一个表达式树序列表示方法的操作。）编译器执行一系列优化以提高质量和效率，最后执行一个代码生成步骤将优化后的内部表示转换成目标处理器的本地指令。
  生成的代码依赖运行时环境来执行一些活动，比如确保类型转换的合法性或者对不能在代码中直接执行的某些类型的对象进行分配。JIT 编译器操作的编译线程与应用程序线程是分开的，因此应用程序不需要等待编译的执行。
   还描述了用于观察执行程序行为的分析框架，通过周期性地对线程取样找出频繁执行的方法。该框架还为专门进行分析的方法提供了工具，用来存储程序的此次执行中可能不会改变的动态值。 因为这个 JIT 编译过程在程序执行时发生，所以能够保持平台无关性：发布的仍然是中立的 Java 平台代码。
  C 和 C++ 之类的语言缺乏这种优点，因为它们在程序执行前进行本地编译；发布给（本地平台）执行环境的是本地代码。收起