1、____________________________________________________________
1，JVM底层结构
1，JVM指令系统
Java指令也是由 操作码和操作数两部分组成。
操作码为8位二进制数，使得JVM最多有256种指令，目前已使用了160多种操作码。
2，JVM寄存器
pc程序计数器//用于记录程序的执行
optop操作数栈顶指针//下面3个都是用于记录指向Java栈区的指针
frame当前执行环境指针
vars指向当前执行环境中第一个局部变量的指针
3，JVM栈结构
JVM为每一个方法创建一个栈框架，以保存该方法的状态信息。每个栈框架包括以下三类信息：
局部变量//vars寄存器指向该变量表中的第一个局部变量。
执行环境//保存解释器对Java字节码进行解释过程中所需的信息
操作数栈//存储运算所需操作数及运算的结果
4，JVM碎片回收堆
Java类的实例所需的存储空间是在堆上分配的。解释器具体承担为类实例分配，回收空间的工作
5，JVM存储区：常量缓冲池、方法区、堆、Java栈、程序计数器和本地方法栈
常量缓冲池用于存储类名称、方法和字段名称以及串常量。
方法区则用于存储Java方法的字节码。
堆保存的是用new创建的对象和数组
栈中主要保存的是基本类型的变量和对象的引用变量，
具体实现方式在JVM规格中没有明确规定。
这使得Java应用程序的存储布局必须在运行过程中确定，依赖于具体平台的实现方式。
JVM还存在缺陷，但JVM的思想是成功的。
2，JVM内存
1，JVMTI--JVM Tool Interface,但JVMTI提供的能监听的event总觉得还太少
2，代码验证：
Runtime r=Runtime.getRuntime();
r.maxMemory();//默认64M
r.freeMemory();
r.totalMemory();//默认-按需从OS动态获取
3，参数说明
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
- Xmx3550m ：设置JVM 最大可用内存为3550M。XMS(Extended Memory Specification)说明书-规格。扩展内存。默认64M
-Xms3550m ：设置JVM 初始内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM 重新分配内存。
-Xmn2g ：设置年代大小为2G。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小 。持久代一般固定大小为64m，持久代Permanent Generation space
-Xss128k ：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。
4，参数-命令行设定
java -cp ClassPath -Xmx512m ClassName，//-cp等效于-classpath
5，内存溢出类型
1 、 java.lang.OutOfMemoryError: PermGen space
存放Class和Meta信息，很多Class或第三方jar。大小超过了jvm默认的大小(4M)报错
GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，
它
2、tomcat下的应用
1，设置内存
$TOMCAT_HOME$/CATALINA.BAT第一行,增加
set JAVA_OPTS=%JAVA_OPTS% -Xms512m -Xmx900m -Duser.timezone=GMT+08
2 、 java.lang.OutOfMemoryError: Java heap space
3，手动设置MaxPermSize大小
修改TOMCAT_HOME/bin/catalina.bat（Linux下为catalina.sh），在Java代码
“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m
6，Sun JVM分代垃圾回收器把堆内存分成3块：采用分代的策略。
1）年轻代(Young Gen)：年轻代主要存放新创建的对象，内存大小相对会比较小，垃圾回收会比较频繁。年轻代分成1个Eden(伊甸园) Space和2个Suvivor(幸存者) Space（命名为A和B）
当对象在堆创建时，将进入年轻代的Eden Space。
垃圾回收器进行垃圾回收时，扫描Eden Space和A Suvivor Space，如果对象仍然存活，则复制到B Suvivor Space，如果B Suvivor Space已经满，则复制到 Old Gen
扫描A Suvivor Space时，如果对象已经经过了几次的扫描仍然存活，JVM认为其为一个Old对象，则将其移到Old Gen。
扫描完毕后，JVM将Eden Space和A Suvivor Space清空，然后交换A和B的角色（即下次垃圾回收时会扫描Eden Space和BSuvivor Space。
Young Gen垃圾回收时，采用将存活对象复制到到空的Suvivor Space的方式来确保不存在内存碎片，采用空间换时间的方式来加速内存垃圾回收。
2）年老代(Tenured Gen)：年老代主要存放JVM认为比较old的对象（经过几次的Young Gen的垃圾回收后仍然存在），内存大小相对会比较大，垃圾回收也相对没有那么频繁（譬如可能几个小时一次）。年老代主要采用压缩的方式来避免内存碎片（将存活对象移动到内存片的一边），当然，有些垃圾回收器（譬如CMS垃圾回收器）出于效率的原因，可能会不进行压缩。
3）持久代(Perm Gen)：持久代主要存放类定义、字节码和常量等很少会变更的信息，关于这块的垃圾回收策略可以参考我的另一篇BLOG《Tomcat Context reloadabled 与 OutOfMemory(PermSpace) 》。
3，JVM加载类
1，类装载器
装载类时，总是先让自己的(递归)父类装载器装载
Test.class.getClassLoader().getClass()
sun.misc.Launcher$AppClassLoader
Test.class.getClassLoader().getParent().getClass()
sun.misc.Launcher$ExtClassLoader
ExtClassLoader.getParent()为null
BootstrapLoader是用C++语言写的,不存在java类实体
2，JVM按以下顺序搜索并装载所有需要的类:
1, 系统/平台类: jdk1.6.0_02\jre\lib\rt.jar。
2, 扩展类:$JAVA_HOME\jre\lib\ext\*.jar
3, 用户类: 开发者定义的类，没有使用 java 扩展机制的第三方jar.
3，定位JRE:
1. 自己的目录下有没有JRE目录
2. 父目录下的JRE子目录
3. 查询环境变量$JAVA_HOME目录
4，定位到类
“系统类”，“扩展类”，前两种的路径由JRE指定；
“用户类”的查找顺序
1. -classpath(命令行模式下使用);
2. classpath(在环境变量中设计，当有 –classpath时该路径信息不起作用)
3. 缺省路径”.” 当前目录(当前两步都没有时，才会使用缺省路径)
5，类如何被装载-“动态装载”-为了节省内存，但牺牲了相应速度。
隐式的类装载：A b = new A();最常见
显式的类装载Class.forName("test.A");
类的声明，并不去装载。这一点和编译类是不相同的。
6，类装载器的隔离性
两个位于不同分支的类装载器具有隔离性，它们装载同一个类，也会在内存中出现两个Class类的实例。
因为被具有隔离性的类装载器装载的类不会共享内存空间，使得使用一个类装载器不可能完成的任务变得可以轻而易举，
2、____________________________________________________________
unicode字符，全都是char的。没有所谓的整数等，它都叫unicode字符了，网络上传输的全都是字符。整数，只能存在于内存中，但如何区分呢？
字符流数据无边界
pc，栈的 结构是什么，线性表还是链表，用什么实现的？c么？c上面的又是用什么实现。追溯到cpu指令。
？？？？看完jvm等后对编程有什么启发
指令存在那里,for循环里面的?jvm里面的指令如何与操作系统同联系，中间需要本地方法不？（应该不需要）
java体系结构的四个组成部分：
java语言
java calss文件格式
java API（类库，有很多抽象方法，也有很多底层的方法，比如访问系统资源I/O）
jvm 抽象的计算机，有自己的指令和内存模型，C语言就没有
java API和jvm一起组成java平台。
装载与执行
jvm包含classloader，用来装载class文件，API中只有程序执行时需要的那些类才会被装载，字节码有执行引擎来执行
执行引擎（前三种为软件实现，第四种为硬件实现）
1、一次性解释字节码：实现简单，效率低（这是“解释”技术的共性）。
2、即时编译器(just-in-time compiler)，第一次执行的字节码会被编译成本地机器代码（然后缓存，以后可以重用）。效率高，但是占用内存大。
3、自适应优化器，结合1、2的优点，对频繁使用的代码编译成本地代码（10%-20%，但是它们使用的时间为80%-90%），其他仍为解释字节码。
4、硬件芯片实现，内嵌在芯片里，用本地方法执行java字节码。
三种理解：1、抽象规范，2、具体实现，3、正在运行的实例（线程）
执行引擎的行为由指令集来定义。
指令集：方法的字节码流，有指令序列构成，每个指令包含：一个单字节的指令，和后面跟随的0-n个操作数operand。
///////////////////////执行一条指令的任务之一是：决定下一条要执行的指令是什么，有三种方法：////////////////////////////
1、顺序执行。2、goto或return。3、异常。
byteStream：03 3b 84 00 01 a7 ff f9 //都是16进制的
iconst_0 //03 把int型常量0压入栈 常量0，是索引为0的常量，不是值为0,已经用javap验证。
istore_0 //3b 把int型的值存入局部变量0中
iinc 0,1 //84 00 01
goto 2 //a7 ff f9
方法
java方法：由java编写，编译成字节码，存储于class文件中
本地方法：用(C或C++或汇编）编译成与处理器相关的机器代码，保存于动态连接库中，格式是各平台专有的。
调用本地方法时，jvm装载包含这个本地方法的动态库，本地方法连接java程序与底层操作系统。
JNI(java native interface)，如果希望保证平台无关性，只能通过调用java API访问底层系统资源。
类装载器calss loader
jvm会使用装载第一个类的装载器，装载它所引用的类。
JVM规范定义了两种类型的类装载器：启动类装载器(bootstrap)和用户自定义装载器(user-defined class loader)。
bootstrap是JVM自带的类装载器，用来装载核心类库，如java.lang.*等。如java.lang.Object是由bootstrap装载的。
Java提供了抽象类ClassLoader，所有用户自定义类装载器都实例化自ClassLoader的子类。 System Class Loader是一个特殊的用户自定义类装载器，由JVM的实现者提供，在编程者不特别指定装载器的情况下默认装载用户类。系统类装载器可以通过ClassLoader.getSystemClassLoader() 方法得到。
当运行一个程序的时候，JVM启动，运行bootstrapclassloader（与jvm一样用本地代码实现），该ClassLoader加载java核心API（即所有java.*开头的类，ExtClassLoader和AppClassLoader也在此时被加载），然后调用ExtClassLoader加载扩展API（例如所有javax.*开头的类和存放在JRE的ext目录下的类），最后AppClassLoader加载CLASSPATH目录下定义的Class，
似乎JVM自身的ClassLoader已经足够了，为什么我们还需要创建自己的ClassLoader呢？ 因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件，如果编写你自己的ClassLoader，你可以做到： 1）在执行非置信代码之前，自动验证数字签名 2）动态地创建符合用户特定需要的定制化构建类 3）从特定的场所取得java class，例如数据库中 4) 等等 事实上当使用Applet的时候，就用到了特定的ClassLoader，因为这时需要从网络上加载java class，并且要检查相关的安全信息。 目前的应用服务器大都使用了ClassLoader技术
ClassLoader Tree & Delegation Model
当你决定创建你自己的ClassLoader时，需要继承java.lang.ClassLoader或者它的子类。在实例化每个ClassLoader对象时，需要指定一个父对象；如果没有指定的话，系统自动指定ClassLoader.getSystemClassLoader()为父对象。
在Java中，java class的卸载仅仅是一种对系统的优化，有助于减少应用对内存的占用。既然是一种优化方法，那么就完全是JVM自行决定如何实现，对Java开发人员来说是完全透明的。 在什么时候一个java class/interface会被卸载呢？Sun公司的原话是这么说的："class or interfacemay be unloaded if and only if its class loader is unreachable. Classesloaded by the bootstrap loader may not be unloaded."
通过线程上下文来加载第三方库jndi实现, 而不依赖于双亲委派. 大部分java app服务器(jboss, tomcat..)也是采用contextClassLoader来处理web服务。
运行时包。
如何回收对象：比如new Person时，20行后的代码才会引用到，gc怎么回收。
沙箱模型：沙箱，包含儿童玩耍的装置，安全环境的意思，
java沙箱基本组件
1、类装载器结构--守护被信任类的边界。
自定义java.lang.MyTest编译无语法错误，运行报
2、class文件检验器--calss结构检查（语法检查）、类型数据的语义检查
3、内置于jvm及java语言的安全特性
类型安全的引用转换、GC、数组边界检查、空引用检查
结构化的内存访问（无指针算法）：class文件无内存地址，jvm装载时再分配。
本地方法必须连接，动态链接库。
4、安全管理器及JAVA API
第五章，jvm
jvm概念：
1、抽象规范
2、一个具体的实现：jvm内部如何存储数据，和具体的实现有关。
3、一个运行中的jvm实例（一个java程序，对应一个jvm实例）
初始类中的main方法，作为初始线程的起点，非守护线程。
每个jvm都有一个执行引擎，执行被装载类方法中的指令。
运行时数据区5个：方法区、堆、java栈、pc计数器、本地方法栈。
jvm规范对此描述相当抽象，细节有实现者决定。
jvm装载class文件，解析得到类型信息，将其放入到方法区，并生成Class对象（位于堆区，类型信息与Class对象什么关系，重复么？）
运行时，把创建的对象存入堆中。方法区和堆，该jvm实例中所有线程共享
pc计数器和java栈，为线程独享（私有，其他线程不可见）。大小规则（容易处理，但不灵活），不像堆内存，不会出现内存碎片。
pc的值，指示下一条将被执行的指令。（指令存于pc中？）
cpu的pc是指令地址计数器，存放指令地址，那么指令有存在哪里，java指令只有一个字节，是否直接存指令本身
java栈，存储该线程中java方法的调用状态（包括它的局部变量，入参，返回值，中间结果等）
java栈有栈帧（stack frame）组成，一个栈帧对应一个调用状态。调用一个方法，就压入一个栈帧。
栈帧包含两部分：局部变量，和操作数栈。局部变量等，属于运行时数据。
本地方法的调用状态存于本地方法栈。
数据类型：
基本类型的变量持有原始值（原始数据）
引用类型的变量持有引用值（地址）
retrunAddress类型：jvm内部使用，用来实现finally字句
方法区类型信息：内存不连续，可伸缩
这个类型及其直接超类的权限定名。class文件中用/代替. 如java/lang/Object
这个类型是类类型还是接口类型（可见abstract和interface本质上不同）
这个类型的访问修饰符：public、static、final等
直接接口的（多个）的权限定名的有序列表
field信息
字段名、字段类型、修饰符
method信息
方法名、返回类型、参数个数及类型、修饰符。如果不是本地方法或抽象方法，还有以下信息：
方法的字节码bytecode
操作数栈和该方法栈帧中局部变区的大小
异常表
这个类型的常量池
直接常量（String、integer等常量），对其他类型、字段、方法的符号引用。因此在java动态链接中起核心作用。
池中的数据如数组一样通过索引访问。
除常量以外的所有类（静态）变量
编译时常量：final声明以及，编译时已知的值初始化的类变量。
一个到类ClassLoader的引用
jvm必须跟踪ClassLoader,在动态链接期间，用此来装载它所引用、依赖的类
一个到类Class的引用
每一个被装载的类型（类、接口），jvm都会为其创建一个java.lang.Class实例。
jvm还会以某种方式将Class实例与类信息关联起来。
Class类使得运行程序可以访问方法区中保存的信息。
方法表：
为了提高访问速度，jvm会为每个装载的非抽象类，生成一个方法表，作为类信息的一部分，
方法表是一个数组，元素是可能被调用用实例方法的直接引用。
堆：内存不连续，可伸缩
jvm规范没有规定java对象如何在堆中表示
1、把堆分为：句柄池、对象池。对象引用先指向句柄池，句柄池有2个条目：指向对象的引用，指向类信息的引用
2、对象中包含指向类信息的指针。
这样就可以实现动态绑定了。
堆中对象数据都有一个对象锁（互斥对象，只有一个线程可以拥有），逻辑上还与等待集合（wait set)数据关联。
PC：应该连续
栈：内存不连续，可伸缩
栈的元素--栈帧：大小确定，堆内存的对象大小不确定。
1、局部变量区：包含方法的入参和局部变量
1个字长为单位，从0开始计数的数组，字节码指令opcode通过索引(偏移量？)取数据
如：runInstanceMethod(char c,int i)，局部变量区按索引如下存储：
0 reference(实例对象的引用，对象不会被拷贝）
1 int （char c 存储时会转换成int）
2 int（int i）
2、操作数栈：也是一个字长为单位，但是是栈，不是数组
3、帧数据区：
用来支持常量池解析（入口地址），正常方法返回，异常方法派发机制
每个方法被执行的时候，都会同时创建一个帧（Frame）用于存储本地变量表、操作栈、动态链接、方法出入口等信息。每一个方法的调用至完成，就意味着一个帧在VM栈中的入栈至出栈的过程。本地变量表存放了编译期可知的各种标量类型（boolean、byte、char、short、int、float、long、double）、对象引用（不是对象本身，仅仅是一个引用指针）、方法返回地址等。其中long和double会占用2个本地变量空间（32bit），其余占用1个。
本地方法栈
字节码(java方法），
第六章：class文件
ClassFile {
u4 magic;//前4个字符永远是0xCAFEBABE
u2 minor_version;
u2 major_version;
u2 constant_pool_count;
cp_info constant_pool[constant_pool_count-1];
u2 access_flags;
u2 this_class;
u2 super_class;
u2 interfaces_count;
u2 interfaces[interfaces_count];
u2 fields_count;
field_info fields[fields_count];
u2 methods_count;
method_info methods[methods_count];
u2 attributes_count;
attribute_info attributes[attributes_count];
}
线程
同步，syncronized
协作，wait，notifyall
保存到什么地方（另类说法）
程序运行时，我们最好对数据保存到什么地方做到心中有数。特别要注意的是内存的分配。有六个地方都可以保存数据：
(1) 寄存器。最快，位于CPU。寄存器是根据需要由编译器分配。我们对此没有直接的控制权。
(2) 堆栈。可通过它的“堆栈指针”获得处理的直接支持。
(3) 堆。
(5) 常数存储。常数值通常直接置于程序代码内部。因为它们永远都不会改变
(6) 非RAM存储。若数据完全独立于一个程序之外，则程序不运行时仍可存在，并在程序的控制范围之外。比如“流式对象”和“固定对象”。对于流式对象，对象会变成字节流，通常会发给另一台机器。而对于固定对象，对象保存在磁盘中。
3、待整理____________________________________________________________
经典书不是看一两遍就可以的。要反反复复地体会理解。结合JMX
内存模型，class文件。？
一个对象占用多大的内存。？
计算机的基本构成是：运算器、控制器、存储器、输入和输出设备
JVM是一个内存中的虚拟机
编译环境
.java文件--java编译器--.class文件
字节码.class文件本地或网络
运行期环境（java平台）
类装载器字节码的验证--装入.class文件和库文件--java解释器/即时编译器--
运行数据区5个（除了本地方法栈）--执行引擎--native interface -- native libray
问：OutOfMemory错误分几种？
答：分两种，分别是“OutOfMemoryError:java heap size”和”OutOfMemoryError: PermGen space”，两种都是内存溢出，heap size是说申请不到新的内存了，这个很常见，检查应用或调整堆内存大小。
“PermGen space”是因为永久存储区满了，这个也很常见，一般在热发布的环境中出现，是因为每次发布应用系统都不重启，久而久之永久存储区中的死对象太多导致新对象无法申请内存，一般重新启动一下即可。
问：为什么会产生StackOverflowError？
答：因为一个线程把Stack内存全部耗尽了，一般是递归函数造成的。栈和线程、方法、基本类型值、对象符号引用有关
JIT编译器
java开始只是解释型的，速度慢，为此后来sun在JVM上提供一个工具，把字节码编译成原生码，下次你来访问的时候直接访问原生码就成了
引用类型包括：类类型，接口类型和数组
栈是运行时的单位，而堆是存储的单位.栈因为运行时的需要，比如保存系统运行的上下文，需要进行地址段的划分。由于栈只能向上增长，因此就会限制住栈存储内容的能力。
栈因为是运行单位，因此里面存储的信息都是跟当前线程（或程序）相关信息的。包括局部变量、程序运行状态、方法返回值等等.
当我们把对象拆开，你会发现，对象的属性其实就是数据，存放在堆中；而对象的行为（方法），就是运行逻辑，放在栈中。我们在编写对象的时候，其实即编写了数据结构，也编写的处理数据的逻辑。不得不承认，面向对象的设计，确实很美。
程序运行永远都是在栈中进行的，因而参数传递时，只存在传递基本类型和对象引用的问题,传对象不显示（对象大小不规则）。线程拷贝的对象副本在线程工作内存中，共享对象在主内存。
对象，从某种意义上说，是由基本类型组成的。可以把一个对象看作为一棵树，对象的属性如果还是对象，则还是一颗树（即非叶子节点），基本类型则为树的叶子节点。
垃圾回收策略：会暂停程序执行
按照基本回收策略分
1、引用计数（Reference Counting）:
比较古老的回收算法。原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只用收集计数为0的对象。
此算法最致命的是无法处理循环引用的问题，即A,B相互引用。
2、标记-清除（Mark-Sweep）+复制（Copying）
3、标记-整理（Mark-Compact）
4、火车头算法。
按分区对待的方式分
增量收集（Incremental Collecting）:实时垃圾回收算法，即：在应用进行的同时进行垃圾回收。不知道什么原因JDK5.0中的收集器没有使用这种算法的。
分代收集（Generational Collecting）:基于对对象生命周期分析后得出的垃圾回收算法。把对象分为年青代、年老代、持久代，对不同生命周期的对象使用不同的算法（上述方式中的一个）进行回收。现在的垃圾回收器（从J2SE1.2开始）都是使用此算法的。
按系统线程分：串行收集（单线程），并行收集。并发收集:相对于串行收集和并行收集而言，前面两个在进行垃圾回收工作时，需要暂停整个运行环境，而只有垃圾回收程序在运行，因此，系统在垃圾回收时会有明显的暂停，而且暂停时间会因为堆越大而越长。
垃圾回收从Java栈开始，获取哪些对象正在被使用，因为栈是真正进行程序执行地方。并发收集器
可以保证大部分工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，此收集器适合对响应时间要求比较高的中、大规模应用。使用-XX:+UseConcMarkSweepGC打开
最大垃圾回收暂停:-XX:MaxGCPauseMillis
暂停问题：当堆空间持续增大时，垃圾回收的时间也将会相应的持续增大，对应应用暂停的时间也会相应的增大
内存碎片：并发垃圾回收算法，解决了暂停的问题，但复杂度高，回收效率低下。
String对象如何不变，他不改变参数，返回时new一个新的。
-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，操作系统对一个进程内的线程数是有限制的，不能无限生成，经验值在3000~5000左右
吞吐量最大化：GC时间占总运行时间最小化
年轻代大小选择
响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用
年轻代大小选择
响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
年老代大小选择
响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。
JVM判断2个类相同的条件：
1、类的全名是否相同，还要看加载此类的类加载器是否一样
所有Java代码都要引用java.lang.Object类，如果用自己的类加载器来完成的话，就会存在很多版本的java.lang.Object类。通过代理模式，对于Java核心库的类的加载工作由引导类加载器来统一完成，保证了 Java 应用所使用的都是同一个版本的 Java 核心库的类，是互相兼容的。
不同的类加载器为相同名称的类创建了额外的名称空间。相同名称的类可以并存在 Java 虚拟机中，只需要用不同的类加载器来加载它们即可。不同类加载器加载的类之间是不兼容的，这就相当于在 Java 虚拟机内部创建了一个个相互隔离的 Java 类空间。这种技术在许多框架中都被用到，后面会详细介绍。
方法-对应线程-main是主线程。
SPI（Service Provider Interface，如JDBC,JNDI) 的接口是 Java 核心库的一部分，是由引导类加载器来加载的；SPI 实现的 Java 类一般是由系统类加载器来加载的。引导类加载器是无法找到 SPI 的实现类的，因为它只加载 Java 的核心库。它也不能代理给系统类加载器，因为它是系统类加载器的祖先类加载器。也就是说，类加载器的代理模式无法解决这个问题,由此产生了context class loader，是从 JDK 1.2 开始引入的
类加载器是 Java 语言的一个创新。它使得动态安装和更新软件组件成为可能（不重启程序，只需要从服务器上下载新的class文件即可）。