java类的加载与初始化过程

导语
当使用java指令运行一个java程序的时候会启动一个虚拟机进程，也就是说无论里面启动了多少个线程都是在这个进程里面（怕读者误解java多线程，有必要注明一下：如果默认的HotSpot将内核级线程与jvm线程进行一对一映射，那么就是用操作系统的系统调用进行控制，如果是ME默认的N对一模型就是用进程内的线程库在jvm用户级线程里面通过映射切换）

“初入类加载”—-jvm运行过程
学过操作系统，我们知道要使程序执行，最少也要让cpu和内存可以相互配合，CPU取址执行，所以JVM要使用某个类时，该类必须存在内存当中，但该类(.class)还没加载到内存中，因此就需要想办法将它先整进去先，类加载或者叫类初始化的概念就这么产生了，一般包含三个过程
1. 加载 (将class文件读入内存。并为之创建一个java.lang.Class对象)
2. 链接(将Class对象的二进制数据流合并到jre里面,为类变量分配内存,设置默认       值，后半句说人话就是static声明的变量准备好可以干活了)
3. 初始化(类变量设置初始值，static代码块准备好了,关于类初始化的时机我会在      本文末尾顺便提及)

类的加载可以动态加载也可以预先加载，java虚拟机规范允许预先加载

类的加载/初始化主要是类加载器来完成的，类加载器一般由jvm提供，理论上是可以自定义

“步入核心”—-类的加载器ClassLoader

作用：使java可以动态加载class文件到JVM里面去执行
##举个应用例子，因为有动态加载，所以从网络中加载class文件，如果跟正反序 列化配合使用，嘿嘿嘿，就可以实现在线更新，如果你写的代码非常非常符合开闭原则的话，小兄代，这辈子你的用户都不需要重新下载了，不过得更换一下类加载器，才能远程加载，默认的是只能从本地加载

## 结构：树形 ##

可能，也许，大概，图片有点ugly
每个 Java 类都维护着一个指向定义它的类加载器的引用，我们知道java中是不允许类名重复的，因此为了程序的安全运行，类的加载机制也有了三种：
第一种：就是直接交给同一个去初始化
第二种：委托给父加载器去初始化，或者另一个可能可以初始化的加载器（java.lang.ClassLoader分装的类装载器使用这种模式，在Tomcat中有所不同,为了使应用自身定义的类高于容器,先找自己再找父类加载器,但是核心库类除外,为了确保核心库的安全）
第三种：采用缓存，将初始过的缓存起来
个人感觉第二种可以满足大部分需求，虽然第一种也足够

敲黑板！！！为什么类的加载要重点扯到类加载器加载机制呢
因为这是我们利用类加载器的委托代理实现模块化的基石
其实模块化的本质就是利用不同的类加载器进行加载来实现的，但一个模块A在另一个模块B被引用是，A模块会委托B模块进行类加载

总结

类加载过程其实光看是没有多大用途了，能够不断在琢磨，在实际生产的代码中模拟，练到熟练了才能潜移默化地对代码编写的质量有所提高
但是这并不意味着看了这篇博客你没有可以马上带走的东西
你需要

1. 理解模块化本质
2. 理解在线更新实现原理
3. 自定义类加载器也是实现某些应用层面的难题的一种方法（虽然也可以实现颗粒度更细的东西，但是不推荐，原因嘛，跟服务降级一个道理，出事了容易拉其他业务下水)

目前较为广泛利用的实质上就是以下三点知识

1. 类加载器之间的实例创建销毁是独立的
2. 可以自定义整个加载过程（配置文件加解密，简直不要太安全，除非骇客反编译你的那份jar包）
3. 动态加载

一点小小的个人观点，如果不是很同意或者有疑问可以说一下

说起模块化，对于java9模块化的话我目前还是持观望态度，毕竟每一次拆分都会在架构层次上增加不少复杂性，比如微服务，maven模块化，如今从jar为基本单位再到moudle为运行的基本单位，对于大多说应用和没有足够经验的人来说划分模块不是一件简单的事情，比如在java9模块中jar包的存放问题，应该怎么划分，而且就目前来说基于module的模块化的参考资料相对于基于jar的模块化的少得多，轻量级的话肯定是java9的更加轻量，感觉人家就是奔着优化jar的部署和解耦去的，但是如果业务需求很复杂的话，用吧，花点时间琢磨一下，比起后期维护起来的方便还是不亏的，小应用的话老老实实用maven，学习成本低，开发完成后，系统模块之间的管理也有比较多的工具可用