我们来对defineClass这个方法进行解析，该方法比较复杂，首先如图：

该方法主要是通过一个字节的数组，对该数据进行解析、验证、二进制码格式校验。通过抛出的ClassFormatError的这个异常来看，也是验证这个类的格式是否符合JVM的规范。
最终是将一个字节数组转换成类实例（注意不是实例对象，是有区别的）。
目前该方法已被替代，注意上图里的注释。

目前新方法，如下图：

第一个参数，其实就是类名(包括整个包名在内)。
现在对该方法进行详细的解析，首先看下check方法，如图：

非常简单，就是检测classLoader是否初始化。

preDefineClass方法，如图：

checkName检测类名是否有效（去除数组类型的判断），禁止以java.为前缀包名。如果没有保护域，则获取默认保护域；最后是进行数字签名的验证。
主要看下数字验证方法，checkCerts方法，如图：

数字验证的方式也很简单，如果存在就比较当前保护域里的数字签名与之前的数字签名是否匹配；反之就在package2certs对象(就是一个hashtable)里缓存起来。
这里的数字签名是从CodeSource这个类型的对象来获取，也就是代码源里的签名。
compareCerts方法就是对比两个数字签名是否匹配(方法很简单，这里就不用截图了)。这里主要是针对于类安全考虑，防止有人恶意修改类文件，采用的是通用的java安全框架来实现的。以后会在java安全的源码分析里在进行详细介绍。

defineClassSourceLocation方法，如图：

非常简单，就是获取代码基的路径。
然后就是开始调用本地解析方法defineClass1进行处理（类似于findLoadedClass方法处理）。如果抛出ClassFormatError异常，在给一次机会（调用方法defineTransformedClass），重新传输一次类的二进制码做解析；如果还是失败，就抛出ClassFormatError异常类型。

最后是执行postDefineClass方法，如图：

这里就是用之前比较过的数字签名，对类进行签名操作（也就是类似于加密操作）

这里需要注意的是：
defineClass方法与loadClass方法是两种不同加载类的实现。
区别在于：
前者是有严格的安全机制，输入源是一个二进制码；后者很简单就是一个本机的加载方式，输入源来自本地存放的class文件。
前者比较适合于网络远程加载类，因为需要进行安全控制；后者是一个比较基于自定义目录加载的实现。
前者在实现时主要是findClass方法与之配合使用；而后者主要是要设置加载的URL（也就是路径）。
这里非常明显地体现出了java的核心思想（严格地来讲应该是核心特性），安全和网络。

java的类加载器，还有一个特殊的功能，就是加载本地库。这个功能是与关键字native是有关系的。简单地说就是调用C++/C的本地库(windows是后缀为.dll，linux下是后缀为.so)。

调用的地方是使用System这个类，其中有两个方法如下：
load(String filename)
loadLibrary(String libname)
一个是根据文件名，一个根据lib名。注意文件名不等同于lib名，不然写错了，会报加载失败信息。
System类是一个很特殊的类，与底层交互较多，会看到很多native关键字，到时候在会在解析System和Runtime时再详细介绍。

回到之前的主题，这两个方法最终都是调用到了ClassLoader.loadLibrary(fromClass, name,isAbsolute)。该方法如图：


说明下参数：
fromClass这个参数是当前调用者的类实例，例如：
public class Test{
            public void load(){
                   System.loadLibrary("1232");
            }
}
这时fromClass参数就是Class<Test>。
isAbsolute参数很简单，指是否是规则路径(例如：../../test.java)。
name参数有可能是文件名方式，也有可能是libname方式。

该方法第一阶段就是基于DownloadManager判断，如果JRE没有完成并且当前还有线程下载时，就会调用DownloadManager类的静态方法downloadFile。
DownloadManager类，这个属于sun.jkernel包下的，与JRE组件有关，简单地说就是安装了JRE的存放路。
有时候JRE是在嵌入的位置就是JAVA_HOME/jre，有时候是独立位置，特别是在windows操作系统下安装时，会提示安装JRE这时可以随时选择存放路径。
JVM初始化完成后会调用此类，另外DownloadManager这个类也支持命令行的操作。以后会进行更多的详细介绍。

因为较为复杂，很多用了调用本地方法，所以我这里只简单介绍。
java.library.path是java的系统变量，其值等于系统变量里的PATH。
sun.boot.library.path是java系统变量，其值等于JAVA_HOME/jre/bin。

主要是通过4个过程来加载本地库。
第1步骤就是判断是否是规则路径，为true，就直接对规则路径进行转换后加载，如果加载失败直接抛出异常并执行步骤5；反之执行步骤2。
                规则路径就是使用了.或..这样符号。
第2步骤如果类加载器不为空，从类加载里获取libname信息，
               但是抽象类ClassLoader是一直返回NULL的（可查看ClassLoader.findLibrary方法），所以基本上都会直接执行步骤3(除非是自定义类加载器，重写了此方法)。
第3步骤首先从sun.boot.library.path里的全部路径下搜索libname进行加载，如果成功执行步骤5；反之执行步骤4。
第4步骤首先判断类加载器是否为空，不为空时，将从java.library.path里的全部路径下搜索libname进行加载，不管成功与否，都会执行步骤5。
第5步骤执行完毕。

另外本地库名称（已经加载过的）在代码中有三个存放属性，如下：
    // All native library names we've loaded.
    private static Vector loadedLibraryNames = new Vector();
    // Native libraries belonging to system classes.
    private static Vector systemNativeLibraries = new Vector();
    // Native libraries associated with the class loader.
    private Vector nativeLibraries = new Vector();

加载之后存放相关信息使用NativeLibrary类来保存的，该加载机制与JNI技术有密切联系，也使用下JNI会对该加载功能有更深入的了解。

System与Runtime源码解析