maven学习总结

2020-07-04

1. maven项目管理工具

1.1 依赖管理:

依赖管理就是对jar包的管理过程, 传统项目中直接放置jar包, maven工程真正的将jar包在仓库中配置, 项目中只用放置jar包的坐标,

###1.2 一键构建

使用maven集成的tomcate插件对项目进行构建, 测试 打包，安装，等操作。

1.3 仓库分类

分为三类： 本地仓库，远程仓库（私服），中央仓库。

本地仓库是我们运行项目第一步必须保证本地仓库有对应的jar包。如果本地没有默认会自动去中央仓库去下载，在公司中会先从远程仓库下载， 远程仓库没有的话， 会从中央仓库下载或本地上传。

1.4 maven的三大生命周期：

清理生命周期： clean。清理target下的class文件

默认生命周期：

compile（只编译src/main下面的代码），

test(既编译src/main下面的代码，又会编译src/test下面的代码)，

package（前两步都走了， 还会在target目录下打个包），

install（会把前面的步骤都走一遍，不但会在target目录下打个包，还会在本地仓库打个包），这几个命令，

1.5 jar包的依赖

直接依赖： A 项目中导入了B包， 我们可以说A直接依赖B。

传递依赖： A 项目中导入了B包，B包直接依赖于C吗，最终A项目中也可以使用C，那么我们就可以说A传递依赖于C。

1.6 解决jar包冲突的三个原则

第一声明优先原则：哪个jar包的坐标在靠上的位置， 哪个就是第一声明，最终进入项目的就是哪个包的依赖包。

路径优先原则：直接依赖路径比传递依赖路径近， 哪个依赖路径近， 进入项目的就是哪个包。

直接排除法：使用exclutions标签直接来排除某个包下的依赖包。

1.7 统一jar包版本管理

      <!-- 统一管理jar包版本 -->
        <properties>
          <spring.version>5.0.2.RELEASE</spring.version>
          <slf4j.version>1.6.6</slf4j.version>
          <log4j.version>1.2.12</log4j.version>
          <shiro.version>1.2.3</shiro.version>
          <mysql.version>5.1.6</mysql.version>
          <mybatis.version>3.4.5</mybatis.version>
          <spring.security.version>5.0.1.RELEASE</spring.security.version>
        </properties>

锁定jar包版本

maven工程是可以分父子依赖关系的。

凡是依赖别的项目后，拿到的别的项目的依赖包，都属于传递依赖。

比如：当前A项目，被B项目依赖。那么我们A项目中所有jar包都会传递到B项目中。

B项目开发者，如果再在B项目中导入一套ssm框架的jar包，对于B项目是直接依赖。

那么直接依赖的jar包就会把我们A项目传递过去的jar包覆盖掉。

为了防止以上情况的出现。我们可以把A项目中主要jar包的坐标锁住，那么其他依赖该项目的项目中，

即便是有同名jar包直接依赖，也无法覆盖。

    <!-- 锁定jar包版本 -->
        <dependencyManagement>
          <dependencies>
            <dependency>
              <groupId>org.springframework</groupId>
              <artifactId>spring-context</artifactId>
              <version>${spring.version}</version>
            </dependency>
            <dependency>
              <groupId>org.springframework</groupId>
              <artifactId>spring-web</artifactId>
              <version>${spring.version}</version>
            </dependency>
            <dependency>
              <groupId>org.springframework</groupId>
              <artifactId>spring-webmvc</artifactId>
              <version>${spring.version}</version>
            </dependency>
            <dependency>
              <groupId>org.springframework</groupId>
              <artifactId>spring-tx</artifactId>
              <version>${spring.version}</version>
            </dependency>
            <dependency>
              <groupId>org.springframework</groupId>
              <artifactId>spring-test</artifactId>
              <version>${spring.version}</version>
            </dependency>
            <dependency>
              <groupId>org.mybatis</groupId>
              <artifactId>mybatis</artifactId>
              <version>${mybatis.version}</version>
            </dependency>
          </dependencies>
        </dependencyManagement>

1.8 工程和模块的区别

工程不等于完整的项目，模块也不等于完整的项目，一个完整的项目看的是代码，代码完整，就可以说这是一个完整的项目和此项目是工程和模块没有关系。

工程天生只能使用自己内部资源，工程天生是独立的。后天可以和其他工程或模块建立关联关系。模块天生不是独立的，模块天生是属于父工程的，模块一旦创建，所有父工程的资源都可以使用。

父子工程直接，子模块天生集成父工程，可以使用父工程所有资源。子模块之间天生是没有任何关系的。

父子工程直接不用建立关系，继承关系是先天的，不需要手动建立。平级直接的引用叫依赖，依赖不是先天的，依赖是需要后天建立的。

1.9 项目之间的依赖关系

举例:

2 Jdk1.8新特性

2.1jdk1.8使用红黑树的改进

在java jdk8中对HashMap的源码进行了优化，在jdk7中，HashMap处理“碰撞”的时候，都是采用链表来存储，当碰撞的结点很多时，查询时间是O（n）。
在jdk8中，HashMap处理“碰撞”增加了红黑树这种数据结构，当碰撞结点较少时，采用链表存储，当较大时（>8个），采用红黑树（特点是查询时间是O（logn））存储（有一个阀值控制，大于阀值(8个)，将链表存储转换成红黑树存储）

问题分析：

你可能还知道哈希碰撞会对hashMap的性能带来灾难性的影响。如果多个hashCode()的值落到同一个桶内的时候，这些值是存储到一个链表中的。最坏的情况下，所有的key都映射到同一个桶中，这样hashmap就退化成了一个链表——查找时间从O(1)到O(n)。

随着HashMap的大小的增长，get()方法的开销也越来越大。由于所有的记录都在同一个桶里的超长链表内，平均查询一条记录就需要遍历一半的列表。

JDK1.8HashMap的红黑树是这样解决的：

如果某个桶中的记录过大的话（当前是TREEIFY_THRESHOLD = 8），HashMap会动态的使用一个专门的treemap实现来替换掉它。这样做的结果会更好，是O(logn)，而不是糟糕的O(n)。

它是如何工作的？前面产生冲突的那些KEY对应的记录只是简单的追加到一个链表后面，这些记录只能通过遍历来进行查找。但是超过这个阈值后HashMap开始将列表升级成一个二叉树，使用哈希值作为树的分支变量，如果两个哈希值不等，但指向同一个桶的话，较大的那个会插入到右子树里。如果哈希值相等，HashMap希望key值最好是实现了Comparable接口的，这样它可以按照顺序来进行插入。这对HashMap的key来说并不是必须的，不过如果实现了当然最好。如果没有实现这个接口，在出现严重的哈希碰撞的时候，你就并别指望能获得性能提升了。