一个Java文件的执行全部过程你确定都清楚吗？( 六 ) _Java文件

2、第二次是为了弥补双亲委托机制的缺陷，因为双亲委托机制使得父类加载器无法使用子类加载器的类资源，这样对于父类需要调用子类加载器加载的类资源时就无法实现。为了解决这个问题，引入了线程上下文类加载器（默认为系统类加载器），当需要调用系统类加载器就可以使用这个属性进行加载。
3、IBM 公司设计的代码热部署，使得传统简单的树状继承关系，改成了更为复杂的网状结构，让每个模块都有自己自定义的类加载器。
自定义类加载器好处1、隔离加载类，创建多个模块空间，确保相互间加载的类不会冲突。
2、修改类加载的方式。某些非必要导入的类可以自定义类加载器在某个事件按需导入。
3、扩展加载器，加载不同位置位置的资源。
4、防止源码外泄。在编译时加密。
注意1、因为同一个类被两个类加载器加载会生成不同的类对象，所以如果两个继承关系的类被两个类加载器加载，那么强制转换类型会报错。所以使用自定义类加载器需要结合场景，不能一味使用。
2、实现时推荐重写 findClass 方法，不破坏双亲委托机制。
沙箱安全机制Java 沙箱是将 Java 代码限定在 JVM 特定的运行范围中，并且严格限制代码对本地系统资源的访问。防止对本地系统造成破坏。
演变1、JDK 1.0 时期
将执行的 Java 代码分为本地和远程两种，本地代码默认视为可信赖的，而远程代码则看作不受信赖的。对于信赖的代码，可以访问一切本地资源。而不受信赖的代码，则会受到沙箱的限制，不能访问本地资源。

文章插图

2、JDK 1.1 时期
由于1.0 中对远程代码限制太过激进，导致一些需要访问本地资源的远程代码无法访问，极大影响了程序的可用性，所以在 1.1 中进行了优化，在前者基础上，增加了安全策略。允许用户指定代码对本地资源的访问权限。

文章插图

3、JDK 1.2 时期
1.1 中无法解决的是本地代码权限问题，因为本地都是可以访问本地资源的，所以在 1.2 中又引入了代码签名。无论是本地代码还是远程代码，都会按照用户的安全策略设定，由类加载器加载到虚拟机中权限不同的运行空间，来实现差异化的代码执行权限控制。

文章插图

4、JDK 1.6时期
也是当前最新的安全策略，相比于前代引入了域的概念。主要升级是将资源的访问进一步划分。虚拟机会把所有代码加载到系统域或应用域中。系统域是与关键资源交互，而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。

文章插图

JDK9 的新特性1、扩展类加载器改名为平台类加载器（platform classloader）。可以通过 ClassLoader 的新方法 getPlatformClassLoader() 来获取。
2、原来的 rt.jar（启动类加载器加载的核心源码）和 tool.jar（Java程序启动所需的 class 目录下的类）被拆分成数十个 JMOD 文件，Java 类库也被改成可扩展的模式，所以拓展目录也就无需存在了。
3、平台类加载器和应用程序类加载器不再继承 URLClassLoader 。现在三大加载器全部继承于 jdk.internal.loader.BuiltinClassLoader

文章插图

4、类加载器拥有了 name 属性，可以通过 getName() 获取，平台类加载器的 name 是 platform 。应用类加载器的名称是 App 。类加载器的名称在调试与类加载器相关的问题时会非常有用。
5、启动类加载器现在是 jvm 内部和 java 类库共同协作的实现的（c++和java，过去只是c++），但是为了与之前的代码兼容，在获取启动类加载器的场景中仍然为 null 。
6、委派机制变化。在加载器收到加载请求后，会先判断该类是否属于某个系统模块，如果属于直接将这个请求发给这个模块的类加载器。