Java 程序执行Java 遵循一次编写、到处运行的理念，即设计一个面向Java 语言特性的虚拟机，并通过编译器将Java 程序转换成该虚拟机所能识别的指令序列，也称Java 字节码，使其可以在不同平台的虚拟机实现里运行。之所以取名字节码，也是因为Java 字节码指令的操作码（opcode）被固定为一个字节。C 程序编译而成的机器码就是一个个的字节：
0x00: 55 push rbp
0x01: 48 89 e5 mov rbp,rsp
0x04: 48 83 ec 10 sub rsp,0x10
0x08: 48 8d 3d 3b 00 00 00 lea rdi,[ rip+0x3b]
; 加载 "Hello, World!\n" 0x0f: c7 45 fc 00 00 00 00 mov DWORD PTR [ rbp-0x4] ,0x0
0x16: b0 00 mov al,0x0
0x18: e8 0d 00 00 00 call 0x12
; 调用 printf 0x1d: 31 c9 xor ecx,ecx
0x1f: 89 45 f8 mov DWORD PTR [ rbp-0x8] ,eax
0x22: 89 c8 mov eax,ecx
0x24: 48 83 c4 10 add rsp,0x10
0x28: 5d pop rbp
0x29: c3 ret
最左列是偏移，中间列是给虚拟机读的机器码，最右列是给人读的代码。
0x00: b2 00 02 getstatic java.lang.System.out
0x03: 12 03 ldc "Hello, World!" 0x05: b6 00 04 invokevirtual java.io.PrintStream.println
0x08: b1 return 从虚拟机视角来看，执行Java 代码首先需要将它编译而成的class 文件加载到Java 虚拟机中；加载后的Java 类会被存放于方法区（Method Area）中。实际运行时，虚拟机会执行方法区内的代码。Java 虚拟机会将栈细分为面向Java 方法的Java 方法栈，面向本地方法（用C++ 写的native 方法）的本地方法栈，以及存放各个线程执行位置的PC 寄存器。在运行过程中，每当调用进入一个Java 方法，Java 虚拟机会在当前线程的Java 方法栈中生成一个栈帧，用以存放局部变量以及字节码的操作数。这个栈帧的大小是提前计算好的，而且Java 虚拟机不要求栈帧在内存空间里连续分布。当退出当前执行的方法时，不管是正常返回还是异常返回，Java 虚拟机均会弹出当前线程的当前栈帧，并将之舍弃。
在字节码翻译的过程中，支持两种执行方式：解释执行与即时编译（Just-In-Time compilation，JIT） ，解释执行即逐条将字节码翻译成机器码并执行；即时编译即将一个方法中包含的所有字节码编译成机器码后再执行。即时编译建立在程序符合二八定律的假设上，也就是百分之二十的代码占据了百分之八十的计算资源。对于占据大部分的不常用的代码，我们无需耗费时间将其编译成机器码，而是采取解释执行的方式运行；另一方面，对于仅占据小部分的热点代码，我们则可以将其编译成机器码，以达到理想的运行速度。
理论上讲，即时编译后的Java 程序的执行效率，是可能超过C++ 程序的。这是因为与静态编译相比，即时编译拥有程序的运行时信息，并且能够根据这个信息做出相应的优化。举个例子，我们知道虚方法是用来实现面向对象语言多态性的。对于一个虚方法调用，尽管它有很多个目标方法，但在实际运行过程中它可能只调用其中的一个。这个信息便可以被即时编译器所利用，来规避虚方法调用的开销，从而达到比静态编译的C++ 程序更高的性能。
HotSpot 内置了多个即时编译器：C1、C2 和Graal ，以满足不同用户场景的需要。C1 又叫做Client 编译器，面向的是对启动性能有要求的客户端GUI 程序，采用的优化手段相对简单，因此编译时间较短。C2 又叫做Server 编译器，面向的是对峰值性能有要求的服务器端程序，采用的优化手段相对复杂，因此编译时间较长，但同时生成代码的执行效率较高。从Java 7 开始，HotSpot 默认采用分层编译的方式：热点方法首先会被C1 编译，而后热点方法中的热点会进一步被C2 编译。
JVM 运行时在 java -version 命令中，我们能够了解当前的JVM 类型与工作模式：
第三行的输出中可以看到：JVM 的名字(HotSpot) 、类型(Client) 和build ID(24.79-b02) 。除此之外，我们还知道JVM 以混合模式(mixed mode) 在运行，这是HotSpot 默认的运行模式，意味着JVM 在运行时可以动态的把字节码编译为本地代码。我们也可以看到类数据共享(class data sharing) 是开启( 即第三行最后的sharing) 的。类数据共享(class data sharing) 是一种在只读缓存( 在jsa 文件中， ”Java Shared Archive”) 中存储JRE 的系统类，被所有Java 进程的类加载器用来当做共享资源，它可能在经常从jar 文档中读所有的类数据的情况下显示出性能优势。
-Xcomp 代表编译模式(compiled mode) (-Xint) 正好相反，JVM 在第一次使用时会把所有的字节码编译成本地代码 ，从而带来最大程度的优化。这听起来不错，因为这完全绕开了缓慢的解释器。然而，很多应用在使用-Xcomp 也会有一些性能损失，但是这比使用-Xint 损失的少，原因是-Xcomp 没有让JVM 启用JIT 编译器的全部功能。因此在上图中，我们并没有看到-Xcomp 比-Xmixed 快多少。
-Xmixed 代表混合模式(mixed mode) JVM 的默认工作模式。它会同时使用编译模式和解释模式。** 对于字节码中多次被调用的部分，JVM 会将其编译成本地代码以提高执行效率；而被调用很少( 甚至只有一次) 的方法在解释模式下会继续执行，从而减少编译和优化成本。**JIT 编译器在运行时创建方法使用文件，然后一步一步的优化每一个方法，有时候会主动的优化应用的行为。这些优化技术，比如积极的分支预测(optimistic branch prediction) ，如果不先分析应用就不能有效的使用。这样将频繁调用的部分提取出来，编译成本地代码，也就是在应用中构建某种热点(** 即HotSpot ，** 这也是HotSpot JVM 名字的由来 ) 。** 使用混合模式可以获得最好的执行效率** 。
那么，Client JVM 和Server JVM 到底在哪些方面不同呢？当虚拟机运行在-client 模式的时候, 使用的是一个代号为C1 的轻量级编译器, 而-server 模式启动的虚拟机采用相对重量级, 代号为C2 的编译器. C2 比C1 编译器编译的相对彻底，服务起来之后, 性能更高。-Server VM 启动时，速度较慢，但是一旦运行起来后，性能将会有很大的提升。
很明显，Client VM 的编译器没有像Server VM 一样执行许多复杂的优化算法，因此，它在分析和编译代码片段的时候更快。而Server VM 则包含了一个高级的编译器，该编译器支持许多和在C++ 编译器上执行的一样的优化，同时还包括许多传统的编译器无法实现的优化。
从J2SE 5.0 开始，当一个应用启动的时候，加载器会尝试去检测应用是否运行在 “server-class” 的机器上，如果是，则使用Java HotSpot Server Virtual Machine (server VM) 而不是Java HotSpot Client Virtual Machine (client VM) 。这样做的目的是提高执行效率，即使没有为应用显式配置VM 。下面这张图展示了各个平台的默认的JVM( 注意：—代表不提供该平台的JVM ) ：
