浅析JVM方法解析、创建和链接

之前写了一篇文章《 你知道Java类是如何被加载的吗？ 》，分析了HotSpot是如何加载Java类的，干脆趁热打铁，再来分析下Hotspot又是如何解析、创建和链接类方法的。

Java类在编译后会被编译成 Class 文件。

先来看下 Class 文件的结构：

ClassFile {       ......       u2 methods_count;       method_info methods[methods_count];       ......}

• methods_count 记录了 Class 文件中一共有多少方法。

• methods 是个数组，包含 Class 文件的所有方法。

methods 的数组类型为 method_info。

每个 method_info 对应一个 Java 方法。

method_info {    u2 access_flags;    u2 name_index;    u2 descriptor_index;    u2 attributes_count;    attribute_info attributes[attributes_count];}

• access_flags 是方法的访问权限。

• name_index 是方法名在常量池中的索引。
• descriptor_index 是方法描述符在常量池中的索引。
• attributes_count 记录了方法一共有多少属性。

• attributes是个数组，包含了方法的所有属性。

attributes 中的每一项都是方法的一个属性，其中代表字节码的属性为 Code_attribute：

Code_attribute {    u2 attribute_name_index;     u4 attribute_length;    u2 max_stack;    u2 max_locals;    u4 code_length;    u1 code[code_length];    u2 exception_table_length;     {        u2 start_pc;        u2 end_pc;        u2 handler_pc;        u2 catch_type;    } exception_table[exception_table_length];    u2 attributes_count;    attribute_info attributes[attributes_count];}

• max_stack 表示当前方法操作数栈的最大深度。

• max_locals 表示当前方法局部变量的最大个数。

• code[code_length] 记录了方法中的字节码指令

总的来说，Class 文件中对方法的描述还是很简洁清晰的。

Class 文件相当于 Java 类的模板，JVM 在读取 Class 文件后，会根据这个模板，建立 Java 类在虚拟机中的模型。

在上篇文章《 你知道Java类是如何被加载的吗？ 》中，我提到了 ClassFileParser，它是HotSpot 加载类所需要的一员大将，通过名字我们就能猜出它的作用：类文件解析器。

还记得Class在JVM中对应的 InstanceKlass 是如何创建的吗？不记得话可以看下述代码回忆下。

 ClassFileParser parser(stream,                         name,                         loader_data,                         protection_domain,                         host_klass,                         cp_patches,                         ClassFileParser::BROADCAST, // publicity level                         CHECK_NULL);
  InstanceKlass* result = parser.create_instance_klass(old_stream != stream, CHECK_NULL);

上面这段代码主要是创建了一个ClassFileParser，并调用了其create_instance_klass（）来创建 InstanceKlass。但是对于Class文件的解析，是在 create_instance_klass（）之前就完成了的。当经过一系列初始化操作后，ClassFileParser 便在其构造函数的末尾，调用 parse_stream(stream, CHECK)，开始了 Class 文件的解析之旅。

在 parse_stream（）中，ClassFileParser 会对整个Class文件解析解析，包括常量池、字段、父类、接口等信息，当然也包括类方法。用来解析所有类方法的函数为：parse_methods（）。

void ClassFileParser::parse_methods(const ClassFileStream* const cfs,                                    bool is_interface,                                    AccessFlags* promoted_flags,                                    bool* has_final_method,                                    bool* declares_nonstatic_concrete_methods,                                    TRAPS) {  ......  const u2 length = cfs->get_u2_fast();  if (length == 0) {    _methods = Universe::the_empty_method_array();  } else {    _methods = MetadataFactory::new_array(_loader_data,                                                   length,                                                   NULL,                                                   CHECK);




    

    for (int index = 0; index < length; index++) {      Method* method = parse_method(cfs,                                    is_interface,                                    _cp,                                    promoted_flags,                                    CHECK);
      ......  }  ......}

ClassFileParser 对于 Class文件的解析是流式的，parse_methods（）先通过：

cfs->get_u2_fast() 拿到方法数量，接着便开始进行遍历，调用 parse_method（）依次解析每个类方法。

从Class文件中method_info的定义可知，method 基本上所有信息都存储在method_info中的attributes[] 数组中，所以对于method的解析，基本上也就是在遍历attributes[] 数组。

method_info 中的attributes[] 数组是用来存放方法的各个属性的，其中包括Code属性、Exception属性、MethodParameters属性、Synthetic属性。parse_method（）要做的主要工作，就是遍历attributes[] 数组，解析每个属性。

下面我们来便来各个击破，看看上面这些属性是如何被解析的。

（1）获取maxStacks、maxLocals和code length

if (_major_version == 45 && _minor_version <= 2) {  cfs->guarantee_more(4, CHECK_NULL);  max_stack = cfs->get_u1_fast();  max_locals = cfs->get_u1_fast();  code_length = cfs->get_u2_fast();} else {  cfs->guarantee_more(8, CHECK_NULL);  max_stack = cfs->get_u2_fast();  max_locals = cfs->get_u2_fast();  code_length = cfs->get_u4_fast();}

code_start = cfs->current();

exception_table_length = cfs->get_u2_fast();if (exception_table_length > 0) {  exception_table_start = parse_exception_table(cfs,                                                code_length,                                                exception_table_length,                                                CHECK_NULL);}

（4）解析Code属性中的属性表，如：

LineNumberTables、LocalVariableTables、LocalVariableTypeTables。主要是用于记录一些调试信息。

Exception 属性记录了方法可能抛出的异常。

checked_exceptions_start =            parse_checked_exceptions(cfs,                                     &checked_exceptions_length,                                     method_attribute_length,                                     CHECK_NULL);

MethodParameters 属性记录了方法的参数信息。

method_parameters_seen = true;method_parameters_length = cfs->get_u1_fast();const u2 real_length = (method_parameters_length * 4u) + 1u;if (method_attribute_length != real_length) {  classfile_parse_error(    "Invalid MethodParameters method attribute length %u in class file",    method_attribute_length, CHECK_NULL);}method_parameters_data = cfs->current();

Synthetic 属性表示成员是在编译期自动为Class生成，如内部类提供给外部类用来访问内部成员的 access（）方法。

access_flags.set_is_synthetic();

由上面的解析过程可知，ClassFileParser 主要就是按照Java虚拟机规范对Class文件结构的定义进行流式解析。

经过第三节的解析，ClassFileParser 已经从Class文件中获取到了方法的所有信息。接下来要做的，便是通过读取的信息，创建 Java 方法在 JVM 中的数据模型。

在HotSpot中，Java方法对应的数据结构为 Method，定义在 method.hpp 中：

class Method : public Metadata { ...... private:  // If you add a new field that points to any metaspace object, you  // must add this field to Method::metaspace_pointers_do().  ConstMethod*      _constMethod;                // Method read-only data.  MethodData*       _method_data;  MethodCounters*   _method_counters;  AccessFlags       _access_flags;               // Access flags  int               _vtable_index;     u2                _intrinsic_id;               // vmSymbols::intrinsic_id (0 == _none)  // Entry point for calling both from and to the interpreter.  address _i2i_entry;           // All-args-on-stack calling convention  // Entry point for calling from compiled code, to compiled code if it exists  // or else the interpreter.  volatile address _from_compiled_entry;        // Cache of: _code ? _code->entry_point() : _adapter->c2i_entry()  // The entry point for calling both from and to compiled code is  // "_code->entry_point()".  Because of tiered compilation and de-opt, this  // field can come and go.  It can transition from NULL to not-null at any  // time (whenever a compile completes).  It can transition from not-null to  // NULL only at safepoints (because of a de-opt).  CompiledMethod* volatile _code;                       // Points to the corresponding piece of native code  volatile address           _from_interpreted_entry; // Cache of _code ? _adapter->i2c_entry() : _i2i_entry  ......}

Method* const m = Method::allocate(_loader_data,                                   code_length,                                   access_flags,                                   &sizes,                                   ConstMethod::NORMAL,                                   CHECK_NULL);

m->set_constants(_cp);