大学生Java（web）开发自学路线指南（绕坑向）

大学生Java（web）开发自学路线指南（绕坑向）

大学的学习生活已经过去了四分之三，身为一个梦想就是往编程开发的岗位进军的我，很幸运的考上了软件工程专业，虽然是个普通的大学，但我相信只要肯努力，是金子总会发光。大学的课程内容大家心里也清楚，但是编程开发本身就是很需要自己去自习的，谁都帮不了你。前段时间我看了B站一位up主，他说编程学习一个很大的优点就是可以自学（大致如此），我也相信，我们这些程序员基本上也都是靠自学来的。但是，这就伴随一个问题，
自学那究竟要学什么啊？曾经刚上大一就选择Java开发的话，碌碌无为了三年，瞎努力了三年，走了无数弯路直到大三快结束了的我才知道Java开发究竟要会点什么要学什么。为了帮助无数曾经和我一样茫然的伙伴们构建自己的学习路线，我把这几年的所了解到的东西汇总起来整合在这篇文章当中算是一个总结，也算是重构自己的知识框架，对自己所学到的知识重新整理，没学过的开始研究。点开这篇文章的你如果和我的方向一样，并且是刚上大学或者对自己的方向很迷茫的，希望这篇文章可以帮助到你；如果打算开始学习Java开发，也可以按照这个路线进行学习。如果觉得我说的有需要补充或者说的不正确的话，也欢迎大家在评论下方指点一二。

入门

Java基础

Java基础语法

这一部分基本数据类型的取值范围是必须记住的，身为一个编程人员这部分算是很基础的了，重点需要关注以下几部分：

1. ==和equals的区别
2. String、StringBuffer与StringBuilder的区别
3. &和&&的区别

面向对象

这一部分首先需要理解Java面向对象是什么，以及它的三个特征与含义

1. hashCode()方法是什么
2. 两个对象的hashCode()相同，是否equals()就是true？
3. 四个访问修饰符的区别
4. 基本数据类型和其包装类
5. 重载和重写

集合

HashMap

HashMap它是线程不安全的，下面重点关注以下几点：

1. JDK1.7时底层的数据结构是数组加链表，插入数据的方式是头插法，1.8时数据结构是数组加链表加红黑树，插入数据的方式改为尾插法，Why？
2. 扩容机制？resize？
3. 2的幂次
4. 重写equals必须重写HashCode

ConcurrentHashMap

1. 安全失败
2. JDK1.7
3. JDK1.8
4. 与HashTable、Collection.Synchronied

ArrayList

1. 底层数据结构是数组
2. 查找、访问的速度快，增删的效率低，线程不安全

LinkedList

1. 底层的数据结构是链表
2. 增删的效率高，线程不安全

I/O

异常

数据库

1. MySQL语法基础
2. JDBC
3. 数据库连接池
   1. Druid
   2. C3P0

前端技术

这部分Java开发工程师只需要打打基础即可，不需要太深入，主要就是HTML、CSS、JS、JQ、BootStrap、AJAX。其实可以在做项目的时候拿来练练，没必要拿一整块的时间去学习，把时间用在节骨眼上，毕竟大学生还要考试啥的。

动态网站

这部分无非JSP加上Servlet，我们学校就有特意花时间教这部分，甚至是综合课程把JSP和SSM融合在一起使用，但是这一部分大家就像学习前端基础技术一样，自己过一遍即可，不用花太多的时间，上课跟着老师学也就完全足够了，能理解底层思想方便后续学习tomcat和后端框架即可。可以看我的博客大致了解一下：

Srevlet

JSP

基础

JVM

推荐人手一本深入理解Java虚拟机，最好是买一本纸质版的书籍，我也会分享电子版的在下方：

第三版电子版链接: https://pan.baidu.com/s/16oAGfDtcPT9vxfDj6bB41w 提取码: qz2x 。

1. 类加载机制
2. 字节码执行机制
3. JVM内存模型
4. 分代回收
5. 垃圾回收机制
6. 垃圾回收器
7. full gc
8. STW
9. oom种类
10. 逃逸分析
11. 可达性
12. JVM调优
13. JVM性能检测工具
14. 内存泄漏
15. CPU100%

并发/多线程

1. 并发编程
2. 线程池
3. 锁
4. 并发容器
5. 原子类

Tomcat

1. Tomcat源码
2. Tomcat类加载机制

MySQL

1. 索引
2. SQL优化
3. 事务及隔离级别
4. 锁
5. MVCC

编程高级基础

数据结构与算法

数据结构

1. 字符串和数组
2. 链表
3. 二叉树
4. 堆、栈、队列
5. 哈希
6. 图

算法

1. 查找
2. 排序
3. 链表反转
4. 成环
5. 贪心
6. 分治
7. 动态规划
8. 回溯

计算机网络

1. ARP协议
2. IP/ICMP协议
3. UDP协议
4. TCP协议
   1. 三次握手
   2. 四次挥手
   3. 使用场景：网络会话、文件传输、发送接收邮件、远程登录
   4. 如何保证可靠
5. DNS/HTTP/HTTPS协议
   1. 三者的关系
   2. 为什么HTTPS更加安全
6. Session/Cookie
7. BIO
   1. 阻塞等待链接
   2. 阻塞等待数据
   3. 开发线程处理并发
   4. 耗资源
8. NIO
   1. 非阻塞IO
   2. epoll
9. 粘包/拆包：在报文末尾增加换行符表明一条完整的消息，这样在接收端可以根据这个换行符来判断信息的完整性；将消息分为消息头、消息体，可以在消息头中声明消息的长度，根据这个长度来获取报文（如808协议）；规定好报文的长度，不足的空位补齐，取的时候按照长度截取即可。
10. 多路复用：
    1. select：
       1. 单个进程可监视的fd数量被限制（也就是可以监听的端口大小有限）
       2. 对socket进行扫描时是线性扫描，即采用轮询的方法，效率比较低
       3. 需要维护一个用来存放大量的fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大
    2. poll
       1. 大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是否有意义
       2. poll还有一个特点——“水平触点”：如果报告了fd后没有被处理，那么下次poll时会再次报告该fd
    3. epoll（相对于select，基本上解决了select的问题）
       1. 没有最大并发连接的限制，能打开的fd数目上限远远大于1024（一个G的内存上能监听约10万个端口）
       2. 效率提升，对socke进行扫描时不是轮询的方法，不会随着fd数目的增加效率降低
       3. 在内存拷贝上，利用mmap()文件映射内存加速与内核空间的消息传递，也就是epoll使用mmap减少了复制的开销

操作系统

1. 进程/线程
2. 并发/锁
3. 内存管理及调度
4. I/O原理

工具的使用

说实在工具没什么好说的，会用就行：

1. 开发环境：现在基本都是用IDEA了
2. Linux系统：主要就是Linux系统的使用，需要花费一些时间，最好是把自己做的项目放到自己搭好的虚拟机或者买的服务器里面跑一下，在实际的操作中去熟悉这些指令，一般考虑CentOS系统。
   1. Linux常用命令
   2. 基本Shell脚本
3. 代码管理工具：
   1. Git
   2. SVN
4. 项目管理/构建工具：
   1. Maven
   2. Gradle

应用框架

Spring全家桶

1. Spring
   1. IOC
   2. AOP
2. Spring MVC
3. SpringBoot
   1. 自动配置、开箱即用
   2. 整合web
   3. 整合数据库（事务问题）
   4. 整合权限
      1. Shiro
      2. Spring Security
   5. 整合各种中间件：缓存、MQ、RPC框架、NIO框架等

ORM层框架

MyBatis：

分库分表

1. MyCat
2. Sharding-JDBC
3. Sharding-Sphere

Redis缓存

1. 5大数据类型
2. 事务
3. 消息通知
4. 管道
5. 持久化
6. 集群

消息队列

RocketMQ

1. 基础组成
2. 支持集群模式
3. 消费保证
4. 高可用
5. 消息去重
6. 分布式事务
7. 完整的一个调用链路
8. 消息重试
9. 消息积压

RabbitMQ

Kafka

RPC框架

Dubbo

1. Netty
2. 服务暴露过程
3. 服务引用
4. SPI
5. 容错机制
6. 降级
7. 负载均衡
8. 选举算法
9. 协议

Spring Cloud

搜索引擎

1. ElasticSearch
2. Solr

分布式/微服务

服务发现/注册

1. Eureka
2. Consul
3. Nacos

Zookeeper

1. 选举机制
2. 过半机制
3. 预提交

网关

1. Zuul
2. GateWay

宏服务？？？

这个不是什么学习路线，我在写这篇文章的时候看到了一则新闻，说是：2020 年 4 月 6 日，Uber 支付体验平台的工程经理 Gergely Orosz 发布推文表示其团队的架构方向已经发生了变化，放弃微服务，转而使用宏服务。

4 月 6 日，Uber 支付体验平台的工程经理 Gergely Orosz 发布推文表示其团队的架构方向已经发生了变化，放弃微服务，转而使用宏服务。

Gergely Orosz 表示：“最早，Uber 通过构建微服务来完成很小的需求或功能，以至于出现了很多由一个人构建维护的微服务。这些微服务的存在给我们带来了新的复杂性和挑战，例如监控、测试、持续集成 / 持续交付（CI/CD）、服务级别协议（SLA）、跨所有微服务的库版本（安全和时区问题）等等。”

因此，在创建新平台的时候，Uber 支付体验团队对新服务进行了更加深思熟虑的规划：不再只是完成一件事，而是使其服务于一项业务功能，由 5-10 个工程师负责维护。Gergely Orosz 把这样的服务规划称之为宏服务。

个人观点，看他这么说，宏服务应该也只是微服务过来的，但是整体的架构会发生改变，但是不管怎么说，身为一名程序员是真的需要去留意这些东西的，毕竟技术这种东西更新很快，我们也不过是普普通通的大学生，现在只是在打好基础，但是时间也就三年，这段时间要是没有把当前的前沿技术学好将来哪有机会去一线互联网公司继续研究新技术甚至为技术的研发做贡献是吧？

A）、跨所有微服务的库版本（安全和时区问题）等等。”

因此，在创建新平台的时候，Uber 支付体验团队对新服务进行了更加深思熟虑的规划：不再只是完成一件事，而是使其服务于一项业务功能，由 5-10 个工程师负责维护。Gergely Orosz 把这样的服务规划称之为宏服务。

个人观点，看他这么说，宏服务应该也只是微服务过来的，但是整体的架构会发生改变，但是不管怎么说，身为一名程序员是真的需要去留意这些东西的，毕竟技术这种东西更新很快，我们也不过是普普通通的大学生，现在只是在打好基础，但是时间也就三年，这段时间要是没有把当前的前沿技术学好将来哪有机会去一线互联网公司继续研究新技术甚至为技术的研发做贡献是吧？

最后，引用一句古语：⚪越大，它的周长就越大；人掌握的知识越多，发现不会的也就越多。