当 JVM 执行 Java 应用程序时，操作系统的作用是什么？为什么我们需要操作系统？答案

【问题标题】：What is the role of the OS when JVM executes a Java application? And why do we need the OS?当 JVM 执行 Java 应用程序时，操作系统的作用是什么？为什么我们需要操作系统？
【发布时间】：2012-02-06 04:42:58
【问题描述】：

我在互联网上做了一些阅读，有人说 Java 应用程序是由 Java 虚拟机 (JVM) 执行的。 “执行”这个词让我有点困惑。据我所知，操作系统可以执行非 Java 应用程序（即：用 C、C++... 编写）。在较低级别，这意味着操作系统将二进制程序加载到内存中，然后指示 CPU 执行内存中的指令。

那么现在有了 JVM，会发生什么？据我所知，JVM（包含运行时环境）将首先由操作系统调用。从那时起，JVM 将为应用程序生成一个（或多个）线程。我想知道操作系统的作用是否会再发挥作用？在我看来，JVM 已经“绕过”了操作系统并直接指示 CPU 执行应用程序。如果是这样，我们为什么需要操作系统？

再进一步，JVM 将使用其 JIT 将应用程序的字节码编译成机器码，然后执行这些机器码。既然已经是机器码了，还需要JVM吗？因为操作系统可以代替 JVM 来指示 CPU 执行这些机器代码。我在这里有什么错误吗？

我想从这里的人那里学到更多。如果我错了，请纠正我。非常感谢！

【问题讨论】：

不要忘记，即使所有内容都经过 JIT 处理，您仍然需要 JVM，因为 JVM 会清理内存并压缩堆等等。

标签： java operating-system jvm cpu

【解决方案1】：

我们需要操作系统来处理 C 或 C++ 程序的所有功能。默认情况下，JVM 会做更多的事情，但它不会取代操作系统所做的任何事情。唯一的区别可能是有时你有Your Code [调用] JVM [调用] OS，或者使用编译后的代码你可以有Your Code [调用] OS

类似地，在 C++ 中，您可能有 Your Code [调用] Boost [调用] OS。

当您的程序以本机代码运行时，它不需要 JVM。这很好，因为 JVM 知道何时“退后”并让应用程序运行。但是，并非所有程序都会在应用程序的剩余生命周期内编译为本机代码，因此您仍然需要它。

可以通过 JNI 使用内核旁路设备/驱动程序，但 Java 不直接支持此类功能。

【讨论】：

“但是，并非所有程序都会在应用程序的剩余生命周期内编译为本机代码，因此您仍然需要它。” ~ 如果程序没有编译为本机代码，它会如何执行？我认为在内部，JVM（使用 JIT 或非 JIT）必须将字节码转换为本机代码，以便 CPU 能够理解并执行它。对吗？
在方法被编译为本机代码之前，它在解释器模式下运行。这使用本机代码指令，但不会生成本机代码来执行此操作。编码的方法可以调用或返回不是由 JIT 编译的代码。如果任何假设结果无效，则可以对经过优化的方法进行反优化。
在解释器模式下运行是什么意思？它不生成本机代码是什么意思？你能给我一个例子吗？非常感谢您热心回答我的问题。
en.wikipedia.org/wiki/Interpreter_%28computing%29 乐于助人。将代码编译为本机代码需要更长的时间，如果不经常调用（大多数代码只调用一次或根本不调用），则不值得付出额外的努力。

【解决方案2】：

在我看来，JVM 已经“绕过”了操作系统并直接指示 CPU 执行应用程序。如果是这样，为什么我们需要操作系统？

所有 C/C++ 二进制文件（不仅仅是 JVM）都直接在 CPU 上运行。运行后，这些程序可以调用操作系统提供的更多机器代码来执行有用的操作，例如读取文件、启动线程或使用网络。

JVM 将 Java 程序转换为在 CPU 上运行的指令。然而，在幕后，Java 的线程、文件 i/o 和网络套接字（仅举几例）都包含调用操作系统为线程/文件/等提供的代码的指令。这是您仍然需要操作系统的原因之一。

既然已经是机器码了，还需要JVM吗？

JVM 提供了 JIT 编译器无法提供的功能。归根结底，JVM 只是在运行大量机器代码，但并非所有机器代码都来自 JIT（或解释器）。例如，其中一些机器代码会进行垃圾收集。这就是你需要 JVM 的原因。

【讨论】：

【解决方案3】：

底层基础 O/S 仍然必须为 JVM 做几乎所有的事情，尤其是：

输入/输出
内存管理
创建线程（如果使用本机线程）
分时 - 即允许多个进程运行

还有更多！

【讨论】：

【解决方案4】：

好吧，我想保持简单。你是如何在 ZX Spectrum 中编码的，那是在过去，当你真的不使用操作系统时（甚至在 DOS 时代之前，在 PC 时代之前）。您编写代码，并且必须管理所有代码。在很多情况下没有编译器，所以你的程序被解释了。

接下来，人们意识到操作系统很棒，程序变得更简单了。此外，编译器的使用范围更广。例如，我在谈论 C++。在这些程序中，如果您需要调用某些操作系统功能，您可以添加所需的库并进行调用。现在，您的程序依赖于操作系统的缺点之一是，另一个问题是您的程序在某些固定版本中包含 OS DLL。如果同一台上的另一个程序需要不同版本的 DLL，那你就有麻烦了。

在 JVM 历史的早期，没有使用 JIT 编译器。因此，您的程序以解释模式运行。您的应用程序不再需要直接调用操作系统，而是使用 JVM 来满足它的所有需求。 JVM 将一些应用程序调用重定向到操作系统。将 JVM 视为中介。 JVM 的最佳特性之一，它具有通用性。你不需要坚持特定的操作系统（实际上你需要做一些小的调整，当你的程序“偶尔”在某些特定的操作系统中工作时你不坚持 Java 要求，例如你使用 C： \ 用于线程调度程序的文件或假设在当前操作系统上碰巧是真的，但通常不保证 JVM 是真的）。 JVM 的程序员开发了这样的 API，一方面可以方便 Java 开发人员使用，另一方面可以映射到任何 OS 系统调用。

JVM 为您提供了更多对操作系统的简单包装。例如，它有自己的内存模型（线程同步），它自己有几个星期的受赠者（它在 JDK 1.5 中被完全修改，因为它被破坏了）。它也有垃圾收集，它将变量初始化为空值（int i；我将被初始化为 0）。也就是说，JVM 除了作为 OS 的主持人之外，还充当您自己的应用程序的帮助代码。

在某些时候添加了 JIT。添加它是为了减少 JVM 创建的开销。当一些假设成立时，通常在代码执行一次之后，命令解释可以编译为机器码（我跳过字节码阶段）。这是优化，我不知道你可以在什么情况下受到影响。

在 JDK 1.6 中添加了另一个优化。现在，在某些情况下，某些对象可以在堆栈上分配，而不是在堆上。我不知道，可能它有一些副作用，但它是 JVM 可以为你做什么的一个例子。

还有我的最后一句话。当您编译您的代码时，真正发生的情况是，检查您的程序在语法上是否正确，然后生成它字节码（.class 文件）。 Java 语言使用现有字节码的子集（这就是 AOP 的实现方式，使用不属于 Java 语言的现有字节码）。当 java 程序被执行时，这些字节码被解释，它们被即时翻译成机器指令。如果 JIT 开启，则某些执行行可以编译为机器语言并重复使用，而不是即时解释。

【讨论】：

【解决方案5】：

既然已经是机器码了，还需要JVM吗？ 编译的java程序不是机器代码。 [javac] 将 [.java] 文件编译成字节码 [.class] 文件。然后将这些字节码提供给 JRE [Java Run-time Environment]。现在 java 解释器开始工作，将字节码解释为在 CPU 上运行的本机机器代码。

【讨论】：

【解决方案6】：

我们知道操作系统不会执行它为处理器提供执行环境的任何程序，如果我们谈论环境它分配内存加载文件向处理器提供指令，管理地址
处理器的加载数据方法的工作只是执行程序这件事发生在 c 或任何过程编程语言中，如果我们看到操作系统在操作系统的这种开销中扮演非常重要的角色因为如果我们用 C 语言编写一个简单的小程序，比如 Hello World，它只包含一个 Main 函数，编译它时会生成多个函数的 .exe 文件，这些函数取自 Library 函数，所以通过 OS 管理所有东西是一项繁琐的工作，所以在 JVM 中在这里给 OS 提供了救济，OS 的工作只是为了将 JVM 从硬盘加载到 RAM 并使 jvm 执行并为 JVM 分配空间来执行 java 程序在这里内存分配，从硬盘加载字节码文件，地址管理，内存分配和解除分配由 JVM 自己完成，所以操作系统是免费的，它可以做其他工作。jvm 根据操作系统为执行 java 程序提供的内容分配或释放内存。

如果我们谈论 Execution JVM Contains Interpreter 以及 JIT 编译器，它在方法执行后将字节码转换为所需函数的机器码该方法的可执行代码被破坏，这就是为什么我们可以说 java 确实有 .EXE 文件

【讨论】：

请标点符号，重新大写，并分段这个难以辨认的混乱。