虚拟机（Virtual Machine)

JRE是由Java API和JVM组成的。JVM的主要作用是通过Class Loader来加载Java程序，并且按照Java API来执行加载的程序。

虚拟机是通过软件的方式来模拟实现的机器（比如说计算机），它可以像物理机一样运行程序。设计虚拟机的初衷是让Java能够通过它来实现WORA(Write Once Run Anywhere 一次编译，到处运行），尽管这个目标现在已经被大多数人忽略了。因此，JVM可以在不修改Java代码的情况下，在所有的硬件环境上运行Java字节码。

Java虚拟机的特点如下：

• 基于栈的虚拟机：Intel x86和ARM这两种最常见的计算机体系的机构都是基于寄存器的。不同的是，JVM是基于栈的。
• 符号引用：除了基本类型以外的数据（类和接口）都是通过符号来引用，而不是通过显式地使用内存地址来引用。
• 垃圾回收机制：类的实例都是通过用户代码进行创建，并且自动被垃圾回收机制进行回收。
• 通过对基本类型的清晰定义来保证平台独立性：传统的编程语言，例如C/C++，int类型的大小取决于不同的平台。JVM通过对基本类型的清晰定义来保证它的兼容性以及平台独立性。
• 网络字节码顺序：Java class文件用网络字节码顺序来进行存储:为了保证和小端的Intel x86架构以及大端的RISC系列的架构保持无关性，JVM使用用于网络传输的网络字节顺序，也就是大端。

虽然是Sun公司开发了Java，但是所有的开发商都可以开发并且提供遵循Java虚拟机规范的JVM。正是由于这个原因，使得Oracle HotSpot和IBM JVM等不同的JVM能够并存。Google的Android系统里的Dalvik VM也是一种JVM，虽然它并不遵循Java虚拟机规范。和基于栈的Java虚拟机不同，Dalvik VM是基于寄存器的架构，因此它的Java字节码也被转化成基于寄存器的指令集。

Java字节码（Java bytecode)

为了保证WORA，JVM使用Java字节码这种介于Java和机器语言之间的中间语言。字节码是部署Java代码的最小单位。

在解释Java字节码之前，我们先通过实例来简单了解它。这个案例是一个在开发环境出现的真实案例的总结。

现象

一个一直运行正常的应用突然无法运行了。在类库被更新之后，返回下面的错误。

Exception in thread
"main"
java.lang.NoSuchMethodError: com.nhn.user.UserAdmin.addUser(Ljava/lang/String;)V
    
at com.nhn.service.UserService.add(UserService.java:
14
)
    
at com.nhn.service.UserService.main(UserService.java:
19
)
应用的代码如下，而且它没有被改动过。
// UserService.java
…
public
void
add(String userName) {
    
admin.addUser(userName);
}
更新后的类库的源代码和原始的代码如下。
// UserAdmin.java - Updated library source code
…
public
User addUser(String userName) {
    
User user =
new
User(userName);
    
User prevUser = userMap.put(userName, user);
    
return
prevUser;
}
// UserAdmin.java - Original library source code
…
public
void
addUser(String userName) {
    
User user =
new
User(userName);
    
userMap.put(userName, user);
}

简而言之，之前没有返回值的addUser()被改修改成返回一个User类的实例的方法。不过，应用的代码没有做任何修改，因为它没有使用addUser()的返回值。

初一看，com.nhn.user.UserAdmin.addUser()方法似乎仍然存在，如果存在的话，那么怎么还会出现NoSuchMethodError的错误呢？

原因

上面问题的原因是在于应用的代码没有用新的类库来进行编译。换句话来说，应用代码似乎是调了正确的方法，只是没有使用它的返回值而已。不管怎样，编译后的class文件表明了这个方法是有返回值的。你可以从下面的错误信息里看到答案。

java.lang.NoSuchMethodError: com.nhn.user.UserAdmin.addUser(Ljava/lang/String;)V

NoSuchMethodError出现的原因是“com.nhn.user.UserAdmin.addUser(Ljava/lang/String;)V”方法找不到。注意一下”Ljava/lang/String；”和最后面的“V”。在Java字节码的表达式里，”L<classname>;”表示的是类的实例。这里表示addUser()方法有一个java/lang/String的对象作为参数。在这个类库里，参数没有被改变，所以它是正常的。最后面的“V”表示这个方法的返回值。在Java字节码的表达式里，”V”表示没有返回值（Void）。综上所述，上面的错误信息是表示有一个java.lang.String类型的参数，并且没有返回值的com.nhn.user.UserAdmin.addUser方法没有找到。

因为应用是用之前的类库编译的，所以返回值为空的方法被调用了。但是在修改后的类库里，返回值为空的方法不存在，并且添加了一个返回值为“Lcom/nhn/user/User”的方法。因此，就出现了NoSuchMethodError。

注：

这个错误出现的原因是因为开发者没有用新的类库来重新编译应用。不过，出现这种问题的大部分责任在于类库的提供者。这个public的方法本来没有返回值的，但是后来却被修改成返回User类的实例。很明显，方法的签名被修改了，这也表明了这个类库的后向兼容性被破坏了。因此，这个类库的提供者应该告知使用者这个方法已经被改变了。

我们再回到Java字节码上来。Java字节码是JVM很重要的部分。JVM是模拟执行Java字节码的一个模拟器。Java编译器不会直接把高级语言（例如C/C++）编写的代码直接转换成机器语言（CPU指令）；它会把开发者可以理解的Java语言转换成JVM能够理解的Java字节码。因为Java字节码本身是平台无关的，所以它可以在任何安装了JVM（确切地说，是相匹配的JRE）的硬件上执行，即使是在CPU和OS都不相同的平台上（在Windows PC上开发和编译的字节码可以不做任何修改就直接运行在Linux机器上）。编译后的代码的大小和源代码大小基本一致，这样就可以很容易地通过网络来传输和执行编译后的代码。

Java class文件是一种人很难去理解的二进文件。为了便于理解它，JVM提供者提供了javap，反汇编器。使用javap产生的结果是Java汇编语言。在上面的例子中，下面的Java汇编代码是通过javap -c对UserServiceadd()方法进行反汇编得到的。

public
void
add(java.lang.String);
  
Code:
   
0
:   aload_0
   
1
:   getfield        #
15
;
//Field admin:Lcom/nhn/user/UserAdmin;
   
4
:   aload_1
   
5
:   invokevirtual   #
23
;
//Method com/nhn/user/UserAdmin.addUser:(Ljava/lang/String;)V
   
8
:  
return

nvokeinterface:调用一个接口方法在这段Java汇编代码中，addUser()方法是在第四行的“5:invokevitual#23″进行调用的。这表示对应索引为23的方法会被调用。索引为23的方法的名称已经被javap给注解在旁边了。invokevirtual是Java字节码里调用方法的最基本的操作码。在Java字节码里，有四种操作码可以用来调用一个方法，分别是：invokeinterface，invokespecial，invokestatic以及invokevirtual。操作码的作用分别如下：

• invokespecial: 调用一个初始化方法，私有方法或者父类的方法
• invokestatic:调用静态方法
• invokevirtual:调用实例方法

Java字节码的指令集由操作码和操作数组成。类似invokevirtual这样的操作数需要2个字节的操作数。

用更新的类库来编译上面的应用代码，然后反编译它，将会得到下面的结果。

public
void
add(java.lang.String);
  
Code:
   
0
:   aload_0
   
1
:   getfield        #
15
;
//Field admin:Lcom/nhn/user/UserAdmin;
   
4
:   aload_1
   
5
:   invokevirtual   #
23
;
//Method com/nhn/user/UserAdmin.addUser:(Ljava/lang/String;)Lcom/nhn/user/User;
   
8
:   pop
   
9
:  
return
你会发现，对应索引为23的方法被替换成了一个返回值为”Lcom/nhn/user/User”的方法。

在上面的反汇编代码里，代码前面的数字代码什么呢？

它表示的是字节数。大概这就是为什么运行在JVM上面的代码成为Java“字节”码的原因。简而言之，Java字节码指令的操作码，例如aload_0，getfield和invokevirtual等，都是用一个字节的数字来表示的（aload_0=0x2a,getfield=0xb4,invokevirtual=0xb6)。由此可知Java字节码指令的操作码最多有256个。

aload_0和aload_1这样的指令不需要任何操作数。因此，aload_0指令的下一个字节是下一个指令的操作码。不过，getfield和invokevirtual指令需要2字节的操作数。因此，getfiled的下一条指令是跳过两个字节，写在第四个字节的位置上的。十六进制编译器里查看字节码的结果如下所示。

表一：Java字节码中的类型表达式在Java字节码里，类的实例用字母“L;”表示，void 用字母“V”表示。通过这种方式，其他的类型也有对应的表达式。下面的表格对此作了总结。

下面的表格给出了字节码表达式的几个实例。

表二：Java字节码表达式范例

想了解更多细节的话，参考《The java Virtual Machine Specification,第二版》中的“4.3 Descriptors”。想了解更多的Java字节码的指令的话，参考《The Java Virtual Machined Instruction Set》的“6.The Java Virtual Machine Instruction Set”

Class文件格式

在讲解Java class文件格式之前，我们先看看一个在Java Web应用中经常出现的问题。

现象

当我们编写完jsp代码，并且在Tomcat运行时，Jsp代码没有正常运行，而是出现了下面的错误。

Servlet.service()
for
servlet jsp threw exception org.apache.jasper.JasperException: Unable to compile
class
for
JSP Generated servlet error:
The code of method _jspService(HttpServletRequest, HttpServletResponse) is exceeding the
65535
bytes limit"

原因

在不同的Web服务器上，上面的错误信息可能会有点不同，不过有有一点肯定是相同的，它出现的原因是65535字节的限制。这个65535字节的限制是JVM规范里的限制，它规定了一个方法的大小不能超过65535字节。

下面我会更加详细地讲解这个65535字节限制的意义以及它出现的原因。

Java字节码里的分支和跳转指令分别是”goto”和”jsr”。

goto
[branchbyte1] [branchbyte2]
jsr [branchbyte1] [branchbyte2]
这两个指令都接收一个2字节的有符号的分支跳转偏移量做为操作数，因此偏移量最大只能达到65535。不过，为了支持更多的跳转，Java字节码提供了"goto_w"和"jsr_w"这两个可以接收4字节分支偏移的指令。
goto_w [branchbyte1] [branchbyte2] [branchbyte3] [branchbyte4]
jsr_w [branchbyte1] [branchbyte2] [branchbyte3] [branchbyte4]

有了这两个指令，索引超过65535的分支也是可用的。因此，Java方法的65535字节的限制就可以解除了。不过，由于Java class文件的更多的其他的限制，使得Java方法还是不能超过65535字节。

为了展示其他的限制，我会简单讲解一下class 文件的格式。

Java class文件的大致结构如下：

ClassFile {
    
u4 magic;
    
u2 minor_version;
    
u2 major_version;
    
u2 constant_pool_count;
    
cp_info constant_pool[constant_pool_count-
1
];
    
u2 access_flags;
    
u2 this_class;
    
u2 super_class;
    
u2 interfaces_count;
    
u2 interfaces[interfaces_count];
    
u2 fields_count;
    
field_info fields[fields_count];
    
u2 methods_count;
    
method_info methods[methods_count];
    
u2 attributes_count;
    
attribute_info attributes[attributes_count];}

上面的内容是来自《The Java Virtual Machine Specification,Second Edition》的4.1节“The ClassFile Structure”。

之前反汇编的UserService.class文件反汇编的结果的前16个字节在十六进制编辑器中如下所示：

ca fe ba be 00 00 00 32 00 28 07 00 02 01 00 1b

通过这些数值，我们可以来看看class文件的格式。

•  magic：class文件最开始的四个字节是魔数。它的值是用来标识Java class文件的。从上面的内容里可以看出，魔数 的值是0xCAFEBABE。简而言之，只有一个文件的起始4字节是0xCAFEBABE的时候，它才会被当作Java class文件来处理。
•   minor_version,major_version:接下来的四个字节表示的是class文件的版本。UserService.class文件里的是0x00000032，所以这个class文件的版本是50.0。JDK 1.6编译的class文件的版本是50.0，JDK 1.5编译出来的class文件的版本是49.0。JVM必须对低版本的class文件保持后向兼容性，也就是低版本的class文件可以运行在高版本的JVM上。不过，反过来就不行了，当一个高版本的class文件运行在低版本的JVM上时，会出现java.lang.UnsupportedClassVersionError的错误。
• constant_pool_count,constant_pool[]:在版本号之后，存放的是类的常量池。这里保存的信息将会放入运行时常量池(Runtime Constant Pool)中去，这个后面会讲解的。在加载一个class文件的时候，JVM会把常量池里的信息存放在方法区的运行时常量区里。UserService.class文件里的constant_pool_count的值是0x0028，这表示常量池里有39(40-1)个常量。
•   access_flags:这是表示一个类的描述符的标志；换句话说，它表示一个类是public,final还是abstract以及是不是接口的标志。
•  fields_count,fields[]:当前类的成员变量的数量以及成员变量的信息。成员变量的信息包含变量名，类型，修饰符以及变量在constant_pool里的索引。
•  methods_count,methods[]:当前类的方法数量以及方法的信息。方法的信息包含方法名，参数的数量和类型，返回值的类型，修饰符，以及方法在constant_pool里的索引，方法的可执行代码以及异常信息。
•  attributes_count,attributes[]:attribution_info结构包含不同种类的属性。field_info和method_info里都包含了attribute_info结构。

javap简要地给出了class文件的一个可读形式。当你用”java -verbose”命令来分析UserService.class时，会输出如下的内容：

Compiled from
"UserService.java"  
public
class
com.nhn.service.UserService
extends
java.lang.Object
  
SourceFile:
"UserService.java"
  
minor version:
0
  
major version:
50
  
Constant pool:
const
#
1
=
class       
#
2
;    
//  com/nhn/service/UserService
const
#
2
= Asciz        com/nhn/service/UserService;
const
#
3
=
class       
#
4
;    
//  java/lang/Object
const
#
4
= Asciz        java/lang/Object;
const
#
5
= Asciz        admin;
const
#
6
= Asciz        Lcom/nhn/user/UserAdmin;;
// … omitted - constant pool continued …  
{
// … omitted - method information …  
public
void
add(java.lang.String);
  
Code:
   
Stack=
2
, Locals=
2
, Args_size=
2
   
0
:   aload_0
   
1
:   getfield        #
15
;
//Field admin:Lcom/nhn/user/UserAdmin;
   
4
:   aload_1
   
5
:   invokevirtual   #
23
;
//Method com/nhn/user/UserAdmin.addUser:(Ljava/lang/String;)Lcom/nhn/user/User;
   
8
:   pop
   
9
:  
return 
LineNumberTable:
   
line
14
:
0
   
line
15
:
9 
LocalVariableTable:
   
Start  Length  Slot  Name   Signature
   
0     
10     
0   
this      
Lcom/nhn/service/UserService;
   
0     
10     
1   
userName       Ljava/lang/String;
// … Omitted - Other method information …
}

javap输出的内容太长，我这里只是提出了整个输出的一部分。整个的输出展示了constant_pool里的不同信息，以及方法的内容。

关于方法的65565字节大小的限制是和method_info struct相关的。method_info结构包含Code,LineNumberTable,以及LocalViriable attribute几个属性，这个在“javap -verbose”的输出里可以看到。Code属性里的LineNumberTable，LocalVariableTable以及exception_table的长度都是用一个固定的2字节来表示的。因此，方法的大小是不能超过LineNumberTable，LocalVariableTable以及exception_table的长度的，它们都是65535字节。

许多人都在抱怨方法的大小限制，而且在JVM规范里还说名了”这个长度以后有可能会是可扩展的“。不过，到现在为止，还没有为这个限制做出任何动作。从JVM规范里的把class文件里的内容直接拷贝到方法区这个特点来看，要想在保持后向兼容性的同时来扩展方法区的大小是非常困难的。

如果因为Java编译器的错误而导致class文件的错误，会怎么样呢？或者，因为网络传输的错误导致拷贝的class文件的损坏呢？

为了预防这种场景，Java的类装载器通过一个严格而且慎密的过程来校验class文件。在JVM规范里详细地讲解了这方面的内容。

注意

我们怎样能够判断JVM正确地执行了class文件校验的所有过程呢？我们怎么来判断不同提供商的不同JVM实现是符合JVM规范的呢？为了能够验证以上两点，Oracle提供了一个测试工具TCK(Technology Compatibility Kit)。这个TCK工具通过执行成千上万的测试用例来验证一个JVM是否符合规范，这些测试里面包含了各种非法的class文件。只有通过了TCK的测试的JVM才能称作JVM。

和TCK相似，有一个组织JCP(Java Community Process;http://jcp.org)负责Java规范以及新的Java技术规范。对于JCP而言，如果要完成一项Java规范请求(Java Specification Request, JSR)的话，需要具备规范文档，可参考的实现以及通过TCK测试。任何人如果想使用一项申请JSR的新技术的话，他要么使用RI提供许可的实现，要么自己实现一个并且保证通过TCK的测试。