1.模块化系统简介以及解决的问题
java模块化系统是JDK9引入的一个重要系统。在介绍Java模块化系统之前先简单介绍下在JDK9之前开发一个Java应用程序的大致过程
1.一般以Java类的形式编写程序，不同的Java类被安排在一个包（package）中。一个包是一个逻辑的类型集合，本质上为它包含的类型提供一个命名空间， 即使声明为public，包可能包含公共类型，私有类型和一些内部实现类型。
2.编译的代码被打包成一个或多个JAR文件，也称为应用程序JAR，因为它们包含应用程序代码， 一个程序包中的代码可能会引用多个JAR。
3.应用程序可能使用类库， 类库作为一个或多个JAR文件提供给应用程序使用。
4.将所有的JAR文件（应用程序JAR文件和JAR类库）放在类路径上来部署应用程序。
这一个开发过程存在的一些问题：
1.每次运行程序时，不管rt.jar中的类是否被classloader加载，都会加载整个rt.jar（Java基础类库）JVM启动的时候，一般会有30～60MB的内存加载(而模块化可以根据模块的需要加载程序运行 需要的class）
2系统并没有对不同部分（也就是 JAR 文件）之间的依赖关系有个明确的概念。每一个公共类都可以被类路径之下任何其它的公共类所访问到，很难对代码进行封装，会导致无意中使用了并不想被公开访问的 API(应用程序接口)。 3.类路径本身也存在问题: 无法判断需要的jar文件是否重复了。
针对之前Java程序开发流程中存在的问题，Java官方提出了模块化系统，虚拟机通过实现可配置的封装隔离机制来实现模块化系统。模块是代码和数据集合， 它可以包含Java代码和本地代码，用模块来管理各个java包，虚拟机通过实现可配置的封装隔离机制来实现模块化系统。模块化系统，可以解决以下问题；
1.解决基于类路径（ClassPath）来查找依赖的可靠性问题
此前，如果类路径中缺失了运行时依赖的类型，那就只能等程序运行到发生该类型的加载、链接 时才会报出运行的异常。而在JDK 9以后，如果启用了模块化进行封装，模块就可以声明对其他模块的显式依赖，这样Java虚拟机就能够在启动时验证应用程序开发阶段设定好的依赖关系在运行期是否完备，如有缺失那就直接启动失败，从而避免了很大一部分由于类型依赖而引发的运行时异常。使得虚拟机有更可靠的配置。
2.解决了跨JAR文件的public类型的可访问性问题
JDK 9中 的public类型不再意味着程序的所有地方的代码都可以随意访问到它们，模块提供了更精细的可访问性控制，必须明确声明其中哪一些public的类型可以被其他哪一些模块访问，这种访问控制也主要是在类 加载过程中完成的。使得类具有更强大的封装。
3.解决了rt.jar文件需要全部加载的问题。
2.模块化系统包含的内容
模块定义包含以下内容：
1.依赖其他模块的列表。
2.导出的软件包列表（其公共API），即其他模块可以使用的列表。
3.开放的软件包（其整个API，公共和私有）列表，即其他模块可反射访问模块的列表。
4.使用的服务列表（或使用java.util.ServiceLoader类发现和加载）
5.提供的服务的实现列表
其中放射访问我的理解就是我们常用的ClassName.GetMethon的形式。
一个模块jar文件与一个普通的jar文件很相像，区别就是模块jar文件在根目录包含了一个modle-info.class文件，这个文件是用来模块信息的，位于 java 代码结构的顶层，模块定义了的需要什么依赖关系，以及哪些模块被外部使用等信息就是保存在这个文件中。在 exports 子句中未提及的所有包默认情况下将封装在模块中，不能在外部使用。
注意：与包的名字一样，模块的名字必须不能重复。
3.模块的兼容性
1.向后兼容性
为了使使用传统的类路径的程序，升级到JDK 9后对应用没有影响，即使可配置的封装隔离机制能够兼容传统的类路径查找机制，提出了“类路径”（ClassPath）相对应的“模块路径”（ModulePath）的概念：即某个类库到底是模块还是传统的JAR包，只取决于它存放在哪种路径上。只要是放在类路径上的JAR文件，无论其中是否包含模块化信息（是否包含了module-info.class文件），它都会被当作传统的JAR包来对待；相应地，只要放在模块路径上的JAR文件，即使没有使用JMOD后缀，甚至说其中并不包含module-info.class文 件，它也仍然会被当作一个模块来对待。并提出了三条访问规则：
类路径访问规则：
所有类路径下的JAR文件及其他资源文件，都被视为自动打包在一个匿名模块（Unnamed Module）里，这个匿名模块几乎是没有任何隔离的，它可以看到和使用类路径上所有的包、JDK系统模块中所有的导出包，以及模块路径上所有模块中导出的包。
模块访问规则：
模块路径下的具名模块（Named Module）只能访问到它依赖定义中列明依赖的模块和包，匿名模块里所有的内容对具名模块来说都是不可见的，即具名模块看不见传统JAR包的内容。
JAR文件在模块路径的访问规则：
如果把一个传统的、不包含模块定义的JAR文件放置到模块路 径中，它就会变成一个自动模块（Automatic Module）。尽管不包含module-info.class，但自动模块将默认依赖于整个模块路径中的所有模块，因此可以访问到所有模块导出的包，自动模块也默认导出自己所有的包。
Java模块化系统目前不支持在模块定义中加入版本号来管理和约 束依赖，本身也不支持多版本号的概念和版本选择功能。
2.模块之间的兼容性
如果同一个模块发行了多个不同的版本，那只能由开发者在编译打包时人工选择好正确版本的模块来保证依赖的正确性。Java模块化系统目前不支持在模块定义中加入版本号来管理和约束依赖，本身也不支持多版本号的概念和版本选择功能。
出现这一兼容性的原因是Oracle官方希望维持一个足够简单的模块化系统，避免技术过于复杂。
4.模块化下的类加载器
与双亲委派模型不同，模块化的类加载器在双亲委派模型上进行了一些改进。
1.扩展类加载器（Extension Class Loader）被平台类加载器（Platform Class Loader）取代
2.平台类加载器和应用程序类加载器都不再派生自java.net.URLClassLoader，现在启动类加载器、平台类加载器、应用程序类加载器全都继承于 jdk.internal.loader.BuiltinClassLoader。如果程序直接依赖了URLClassLoader类的特定方法，那代码很可能会在JDK 9及更高版本的JDK中崩溃。
在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载，也许这可以算是对双亲委派的第四次破坏
