【简易JVM开发日志4】classDecode（3）解析方法，字段表属性

【总目录/源代码】：https://blog.youkuaiyun.com/qq_40636117/article/details/94383044

【上一篇】：https://blog.youkuaiyun.com/qq_40636117/article/details/94654292

 

解析完属性池后，下一步就是去实现jvm的RunTimeDataArea，也就是运行数据区了。不过要想让jvm运行起来，还得需要方法表里面的数据（比如方法Code属性的指令，局部变量）。

本来就因为解析方、字段表属性太麻烦打算绕过去，现在又绕回来了。

 

一、属性格式

上次解析属性池的时候，我们知道方法，字段表的格式是这样的：

u1:无符号1字节数据    u2:无符号2字节数据    u4:无符号4字节数据
 
//属性
typedef struct AttrInfo{
	u2 nameIndex;        //属性名称索引
	u4 len;              //属性内容数组大小
	u1* infos;           //属性内容数组
}AttrInfo;
 
 
字段/方法结构
//u1:无符号8位数据    u2:无符号16位数据    
typedef struct MemberInfo{
	u2 accessFlag;        //访问符
	u2 nameIndex;         //名称索引
	u2 desIndex;          //描述索引
	u2 attrCount;         //属性数组大小
	AttrInfo* attrInfos;  //属性数组（其中方法里面这里存放着方法体）
}MemberInfo;

其中方法，字段的属性就存放在attrInfos里面。这个attrInfos结构可不是像上面那么简单，就nameIndex，len和infos这三个属性，而是有如下种类。

1.Code：代码属性。存放方法的字节码指令，局部变量等信息，Code甚至还有自己的属性。是最复杂的一个属性

2.Exceptions：异常属性，存放异常信息（和Code中自带的异常属性不同）

3.Deprecate：废弃属性。记录类一些废弃的方法

4.Synthetic:表明是由编译器生成

5.sourceFile:用于记录生成这个Class文件的源码文件名称

6.ConstantValue:通知虚拟机自动为静态变量赋值(即标明static修饰的变量）

7.LineNumberTable:用于描述Java源码的行号与字节码行号之间的对应关系

8.LocalVariableTable:用于描述栈帧中局部变量表中的变量与Java源码中定义的变量之间的关系

9.Other:其他不明属性

把这些属性结构列举出来过于繁琐，如果想知道具体信息可以参见这个博客：https://www.cnblogs.com/timlong/p/8143839.html

由于这些属性结构第1,2个变量都是nameIndex（名称索引）和Len（属性占位大小）

所以我自定义了Other属性，其结构为

Other{
    u2 nameIndex;
    u4 len;
    u1 chars[len]
}

将前8种属性一一解析出来，将其他不明属性统统归类为Other，就发生jvm读取到不明属性时无法解析，影响后面的局面了。

 

二、如何存放属性

很明显，我们解析Code，Exceptions等属性后，是不能放在attrInfos里存放的。我听说C++里面有类也有继承，但不熟悉，不敢动不敢动。于是直接把这些属性作为MemberInfo的一部分。

MemberInfo里面属性个数用2字节存储，我也不敢保证每个属性最多1个（虽然测试了不少类，除了Other以外，没见过同一个属性个数超过2个的），那就当每个属性有多个好了。

对此，我们可以vector或数组存储相同类型的属性

前者的好处是功能强大，较为节省空间（没法确定某种属性个数，数组就得开得大），坏处就是运行时间慢

后者好处是运行时间块，但是较为浪费空间。

 

比较了很久，我选择了后者，即用数组。因为解析多个类发现，属性个数其实还是挺少的，也浪费不到哪里去。

出于尽可能节省空间，我用了如下方法：

int s=属性总个数

每个类型属性的个数=0

for(int i=0;i<s;++i){

    检测到某类型

        1.如果该类型属性个数=0：分配大小为s的数组

        2.将该类型存放到该类型的数组。s--

}
       

这种算法的特点不言而喻，属性类型越少越节省空间

好在大多数方法表就一个Code属性，最多再加上一个Exceptions属性，还是比较节省空间的。

 

三、识别属性类型

由之前文章知道，常量池常量类型由jvm固定死了。1就代表utf8，3就代表Integer。

但是属性类型却自由得多。属性有一个nameIndex变量（二字节），通过这个变量到常量池寻找出的数据就是这个属性的类型

比如某个属性的nameIndex=9，而常量池下标为9的常量是一个内容为“Code”的utf8类型数据，

那么这个属性名称就是Code。

看来要是你开心，也可以自己瞎几把定义一个属性了。

所以这也是为啥属性开始的两个属性为nameIndex（2字节，表示属性类型名称）和Len（4字节，表示属性字节数），

我要自定义Other这个结构体，存放杂七杂八的数据了。

不然真的无法解析下去啊。

 

由于utf8用unsigned char数组存放，要是想要识别属性类型的话，string现成的方法怕是用不了了，得把字符数组里面的内容一个个取出来判断，有点麻烦。

所以我用了一个简单粗暴的办法：将字符数组前4个元素相加。

这个方法有很大的风险，第一如果属性名的字符小于4，会出现不可预料的后果，第二如果两个属性字符数组前4个元素相加的值相同，就会产生混淆，解析直接出错。

第二个错误实际上也确实发生了。

属性SourceFile的前四个字符 'S'+'o'+'u'+'r' 相加的值为425

属性RuntimeVisibleAnnotations前四个字符 'R'+'u'+'n'+t'也是425

这给我敲响了一个警钟，不过我还是懒，就先这样吧。

 

四、解析属性

解析属性的工作比较庞杂，因为属性比较多，属性的内容也不少，一不小心写错一点点，直接GG

我先用Other存放所有的属性，然后逐步将Other出去，达到解析属性的目的。其中Code属性解析起来最烦。

解析属性没什么值得说的，佛系写了几天，终于完工了。

 

测试：