徒手撸一个Mock框架（二）——如何创建final类的代理

在上一篇中，我们还留下一个很复杂的问题，即如何创建一个final类的代理。

对于一般的类来说，我们使用cglib来创建代理的时候，只需要调用setSuperClass便足够了。然而，如果将一个final类作为参数传递过去，那么会抛出一个IllegalArgumentException: Cannot subclass final class。

要解决这个问题，途径并不多。final作为一个非常关键的关键字，Java和Java虚拟机会在编译器和运行期都进行检查。以确保并不会有某个类是一个final类的子类。

好在，我们可以使用一些小伎俩。要知道的一点是，JVM只有在加载了类之后，才会知道这是一个final类。所以，我们要做的就是，在类完成加载之前，将一个final类修改为非final类。

没错，这就是要用到自定义类加载技术了。

ClassLoader

一般而言，如果要实现自定义的ClassLoader，只需要继承ClassLoader这个抽象类，而后重写findClass方法就可以。并且在findClass里面调用defineClass方法。

class MyClassLoader extends ClassLoader {
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // todo
        // byte[] bytes = new byte[];
        return defineClass(name, bytes, 0, bytes.length);
    }
}

实现ClassLoader并不难，难的是如何修改。

ASM

在Java里面，有一类工具叫做字节码操作工具。这一类工具常见于复杂框架中。

使用这一类工具一般有两个理由：

1. 一些信息只有在运行期才能拿到，例如生成各种代理的框架；
2. 另外一个理由就是，表达一些Java语言无法表达的语义。常见于各种基于JVM语言的编译工具里面；

这一次我们使用ASM工具。ASM和其余的诸如Javaassis, BCEL比起来，具有抽象层次高，功能完备的特点，美中不足的是，使用这个ASM工具要求对Java的字节码指令和.class文件格式有较深的理解。cglib也是一种字节码操作工具，但它是在ASM基础上的更高一级的抽象。

这一次我们只使用ASM里面的event based API。event based API的核心是实现一个类，并且继承ClassVisitor。

抽象类ClassVisitor其实并没有抽象方法。它里面的实现，就是按照读取的字节码流，原样返回。ClassVisitor是依照Visitor模式设计的，所以我们可以实现多个ClassVisitor以完成不同的功能。

这一次我们只需要实现一个就够了。这个实现的ClassVisitor非常简单，在读取.class文件的时候，将类的final标记去掉。

因此我们只需要重写：

这个方法有一大堆参数，不过我们只需要关注access参数。因为这个参数代表的就是一个类的“访问性”。通过阅读文档我们能知道，final是由16所代表的，二进制的话则是10000。常量org.objectweb.asm.Opcodes#ACC_FINAL恰好代表这个。

所以我们重写的地方很简单：

public class RemoveFinalFlagClassVisitor extends ClassVisitor {

    public RemoveFinalFlagClassVisitor(ClassVisitor cv) {
        super(Opcodes.ASM7, cv);
    }

    @Override
    public void visit(int version, int access, String name, String signature, String superName, String[] interfaces) {
        // we have the final flag
        if((access & Opcodes.ACC_FINAL) == Opcodes.ACC_FINAL) {
            //remove the final flag
            access = access ^ Opcodes.ACC_FINAL;
        }
        super.visit(version, access, name, signature, superName, interfaces);
    }
}

代码实际上很简单，只不过是用位运算了实现而已。

在调用super.visit的时候，我们就已经把final关键字去掉了。

ClassLoader的实现

这段代码也不难。ClassWriter自身也继承了ClassVisitor，所以实际上它和我们写的RemoveFinalFlagClassVisitor构成了一个Visitor链。

另外一个地方就是构造函数里面，我调用的是super(null)，这只是为了将类加载器的parent设置为null，从而避免在loadClass的类先被父加载器加载了——如果被父加载器加载，我们就无法去掉final了，除非这个类不在父加载器的classpath里面。

换句话来说，这种实现破坏了著名的双亲委托模型。

自己做的孽，含着泪也要顶住

于是我们会陷入另外一个问题，在双亲委托模型被破坏之后，我们的代码会出现一个很微妙的问题：

这个单测居然失败了，惊不惊喜，意不意外？？

而且失败原因不是assertNotNull断言失败，而是第20行失败了，异常是java.lang.ClassCastException!详细的信息是:

java.lang.ClassCastException: class cn.com.flycash.stupidmock.testobj.FinalObject cannot be cast to class cn.com.flycash.stupidmock.testobj.FinalObject (cn.com.flycash.stupidmock.testobj.FinalObject is in unnamed module of loader cn.com.flycash.stupidmock.classloader.StupidMockClassLoader @50de0926; cn.com.flycash.stupidmock.testobj.FinalObject is in unnamed module of loader 'app')

也就是，在类型转换的时候，虚拟机发现创建实例的类的加载器是我们自定义的StupidMockClassLoader，而要转换到的类型虽然也是FinalObject，然而却是使用AppClassLoader加载的。

我们可以在AppClassLoader#loadClass里面打上断点，可以清楚看到，在我们的加载器加载了一次FinalObject.class之后，AppClassLoader又加载了一次。

出现这个问题根源在于，从Java语言层面上来说，或者编译层面上来说，类的全限定名就代表了类的唯一性，而在虚拟机层面上，类加载器+类全限定名才是类的唯一性。

这种割裂，在开发各种框架的时候，会坑死人。

直接原因再说我在使用IDE运行测试的时候，FinalObject编译后的文件FinalObject.class出现在了AppClassLoader的classpath之下。

那么现在有两个问题：

1. 为什么JVM会触发第二次加载？毕竟按照理论上来说，我们自定义的类加载器已经加载到了这个类！
2. 怎么解决这个问题？

这一章要解决的问题是“如何创建final类的代理”，到这里也算是创建出来了，只是又引出来新的问题。

新的问题且随它去，下一篇我将解释其中的一个问题。