从零开始学JVM系列（三）：玩弄五花八门的类加载器
前言
在上一篇中，从源码的角度分析了JVM的启动过程和类加载过程，从细节上也分析一个完整的类加载经历了哪几个步骤，以及各个步骤的细节，但是小伙伴们知道类加载器是从什么时候开始初始化的吗？类加载器加载类的方式是什么？类加载器的种类有哪些？各自的加载路径是什么？
带着这些问题，我用一篇文章的篇幅从以下五个环节全面的介绍类加载器：
- 类加载器初始化的时机
- 类加载器加载类的方式
- 介绍各种五花八门的类加载器
- 各种类加载器加载文件的路径
- 从源码的角度分析类加载器的初始化过程
第一个环节：类加载器初始化的时机
在上文中，我们有解析到JVM虚拟机启动，需要使用类加载器加载main方法所在的类，那么就可以判定在这之前类加载器就已经初始化完成，那我们就往前再退一步，看看在初始化JVM的时候有没有初始化类加载器：
初始化JVM
JavaMain方法 在jdk/src/java.base/share/native/libjli/java.c目录
int JNICALL JavaMain(void * _args) {
// 无用代码先忽略
......
// InitializeJVM 初始化JVM，给JavaVM和JNIEnv对象正确赋值，通过调用InvocationFunctions结构体下的CreateJavaVM()函数指针来实现
// 该指针在LoadJavaVM()函数中指向libjvm.so动态链接库中JNI_CreateJavaVM()函数
if (!InitializeJVM(&vm, &env, &ifn)) {
JLI_ReportErrorMessage(JVM_ERROR1);
exit(1);
}
// 无用代码，先忽略
......
}
InitializeJVM方法
static jboolean
InitializeJVM(JavaVM **pvm, JNIEnv **penv, InvocationFunctions *ifn)
{
// 无用代码，先忽略
......
r = ifn->CreateJavaVM(pvm, (void **)penv, &args); //通过ifn的函数指针 调用CreateJavaVM函数初始化JavaVM 和 JNIEnv
JLI_MemFree(options);
return r == JNI_OK;
}
CreateJavaVM方法
_JNI_IMPORT_OR_EXPORT_ jint JNICALL JNI_CreateJavaVM(JavaVM **vm, void **penv, void *args) {
//通过Atomic::xchg方法修改全局volatile变量vm_created为1，该变量默认为0，如果返回1则说明JVM已经创建完成或者创建中，返回JNI_EEXIST错误码，如果返回0则说明JVM未创建
if (Atomic::xchg(1, &vm_created) == 1) {
return JNI_EEXIST; // already created, or create attempt in progress
}
//通过Atomic::xchg方法修改全局volatile变量safe_to_recreate_vm为0，该变量默认为1，如果返回0则说明JVM已经在重新创建了，返回JNI_ERR错误码，如果返回1则说明JVM未创建
if (Atomic::xchg(0, &safe_to_recreate_vm) == 0) {
return JNI_ERR;
}
assert(vm_created == 1, "vm_created is true during the creation");
bool can_try_again = true;
//完成JVM的初始化，如果初始化过程中出现不可恢复的异常则can_try_again会被置为false
result = Threads::create_vm((JavaVMInitArgs*) args, &can_try_again);
// 无用代码，先忽略
......
}
Threads::create_vm方法
注意：这是初始化JVM最重要的一个方法，非常复杂，这里先省略部分代码，只关注类加载的部分，至于初始化JVM的HotSpot源码分析以后会单独开一个系列
jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) {
// 无用代码，先不关注
......
// 最终系统初始化，包括安全管理器和系统类加载器
call_initPhase3(CHECK_JNI_ERR);
// 完成SystemClassLoader的加载
SystemDictionary::compute_java_system_loader(THREAD);
if (HAS_PENDING_EXCEPTION) {
vm_exit_during_initialization(Handle(THREAD, PENDING_EXCEPTION));
}
// 无用代码，先不关注
.......
}
SystemDictionary::compute_java_system_loader方法
call_initPhase3方法初始化的是系统类加载器，Java层面的在compute_java_system_loader方法后就初始化完成了，
void SystemDictionary::compute_java_system_loader(TRAPS) {
KlassHandle system_klass(THREAD, WK_KLASS(ClassLoader_klass));
JavaValue result(T_OBJECT);
// 调用java.lang.ClassLoader类的getSystemClassLoader()方法
JavaCalls::call_static(&result, // 调用Java静态方法的返回值存储在result中
KlassHandle(THREAD, WK_KLASS(ClassLoader_klass)), // 调用的目标类为java.lang.ClassLoader
vmSymbols::getSystemClassLoader_name(), // 调用目标类中的目标方法为getSystemClassLoader
vmSymbols::void_classloader_signature(), // 调用目标方法的方法签名
CHECK);
// 获取调用getSystemClassLoader()方法的结果并保存到_java_system_loader属性中
_java_system_loader = (oop)result.get_jobject(); // 初始化属性为系统类加载器/应用类加载器/AppClassLoader
}
通过JavaClass::call_static方法调用java.lang.ClassLoader类的getSystemClassLoader方法
JavaClass::call_static方法非常重要，它是HotSpot调用Java静态方法的API
java.lang.ClassLoader类的getSystemClassLoader方法 注意：这是Java层面的代码
@CallerSensitive
public static ClassLoader getSystemClassLoader() {
initSystemClassLoader();
if (scl == null) {
return null;
}
// 无关紧要的代码，先不关注
......
return scl;
}
initSystemClassLoader方法
private static synchronized void initSystemClassLoader() {
if (!sclSet) {
if (scl != null)
throw new IllegalStateException("recursive invocation");
// 开始进行Java层面类加载器的初始化
sun.misc.Launcher l = sun.misc.Launcher.getLauncher();
// 无关紧要的代码，先不关注
......
}
}
我们重点来看下sun.misc.Launcher l = sun.misc.Launcher.getLauncher()这行代码，这行代码就是执行Java层面类加载器的入口
sun.misc.Launcher.getLauncher方法
发现sun.misc.Launcher.getLauncher直接返回launcher变量，这个变量又在Launcher类加载的最后一步初始化阶段已经创建好实例，所以我们去Launcher类的无参构造函数中去看看
new Launcher方法
public Launcher() {
Launcher.ExtClassLoader var1;
try {
// 初始化ExtClassLoader类加载器
var1 = Launcher.ExtClassLoader.getExtClassLoader();
} catch (IOException var10) {
throw new InternalError("Could not create extension class loader", var10);
}
try {
// 初始化AppClassLoader类加载器，并把loader变量指向成AppClassLoader类加载器
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {
throw new InternalError("Could not create application class loader", var9);
}
// 无关紧要的代码，先不关注
......
}
至此，我们类加载器的初始化动作就已经全部完成，总体上可以划分成如下两块：
- JVM层面：会创建一个系统的类加载器，就是下面要说的
Bootstrap ClassLoader - Java层面：会创建两个应用层面的类加载器
ExtClassLoader和AppClassLoader
我们的main方法所在的类就是用初始化出来的AppClassLoader类加载器加载的，目前，我们只需要知道存在着五花八门的类加载器就可以了，至于为什么会出现这么多类加载器，我会在下一篇文章中，借着双亲委派机制说明原因
第二个环节：类加载器加载类的方式
在第一个环节，我们看到了各种不同的类加载器以及它们初始化的时机，加载器的作用就是用来加载类的，在咱们平时的项目中，经常会用到各种第三方库包括各种框架、工具类、sdk等等，想象一下，如果在项目启动的时候，把这些类一股脑加载到JVM内存中，这不得把JVM给挤爆了，可能直接抛出OOM异常，所以JVM一定是用了一种特殊的方式避免这个问题，这个环节就是讲这个特殊的方式
加载类的方式：懒加载
懒体现在：JVM不会在项目启动的时候，就把程序涉及到的类全部一股脑加载，等到程序需要用到哪个类，就加载哪个类，就是按需加载，这样会大大节省了JVM内存空间，或者说细一点是大大节省了方法区的空间
证明JVM的加载是懒加载
public class LazyLoading {
static {
System.out.println("*********** loading TestLazyLoading class ***********");
}
public static void main(String[] args) {
new TestA();
System.out.println("*************** loading test ************");
TestB testB = null;
}
}
// 测试用的A类
class TestA {
static {
System.out.println("********* load TestA **********");
}
public TestA() {
System.out.println("*********** initial A **************");
}
}
// 测试用的B类
class TestB {
static {
System.out.println("********* load TestB **********");
}
public TestB() {
System.out.println("*********** initial B **************");
}
}
我们分析一下加载步骤：
-
第一步：根据上篇文章中的
HotSpot启动过程可知，HotSpot启动后首先会加载main方法所在的TestLazyLoading类，类加载的最后一步是初始化，其中就会执行静态代码块，所以首先会输出loading TestLazyLoading class -
第二步：加载完
TestLazyLoading类，就会执行main方法，会去new TestA()，所以肯定会加载TestA这么一个类，同样最后一步初始化中会去执行静态代码快，输出load TestA，接着再执行构造方法，输出initial A -
第三步：为了方便观察打印结果，我们直接输出loading test
-
第四步：定义了
TestB类，但是我们给它赋值的是空值，说明没用到TestB类，自然也不会打印load TestB和initial B
来看一下输出结果，也符合我们的分析，证明了类加载的方式是一个懒加载的方式
Connected to the target VM, address: '127.0.0.1:62820', transport: 'socket'
*********** loading TestLazyLoading class ***********
********* load TestA **********
*********** initial A **************
*************** loading test ************
Disconnected from the target VM, address: '127.0.0.1:62820', transport: 'socket'
第三个环节：介绍各种五花八门的类加载器
类加载器
类的加载是通过类加载器来实现的，在Java的世界中，不同路径下的类使用了不同的类加载器进行加载，Java自带的类加载器包括引导类加载器、扩展类加载器、应用程序类加载器
-
引导类加载器：由JVM虚拟机实现，负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar（字符集）等等
-
扩展类加载器
ExtClassLoader：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包 -
应用程序类加载器
AppClassLoader：负责加载classPath路径下的类包，主要加载的就是你自己写的类 -
自定义加载器：负责加载用户自定义路径下的类包
写一个测试类来看看我们的各种类加载器长什么样子：
public class JDKClassLoader {
public static void main(String[] args) {
System.out.println(String.class.getClassLoader());
System.out.println(com.sun.crypto.provider.DESKeyFactory.class.getClassLoader());
System.out.println(JDKClassLoader.class.getClassLoader());
}
}
- String类在Java中是属于核心类
- AESKeyGenerator这个类是在JRE的lib目录下的ext扩展目录中随便找的一个类
- JDKClassLoader是应用程序的类
Connected to the target VM, address: '127.0.0.1:63102', transport: 'socket'
null
sun.misc.Launcher$ExtClassLoader@1b0375b3
sun.misc.Launcher$AppClassLoader@18b4aac2
Disconnected from the target VM, address: '127.0.0.1:63102', transport: 'socket'
- 第二行和第三行输出内容的不同证明了不同路径下的类加载器不同
- 无论是ExtClassLoader还是AppClassLoader其实前缀都是sun.misc.Launcher这个类，进入Launcher源码中可以看到
ExtClassLoader和AppClassLoader都是Launcher类的内部类 - java的核心类库都是通过
引导类加载器加载，但是这个类加载器是用C++语言写的，生成的自然是C++的对象，而不是java对象，C++生成的对象，Java自然获取不到，返回的就是null
第四个环节：各种类加载器加载文件的路径
public class JDKClassLoader {
public static void main(String[] args) {
System.out.println("bootstrapLoader加载以下文件：");
URL[] urls = Launcher.getBootstrapClassPath().getURLs();
for (URL url : urls) {
System.out.println(url);
}
System.out.println();
System.out.println("extClassLoader加载以下文件：");
System.out.println(System.getProperty("java.ext.dirs"));
System.out.println();
System.out.println("appClassLoader加载以下文件：");
System.out.println(System.getProperty("java.class.path"));
}
}
运行一下看下输出结果：
bootstrapLoader加载以下文件：
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/resources.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/rt.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/sunrsasign.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/jsse.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/jce.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/charsets.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/jfr.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/classes
extClassLoader加载以下文件：
/Users/zhouxinze/Library/Java/Extensions:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/ext:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
appClassLoader加载以下文件：
/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/ext/jaccess.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/jfxswt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/lib/javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/lib/packager.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/lib/tools.jar:/Users/zhouxinze/IdeaProjects/java_basic/out/production/java_basic:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar:/Users/zhouxinze/Library/Caches/JetBrains/IntelliJIdea2020.3/captureAgent/debugger-agent.jar
分析输出结果：
bootStrapLoader读取的是jre目录下最核心的包extClassLoader读取的是lib\ext目录下的文件appClassLoader读取的是应用程序java文件的编译输出路径
第五个环节：类加载器的初始化过程
我们在第一个环节中分析过，JVM通过JavaClass::call_static方法调用java.lang.ClassLoader类的getSystemClassLoader方法初始化各种类加载器，Launcher类的实例在初始化过程中就会创建各种不同的java层面的类加载器，我们直接看源码：
java.lang.ClassLoader类的getSystemClassLoader方法
@CallerSensitive
public static ClassLoader getSystemClassLoader() {
// 初始化类加载器
initSystemClassLoader();
// 先忽略，不关注
......
}
java.lang.ClassLoader类的initSystemClassLoader方法
private static synchronized void initSystemClassLoader() {
if (!sclSet) {
if (scl != null)
throw new IllegalStateException("recursive invocation");
// Launcher类的实例在初始化过程中就会创建各种不同的java层面的类加载器
sun.misc.Launcher l = sun.misc.Launcher.getLauncher();
// 先忽略 不关注
......
}
Launcher类的getLauncher方法
// 发现在Launcher类加载的最后一步初始化的时候就已经创建
private static Launcher launcher = new Launcher();
public static Launcher getLauncher() {
return launcher;
}
Launcher类的new Launcher方法
public Launcher() {
Launcher.ExtClassLoader var1;
try {
// 创建ExtClassLoader类加载器实例
var1 = Launcher.ExtClassLoader.getExtClassLoader();
} catch (IOException var10) {
throw new InternalError("Could not create extension class loader", var10);
}
try {
// 创建AppClassLoader类加载器实例
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {
throw new InternalError("Could not create application class loader", var9);
}
// 先忽略，不关注
......
}
-
在无参构造函数中，通过
Launcher.ExtClassLoader.getExtClassLoader方法来创建ExtClassLoader类加载器实例 -
通过
Launcher.AppClassLoader.getAppClassLoader(ExtClassLoader extClassLoader)方法来创建AppClassLoader类加载器实例
初始化ExtClassLoader类加载器
Launcher.ExtClassLoader.getExtClassLoader方法
public static Launcher.ExtClassLoader getExtClassLoader() throws IOException {
if (instance == null) {
Class var0 = Launcher.ExtClassLoader.class;
// 加了类级别的锁，保证同步
synchronized(Launcher.ExtClassLoader.class) {
if (instance == null) {
instance = createExtClassLoader();
}
}
}
return instance;
}
- 实际上我们发现，创建ExtClassLoader实例就是new ExtClassLoader，当然前面还有各种安全控制检查AccessController.doPrivileged这里不再展开
private static Launcher.ExtClassLoader createExtClassLoader() throws IOException {
try {
// 做一些安全校验
return (Launcher.ExtClassLoader)AccessController.doPrivileged(new PrivilegedExceptionAction<Launcher.ExtClassLoader>() {
public Launcher.ExtClassLoader run() throws IOException {
// 先忽略，不关注
......
// 创建ExtClassLoader类加载器
return new Launcher.ExtClassLoader(var1);
}
});
} catch (PrivilegedActionException var1) {
throw (IOException)var1.getException();
}
}
初始化AppClassLoader类加载器
Launcher类的getAppClassLoader方法
public static ClassLoader getAppClassLoader(final ClassLoader var0) throws IOException {
final String var1 = System.getProperty("java.class.path");
final File[] var2 = var1 == null ? new File[0] : Launcher.getClassPath(var1);
return (ClassLoader)AccessController.doPrivileged(new PrivilegedAction<Launcher.AppClassLoader>() {
public Launcher.AppClassLoader run() {
URL[] var1x = var1 == null ? new URL[0] : Launcher.pathToURLs(var2);
return new Launcher.AppClassLoader(var1x, var0);
}
});
}
- 创建AppClassLoader实例就是new AppClassLoader，同样的，也有各种安全控制检查
- 调用Launcher.AppClassLoader.getAppClassLoader(ExtClassLoader extClassLoader) 的时候我们把扩展类加载器实例传进去了，我们跟随着这个参数来看看，发现它最终进入到了
ClassLoader类的构造方法中
// The parent class loader for delegation
// Note: VM hardcoded the offset of this field, thus all new fields
// must be added *after* it.
private final ClassLoader parent;
private ClassLoader(Void unused, ClassLoader parent) {
this.parent = parent;
if (ParallelLoaders.isRegistered(this.getClass())) {
parallelLockMap = new ConcurrentHashMap<>();
package2certs = new ConcurrentHashMap<>();
domains =
Collections.synchronizedSet(new HashSet<ProtectionDomain>());
assertionLock = new Object();
} else {
// no finer-grained lock; lock on the classloader instance
parallelLockMap = null;
package2certs = new Hashtable<>();
domains = new HashSet<>();
assertionLock = this;
}
}
- 传进去的ExtClassLoader extClassLoader赋值给了这个parent属性，这个parent属性在ClassLoader类，所有的类加载器都继承ClassLoader类，也就是说，所有的类加载器都有parent属性，同时也说明了AppClassLoader类的加载器有一个父类的类加载器属性是ExtClassLoader
衍生出来的问题
既然所有的类加载器都有一个parent属性，那么ExtClassLoader应该也有呀，所以我们来看看，ExtClassLoader的parent属性是什么？
我们追踪到ExtClassLoader的构造函数，发现他传入的父类类加载器是null，这是因为引导类的类加载器是用C++写的，无法通过Java层面来获取到，所以这里就传了null
花絮
还记得上面那个打印各个类加载器的读取文件路径的例子吗？
细心的小伙伴肯定会注意到，应用程序类加载器AppClassLoader打印的路径既有引导类加载器bootStrapLoader负责的读取路径，也有扩展类加载器extClassLoader负责的读取路径，也就是说它打印了不属于它加载的文件的路径？
这就涉及到了类加载中的双亲委派机制，这里这个知识点比较独立，所以在本篇中就不在讲述双亲委派机制，在下篇文章中，会好好讲讲这个双亲委派机制，这里大家先忍耐一下。
本文总结
好啦，以上就是这篇文章的全部内容了，我们一起来回忆一下：
- 第一步：从HotSpot源码的角度解析了类加载器初始化的时机
- 第二步：证明类加载器加载类的方式是懒加载
- 第三步：介绍了各种五花八门的类加载器，并证明不同路径下的类由不同的类加载器加载
- 第四步：打印了各种类加载器加载文件的路径
- 第五步：从JDK源码的角度分析类加载器的初始化过程，以及每个类都有的parent属性
关于类加载器的介绍就先到这，其实还剩下最后一个也是最重要的知识点：类加载器加载类的双亲委派机制，我把它单独放到下篇文章中，这里就先卖个关子
絮叨
最后，如果感到文章有哪里困惑的，请第一时间留下评论，如果各位看官觉得我有点东西的话 求点赞👍 求关注❤️ 求分享👥 对我来说真的非常有用！！！如果想获取电子书《深入理解Java虚拟机：JVM高级特性与最佳实践（第3版）周志明》，可以关注微信公众号Java百科全书，最后的最后，感谢各位看官的支持！！！
349
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
