A.ClassLoader没有层次关系；

B.所有类中的ClassLoader都是AppClassLoader;

C.通过Class.forName(StringclassName),能够动态加载一个类；

D.不同的ClassLoader加载同一个Class文件，所有的类是相同的。

解析：

A选项错误，ClassLoader 具备层次关系

B选项错误，ClassLoader 不止一种

D 选项错误，不同的类装载器分别创建的同一个类的字节码数据属于完全不同的对象，没有任何关联。

答案选C

题2：JVM 使用哪种字符表示（）

A.ASCII characters

B.Unincode characters

C.Cp1252

D.UTF-8

解析：JVM的设计者当初决定JVM中所有字符的表示形式时，是不允许使用各种编码方式的字符并存的，这是因为如果在内存中的Java字符可以以GB2312、UTF-16、BIG5等各种编码形式存在，那么对开发者来说，连进行最基本的字符串打印、连接等操作都会寸步难行。例如，一个GB2312的字符串后面连接UTF-8的字符串，那么连接后的最终结果应该是什么编码呢？选哪一个都没有道理。

  Java 开发者必须牢记：在Java 中字符只以一种形式存在，那就是Unicode(不选择任何特定的编码，直接使用它们在字符集中的编号，这是统一的唯一方法)。

  但“在Java中”到底是指哪里呢？是指在JVM中、在内存中、在你的代码里声明的每一char、String类型的变量中。例如，你在程序中这样写：

Char han=’永’

在内存的相应区域，这个字符就表示为0x6c38,可以用下面的代码证明：

Char han=’永’System.out.format(“%x”,(short)han);

输出是：6c38。反过来用Unicode编号来指定一个字符也可以，像这样：

Char han=0x6c38;System.out.println(han)

输出就是：永。

 这其实也是说，只要你正确地读入了“永”字，那么它在内存中的表示形式一定是0x6c38,没有任何其他的值能代表这个字。

  JVM的这种约定使得一个字符分为两部分：JVM 内部和OS的文件系统。在JVM内部，统一使用Unicode表示，当这个字符被从JVM内部移到外部（即保存为文件系统中的一个文件的内容时），就进行了编码转换，使用了具体的编码方案。因此可以说，所有的编码转换只发生在边界的地方。

  所有的I/O基本上可以分为两大阵营：面向字符的输入/输出流；面向字节的输入/输出流。面向字符或者面向字节中的所谓“面向”，是指这些类在处理输入/输出的时候，在哪个意义上保持一致。

如果面向字节，那么这类工作要保证系统中的文件二进制内容和读入JVM内部的二进制内容一致，不能变换任何0和1的顺序。这种输入/输出方式很适合读入视频文件或者音频文件，或者任何不需要做变换的文件内容。

  而面向字符I/O是指希望系统中的文件的字符和读入内存的“字符”（注意和字节的区别）要一致。例如，我们的中文版Winddows系统上有一个GBK文本文件，其中有一个“永”字，这个字的GBK编码什么不用管，当我们使用面向字符的I/O把它读入内存并保存在一个char型变量中时，我希望I/O系统不要直接把“永”字的GBK编码放到这个字符（char）型变量中，我不关心这个char型变量具体的二进制内容到底是多少，我只希望这个字符读进来之后仍然是“永”字。

  从这个意义上也可以看出，面向字符的I/O类，也就是Reader和Writer类，实际上隐式地做了编码转换，在输出时，将内存中的Unicode 字符使用系统默认的编码方式进行了编码，而在输入时，将文件系统中已经编码过字符使用默认编码方案进行了还原。这里要注意：Reader 和Writetr 只会使用这个默认的编码来转换，而不能为一个Reader或者Writer 指定转换时使用的编码。这也意味着，如果使用中文版Windows系统，其中存放了一个UTF-8编码的文件，当采用Reader类来读入的时候，它会使用GBK来做转换，转换后的内容当然不对。这其实是一种傻瓜式的功能提供方式对大多数初级用户（以及不需要夸平台的高级用户）来说反而是一件好事情。

  如果用到GBK 编码以外的文件，就必须采用编码转换：一个字符与字符之间的转换。因此，Java的I/O系统中能够指定转换编码的地方，也就在字符与字节转换的地方，那就是InputStreamReader和OutputStreamWriter。这两类是字节流和字符流之间的适配器类，它们承担编码转换的任务。

答案B