apache和虚拟机端口冲突_如何解决实际工作中的Jar包冲突？

• jar包冲突指的是什么？

       jar包冲突是一个过程，既存在某种场景使得两个jar包能够互相关联，并且两个jar包会存在对立或不一致的内容，并产生相互作用。

• 为什么会有jar包冲突这种问题呢？

    假设没有场景联系两个jar包或者关联的两个jar包内容永远是不一样的或者不让其有相互作用，那么永远不会有jar包冲突。

        1.  目前采用的Maven构建工程不可避免会关联多个jar包。

        2.  每个jar包属于一个工程并非一个团队开发。

       3.  jvm加载jar包内部实现无法更改，必然无法智能辨别哪一个jar包代码有效

        结论: 当前情景下jar包冲突是可能发生的。

•    什么情况下会产生Jar包冲突呢？

    Jvm加载的时候加载到了多个jar中一个非预期的Jar包。

•    jar包冲突会导致什么结果呢？(充分非必要条件)

      1. NoClassDefFoundError (发生加载之后阶段)实战中产生情况：

         1.1   对应的Class在java的classpath中不可用

       1.2  你可能用jar命令运行你的程序，但类并没有在jar文件的manifest文件中的classpath属性中定义

         1.3  可能程序的启动脚本覆盖了原来的classpath环境变量

       1.4  因为NoClassDefFoundError是java.lang.LinkageError的一个子类，所以可能由于程序依赖的原生的类库不可用而导致

        1.5  检查日志文件中是否有java.lang.ExceptionInInitializerError这样的错误，NoClassDefFoundError有可能是由于静态初始化失败导致的

       1.6 如果你工作在J2EE的环境，有多个不同的类加载器，也可能导致NoClassDefFoundError

     2. ClassNotFoundException(发生在加载阶段) :

        2.1 当程序试图使用class类中的forname方法、classloader类中的findsystemclass方法，classloader类中loadclass方法通过字符串名的形式加载此类时，会抛出该异常.

  3. NoSuchMethodError (发生加载之后阶段)实战中产生情况：
     3.1 版本冲突加载的类中方法无法找到对应的方法。

•    如何定位冲突的Jar包并解决？

JVM类加载原理：

 一、加载

         (1)    通过全限定名(java.lang.String)来获取二进制流。

        (2)    将这个字节流代表的静态存储结构转化为方法区的运行时数据结构。

       (3)    在Java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口。

  说明：

1. class字节码文件优点：平台无关性、节省空间加快传输速度、不用对java文件进行语法检查语义分析等。

2. 静态存储结构：class版本、常量池、访问标志、索引、字段表集合、方法表集合、属性表集合。

3. 对类加载器的引用 ，jvm必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的，那么jvm会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。

4. 方法区：类信息、常量池、域信息、类变量、常量、加载器引用等。

5. 加载阶段是开发期间可控性最强的，因为用户可以自定义类加载器进行相应的二进制流加载动作。更加详细信息请参考jvm规范第五章：loading,linkingand initializing.

    二、验证

    (1)   验证是连接阶段的第一步，这一个阶段主要目的是为了确保Class文件字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

     (2)   验证过程:文件格式验证、元数据验证、字节码验证和符号引用验证。

三、准备

   准备阶段是正式为类变量分配内存并设置类变量的初始值阶段
,在方法区中分配这些变量所使用的内存空间。例如: public static int v=20.

四、解析

    解析阶段是指虚拟机将常量池中的符号引用替换为直接引用的过程。

  4.1 直接引用：

      直接引用可以是指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。如果有了直接引用，那引用的目标必定已经在内存中存在 。

  4.2 符号引用:

 符号引用与虚拟机实现的布局无关，引用的目标并不一定要已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须是一致的，因为符号引用的字面量形式明确定义在Java虚拟机规范的 Class 文件格式中。
五、初始化

       初始化阶段是类加载最后一个阶段，前面的类加载阶段之后，除了在加载阶段可以自定义类加载器以外，其它操作都由 JVM 主导。到了初始阶段，才开始真正执行类中定义的 Java 程序代码。

     5.1 构造器

         初始化阶段是执行类构造器方法的过程。方法是由编译器自动收集类中的类变量的赋值操作和静态语句块中的语句合并而成的。虚拟机会保证子方法执行之前，父类的方法已经执行完毕，如果一个类中没有对静态变量赋值也没有静态语句块，那么编译
器可以不为这个类生成()方法。
注意以下几种情况不会执行类初始化：     1. 通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。        2. 定义对象数组，不会触发该类的初始化。     3. 常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类。         4. 通过类名获取 Class 对象，不会触发类的初始化。        5. 通过 Class.forName 加载指定类时，如果指定参数 initialize 为 false 时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。         6. 通过 ClassLoader 默认的 loadClass 方法，也不会触发初始化动作
     5.2 类加载器

        虚拟机设计团队把加载动作放到 JVM 外部实现，以便让应用程序决定如何获取所需的类

         启动类加载器(Bootstrap ClassLoader):

           负责加载 JAVA_HOME\lib 目录中的，或通过-Xbootclasspath 参数指定路径中的，且被虚拟机认可(按文件名识别，如 rt.jar)的类.

        扩展类加载器(Extension ClassLoader):
            负责加载 JAVA_HOME\lib\ext 目录中的，或通过 java.ext.dirs 系统变量指定路径中的类库.

       应用程序类加载器(Application ClassLoader)：

        负责加载用户路径(classpath)上的类库。JVM 通过双亲委派模型进行类的加载，当然我们也可以通过继承 java.lang.ClassLoader实现自定义的类加载器。 

      5.3 类加载流程        

            双亲委派：

           当一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父类去完成，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载其中，只有当父类加载器反馈自己无法完成这个请求的时候(在它的加载路径下没有找到所需加载的Class)，子类加载器才会尝试自己去加载。采用双亲委派的一个好处是比如加载位于 rt.jar 包中的类 java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个 Object 对象。

   实战中解决思路:

     一、在maven编译阶段解决：

         1.1 查询冲突：

             mvn -Dverbose dependency:tree|grep conflict 查询出重复jar包

         1.2 显示依赖包信息

         mvn dependency:tree -Dverbose -Dincludes=asm:asm

         1.3 mvn dependency:analyze

       Used undeclared dependencies found

     这个是指某些依赖的包在代码中有用到它的代码，但是它并不是直接的依赖(就是说没有在pom中直接声明)，是通过引入传递下来的包

      Unused declared dependencies found

   这个是指我们在pom中声明了依赖，但是在实际代码中并没有用到这个包！也就是多余的包。这个时候我们就可以把这个依赖从pom中剔除。(指的是main/java和test里没有用的，但是并不是意味着真的没有用到这些包)

     1.3 依赖排除事例:

     org.apache.hbasehbase0.94.17       commons-logging        commons-logging      

    二、在类加载阶段解决：

    2.1  ll -f 命令即可查看两台机器jar包加载的顺序的不同。

    2.2 -verbose -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=""打印类加载顺序和对应的jar包。

   2.3 tomcat8解决事例:

       预先加载需要的类(前提分析出加载顺序，直接引用的关系)