上一篇文章讲述了 Clojure 编译器工作的整体流程，主要涉及 LispReader 与 Compiler 这两个类，而且指出编译器并没有把 Clojure 转为 相应的 Java 代码，而是直接使用 ASM 生成可运行在 JVM 中的 bytecode。本文不会讲解 ASM 的使用细节，而主要讨论 Clojure 编译成的 bytecode 如何实现动态运行时以及为什么 Clojure 程序启动慢，这会涉及到 JVM 的类加载机制。
JVM 设计之初只是为 Java 语言考虑，所以最基本的概念是 class，除了八种基本类型，其他都是对象。Clojure 作为一本函数式编程语言，最基本的概念是函数，没有类的概念，那么 Clojure 代码生成以类为主的 bytecode 呢？
一种直观的想法是，每个命名空间（namespace）是一个类，命名空间里的函数相当于类的成员函数。但仔细想想会有如下问题：
上述问题 2 就要求必须将函数编译成一个类。根据 Clojure 官方文档 ，对应关系是这样的：
__init gen-class 生成固定名字的类，方便与 Java 交互 defrecord 、 deftype 生成同名的类， proxy 、 reify 生成匿名的类 需要声明一点的是，只有在 AOT 编译时，Clojure 会在本地生成 .class 文件，其他情况下生成的类是在内存中的。
明确了 Clojure 类生成规则，下面介绍 Clojure 是如何实现动态运行时。这一问题将分为 AOT 编译与 DynamicClassLoader 类的实现两部分。
$ cat src/how_clojure_work/core.clj (ns how-clojure-work.core) (defn -main [& _] (println "Hello, World!"))
使用 lein compile 编译这个文件，会在 *compile-path* 指定的文件夹（一般是项目的 target ）下生成如下文件：
$ ls target/classes/how_clojure_work/ core$fn__38.class core$loading__5569__auto____36.class core$main.class core__init.class
core$main.class 与 core__init.class 分别表示原文件的 main 函数与命名空间加载类，那么剩下两个类是从那里来的呢？
我们知道 Clojure 里面很多“函数”其实是用宏实现的，宏在编译时会进行展开，生成新代码，上面的 ns 、 defn 都是宏，展开后（在 Cider + Emacs 开发环境下， C-c M-m ）可得
(do
(in-ns'how-clojure-work.core)
((fn*
loading__5569__auto__
([]
(.clojure.lang.Var
(clojure.core/pushThreadBindings
{clojure.lang.Compiler/LOADER
(.(.loading__5569__auto__ getClass)getClassLoader)}))
(try
(refer'clojure.core)
(finally
(.clojure.lang.Var(clojure.core/popThreadBindings)))))))
(if(.'how-clojure-work.core equals 'clojure.core)
nil
(do
(.clojure.lang.LockingTransaction
(clojure.core/runInTransaction
(fn*
([]
(commute
(deref#'clojure.core/*loaded-libs*)
conj
'how-clojure-work.core)))))
nil)))
(defmain(fn*([& _](println"Hello, World!"))))
可以看到， ns 展开后的代码里面包含了两个匿名函数，对应本地上剩余的两个文件。下面依次分析这四个 class 文件
$ javap core__init.class
public classhow_clojure_work.core__init{
public static final clojure.lang.Var const__0;
public static final clojure.lang.AFn const__1;
public static final clojure.lang.AFn const__2;
public static final clojure.lang.Var const__3;
public static final clojure.lang.AFn const__11;
public static void load();
public static void __init0();
public static {};
}
可以看到，命名空间加载类里面有一些 Var 与 AFn 变量，可以认为一个 Var 对应一个 AFn 。使用 Intellj 或 JD 打开这个类文件，首先查看静态代码快
static {
__init0();
Compiler.pushNSandLoader(RT.classForName("how_clojure_work.core__init").getClassLoader());
try {
load();
} catch (Throwable var1) {
Var.popThreadBindings();
throw var1;
}
Var.popThreadBindings();
}
这里面会先调用 __init0 ，先看它的实现：
public static void __init0() {
const__0 = (Var)RT.var("clojure.core", "in-ns");
const__1 = (AFn)Symbol.intern((String)null, "how-clojure-work.core");
const__2 = (AFn)Symbol.intern((String)null, "clojure.core");
const__3 = (Var)RT.var("how-clojure-work.core", "main");
const__11 = (AFn)RT.map(new Object[] {
RT.keyword((String)null, "arglists"), PersistentList.create(Arrays.asList(new Object[] {
Tuple.create(Symbol.intern((String)null, "&"),
Symbol.intern((String)null, "_"))
})),
RT.keyword((String)null, "line"), Integer.valueOf(3),
RT.keyword((String)null, "column"), Integer.valueOf(1),
RT.keyword((String)null, "file"), "how_clojure_work/core.clj"
});
}
RT 是 Clojure runtime 的实现，在 __init0 里面会对命名空间里面出现的 var 进行赋值。
接下来是 pushNSandLoader （内部用 pushThreadBindings 实现），它与后面的 popThreadBindings 形成一个 binding，功能等价下面的代码：
(binding[clojure.core/*ns* nil
clojure.core/*fn-loader* RT.classForName("how_clojure_work.core__init").getClassLoader()
clojure.core/*read-eval true]
(load))
接着查看 load 的实现：
public static void load() {
// 调用 in-ns，传入参数 how-clojure-work.core
((IFn)const__0.getRawRoot()).invoke(const__1);
// 执行 loading__5569__auto____36，功能等价于 (refer clojure.core)
((IFn)(new loading__5569__auto____36())).invoke();
Object var10002;
// 如果当前的命名空间不是 clojure.core 那么会在一个 LockingTransaction 里执行 fn__38
// 功能等价与(commute (deref #'clojure.core/*loaded-libs*) conj 'how-clojure-work.core)
if(((Symbol)const__1).equals(const__2)) {
var10002 = null;
} else {
LockingTransaction.runInTransaction((Callable)(new fn__38()));
var10002 = null;
}
Var var10003 = const__3;
// 为 main 设置元信息，包括行号、列号等
const__3.setMeta((IPersistentMap)const__11);
var10003.bindRoot(new main());
}
loading5569auto____36
$ javap core\$loading__5569__auto____36.class
Compiled from "core.clj"
public final classhow_clojure_work.core$loading__5569__auto____36extendsclojure.lang.AFunction{
public static final clojure.lang.Var const__0;
public static final clojure.lang.AFn const__1;
public how_clojure_work.core$loading__5569__auto____36(); // 构造函数
public java.lang.Object invoke();
public static {};
}
与 core__init 类结构，包含一些 var 赋值与初始化函数，同时它还继承了 AFunction ，同名字就可以看出这是一个函数的实现。
// 首先是 var 赋值
public static final Var const__0 = (Var)RT.var("clojure.core", "refer");
public static final AFn const__1 = (AFn)Symbol.intern((String)null, "clojure.core");
// invoke 是方法调用时的入口函数
public Object invoke() {
Var.pushThreadBindings((Associative)RT.mapUniqueKeys(new Object[]{Compiler.LOADER, ((Class)this.getClass()).getClassLoader()}));
Object var1;
try {
var1 = ((IFn)const__0.getRawRoot()).invoke(const__1);
} finally {
Var.popThreadBindings();
}
return var1;
}
上面的 invoke 方法等价于
(binding[Compiler.LOADER(Class)this.getClass()).getClassLoader()] (refer'clojure.core))
fn__38 与 loading__5569__auto____36 类似， 这里不在赘述。
$ javap core\$main.class
Compiled from "core.clj"
public final classhow_clojure_work.core$mainextendsclojure.lang.RestFn{
public static final clojure.lang.Var const__0;
public how_clojure_work.core$main();
public static java.lang.Object invokeStatic(clojure.lang.ISeq);
public java.lang.Object doInvoke(java.lang.Object);
public int getRequiredArity();
public static {};
}
由于 main 函数的参数数量是可变的，所以它继承了 RestFn ，除了 var 赋值外，重要的是以下两个函数：
public static Object invokeStatic(ISeq _) {
// const__0 = (Var)RT.var("clojure.core", "println");
return ((IFn)const__0.getRawRoot()).invoke("Hello, World!");
}
public Object doInvoke(Object var1) {
ISeq var10000 = (ISeq)var1;
var1 = null;
return invokeStatic(var10000);
}
通过上面的分析，我们可以发现，每个函数在被调用时，会去调用 getRawRoot 函数得到该函数的实现，这种重定向是 Clojure 实现动态运行时非常重要一措施。这种重定向在开发时非常方便，我们可以用 nrepl 连接到正在运行的服务，动态修改服务的行为，无需重启服务。但是在正式的生产环境，这种重定向对性能有影响，而且也没有重复定义函数的必要，所以可以在服务启动时指定 -Dclojure.compiler.direct-linking=true 来避免这类重定向，官方称为 Direct linking 。可以在定义 var 时指定 ^:redef 表示必须重定向。 ^:dynamic 的 var 永远采用重定向的方式确定最终值。
需要注意的是，var 重定义对那些已经 direct linking 的代码是透明的。
熟悉 JVM 类加载机制（不清楚的推荐我另一篇文章《JVM 的类初始化机制》）的都会知道，一个类只会被一个 ClassLoader 加载一次，仅仅有上面介绍的重定向机制是无法实现动态运行时的，还需要一个灵活的 ClassLoader，可以在 REPL 做如下实验：
user>(defn foo []1) #'user/foo user> (.. foo getClass getClassLoader) #object[clojure.lang.DynamicClassLoader 0x72d256 "clojure.lang.DynamicClassLoader@72d256"] user> (defn foo [] 1) #'user/foo user> (.. foo getClass getClassLoader) #object[clojure.lang.DynamicClassLoader 0x57e2068e "clojure.lang.DynamicClassLoader@57e2068e"]
可以看到，只要对一个函数进行了重定义，与之相关的 ClassLoader 随之也改变了。
下面来看看 DynamicClassLoader 的核心实现：
京公网安备 11010802041100号