简介《Java学习路线》PDF 面向Java初学者及希望系统进阶的后端开发者用一条从语言基础到工程落地的路径解决知识点零散、学习顺序不清的问题。内容按Java语法与面向对象、JVM与GC调优、并发编程、数据结构与算法、计算机网络、数据库与SQL、Web开发、Spring生态、微服务、前端基础、研发工具、Linux、设计模式等模块展开并延伸到任务调度、链路追踪、ELK日志分析及Docker/Kubernetes容器化形成较完整的后端知识图谱。资源包为1个PDF文件大小约92KB轻量便于随时查阅适合按模块制定计划或在项目中查漏补缺。已有492人学习可帮助读者理清从入门到后端开发的能力层级、技术栈关联与进阶方向并结合实际项目巩固重点知识。1. 一张后端知识地图Java 学习路线为什么按「层」切而不是按「书」切多数人的 Java 学习路线是从一本语法书起步的把集合和 IO 啃完就以为地基打完了真进项目才发现还要写 SQL、配 Nginx、解释为什么加了索引还是慢。这份路线图真正的价值不在技术名词的数量而在它按调用链分层语言与运行时在最底下框架与中间件居中分布式与工程化在最上面算法、网络、操作系统像钢筋一样贯穿三层。按层复习的好处是每一层都能回答“上一层凭什么调用我”而不是把 JVM、Spring、消息队列背成三座互不相连的孤岛。已经在写业务代码的人可以拿它当查漏清单准备面试的人可以拿它当追问路径。2. 语言与运行时底座语法、JVM、并发与算法这四块怎么串这一层是整张图里最容易被低估的部分。语法书翻完只需两周但容器源码、JVM 内存布局、并发可见性这些问题往往要花掉几个月才能真正讲明白。梳理下来会发现这一层的知识点不是并列关系而是层层递进语法决定你能不能写出来容器和泛型决定代码质量JVM 决定你知道程序在机器上怎么跑并发决定你在多核场景下会不会写出看起来对、跑起来错的代码。算法与网络、操作系统则是面试与排查问题的公共底座。2.1 语言基本功语法之后真正拉开差距的是容器、泛型与异常基础语法、面向对象、接口这几块几乎没有复习价值会就是会不会也写不出能跑的代码。真正需要反复过的是容器体系List、Map、Set 三大家族的实现差异决定了你在十万级数据量下是毫秒还是秒级响应。最典型的对比是 ArrayList 与 LinkedList很多人背了“链表插入快”就无脑选后者实际上头部插入之外LinkedList 的随机访问和缓存局部性都更差绝大多数业务场景 ArrayList 反而更稳。容器底层结构典型适用场景复习时要能讲清的点ArrayList动态数组读多写少、按下标访问扩容倍数、1.5 倍与拷贝成本LinkedList双向链表频繁头尾增删、队列语义为何实际项目里用得少HashMap数组 链表 红黑树通用键值存储负载因子 0.75、树化阈值 8 与退化阈值 6TreeMap红黑树需要有序遍历或范围查询与 LinkedHashMap 的顺序语义区别ConcurrentHashMap分段思想演进到 CAS synchronized多线程共享缓存1.8 之后为何放弃 Segment泛型和反射是另一个分水岭。泛型擦除意味着运行时拿不到ListString里的 String这直接解释了为什么不能new T[]、为什么重载f(ListString)和f(ListInteger)会编译失败。反射和注解则构成了所有框架的地基Spring 扫描注解、MyBatis 映射字段、JSON 序列化取属性全都走的是反射这条链理解了Class、Method、Field三件套看框架源码才不至于全程懵。异常处理要分清 checked 与 unchecked 的边界业务可恢复的用受检异常编程错误用运行时异常吞异常和catch (Exception e) {}是代码评审里的高频扣分项。I/O 部分重点不在会写FileInputStream而在理解 BIO、NIO、多路复用的模型差异这块和后面 Netty、Tomcat 的连接器设计是同一套知识。2.2 JVM 与并发能画出来才算真会背参数是最低配JVM 的复习顺序建议是类加载机制 → 运行时数据区 → 垃圾回收 → 性能监控与调优。类加载五个阶段中验证、准备、解析容易被跳过但“准备阶段给静态变量赋零值、初始化阶段才赋真实值”这个细节是无数道面试题的源头。双亲委派模型要能说清它解决了什么问题同一个类不被重复加载、核心类库不被篡改以及为什么 Tomcat、热部署这些场景要打破它。运行时数据区里堆和虚拟机栈的区别几乎人人会背真正的分水岭是能不能说清一个方法调用发生时栈帧里发生了什么、对象在哪一刻从新生代进入老年代、方法区在 1.8 之后为什么换成了元空间。垃圾回收部分不要只记“标记清除、复制、标记整理”三个词要能把分代假设和收集器对应起来新生代对象朝生夕灭所以用复制算法老年代存活率高所以用标记整理CMS 追求低停顿但会产生碎片G1 用 Region 划分把停顿做成可预测的。提示调优题的答题顺序永远是“先定位问题再改参数”直接报-Xmx数值的答案基本会被追问穿。工具层面jps看进程、jstat -gc看回收频率和耗时、jmap导出堆快照、jstack抓线程栈这四个足够应付绝大多数线上排查。调优之前先问三个问题是 GC 频繁还是单次停顿长是内存泄漏还是内存不足是锁竞争还是 CPU 打满答案不同改的参数完全不同。并发部分的知识密度最高。JMM 定义了主内存与工作内存的抽象volatile保证可见性和禁止指令重排但不保证原子性synchronized保证原子性、可见性和有序性。happens-before 规则是判断“这段代码在多线程下有没有问题”的推理工具比背结论可靠得多。锁升级路径无锁 → 偏向锁 → 轻量级锁 → 重量级锁要能对应到具体的竞争场景AQS 的 state 与 CLH 队列则是理解ReentrantLock、CountDownLatch、Semaphore的统一入口。线程池是这一节最该动手写一遍的东西七个参数少一个都答不完整// 手动创建线程池避免 Executors 工厂方法的无界队列风险 ThreadPoolExecutor pool new ThreadPoolExecutor( 4, // corePoolSize常驻核心线程数 8, // maximumPoolSize峰值可扩到多少 60L, TimeUnit.SECONDS, // 非核心线程空闲回收时间 new ArrayBlockingQueue(200), // 有界队列防止任务无限堆积 new ThreadFactory() { // 自定义线程名方便 jstack 定位 private int i 0; public Thread newThread(Runnable r) { return new Thread(r, biz-pool- i); } }, new ThreadPoolExecutor.CallerRunsPolicy() // 满了之后回退给调用线程 );这段配置的逻辑是核心 4 线程先顶着队列积压到 200 之后再扩到 8 线程还满就触发拒绝策略。参数怎么改取决于任务类型CPU 密集型大致设成核数加一IO 密集型可以放大到核数的数倍但前提是队列必须有界Executors.newFixedThreadPool的无界队列在流量突增时会把内存吃干净这是血泪经验级别的坑。四种拒绝策略里CallerRunsPolicy适合能容忍降速但不能丢任务的场景AbortPolicy适合必须快速失败的场景。2.3 算法、网络与操作系统被当成公共课其实是排查问题的底层数据结构与算法的复习要区分两条线一条是面试线重点是复杂度分析、二分边界、链表操作、二叉树遍历、动态规划的状态定义另一条是工程线重点是能不能判断出这段循环是 O(n²) 从而在数据量上来前改掉。排序算法不必默写全部但要能说清快排为什么平均 O(n log n) 而最坏退化到 O(n²)、归并为什么稳定、堆排序为什么适合求 TopK。算法思想典型题型复习重点二分查找有序数组查找、边界问题左右区间的开闭写法必须统一双指针链表、数组去重指针移动条件与终止判断动态规划背包、最长子序列状态定义与转移方程不是背题回溯排列组合、棋盘类剪枝条件决定会不会超时贪心区间调度能否证明局部最优推出全局最优计算机网络的重点是 TCP 与 HTTP 两条线。三次握手要能解释“为什么不是两次”四次挥手要能解释 TIME_WAIT 存在的意义HTTP 要能从报文结构讲到 1.1 的持久连接、2 的多路复用、HTTPS 的握手与证书校验。Cookie 与 Session 的区别背后是“状态放在客户端还是服务端”的架构选择再往后延伸到 Token 与无状态鉴权这条线索能一直连到微服务的网关鉴权。操作系统部分不用啃教材抓住进程与线程的区别、上下文切换的成本、死锁的四个必要条件、I/O 模型演进这几块就够了它们和 JVM 线程模型、Netty 的 Reactor 模式是同一套语言。3. 框架与中间件层Spring、缓存、消息队列与数据访问的分工这一层的复习目标是建立“谁负责解决什么问题”的直觉。很多人能说出 Spring 有 IoC 和 AOP却说不出一个请求从进网关到落库到底经过了哪些组件能背出 Redis 五种数据类型却说不清什么场景该用它而不是本地缓存。梳理下来这一层的所有技术都在回答四个问题对象谁来管、数据放哪里、服务之间怎么通信、数据库压力怎么卸。3.1 Spring 家族一条从 Bean 容器到自动配置的完整链Spring 的核心只有两件事IoC 容器负责对象的生命周期和依赖注入AOP 负责把日志、事务、权限这类横切逻辑从业务代码里抽出来。Bean 的生命周期是面试高频区要能按顺序说出实例化、属性填充、BeanPostProcessor前置处理、初始化方法、后置处理、使用、销毁这几步并且知道PostConstruct和InitializingBean在链条里的位置。循环依赖是另一个必考点。三级缓存的设计意图是一级放成品 Bean二级放半成品三级放能生成半成品的工厂从而在 A 依赖 B、B 又依赖 A 时让 B 拿到 A 的早期引用。但要注意构造器注入的循环依赖三级缓存也救不了Async这类需要代理的场景也可能绕不过去这解释了为什么官方更推荐构造器注入加设计上的解耦。Spring MVC 要抓住 DispatcherServlet 这一个入口请求进来先过 HandlerMapping 找处理器再过 HandlerAdapter 执行返回值经 ViewResolver 或消息转换器输出。把这条链画一遍拦截器、参数绑定、全局异常处理各自插在哪一步就都清楚了。Spring Boot 的自动配置是这层的价值高点。SpringBootApplication拆开是三个注解其中EnableAutoConfiguration通过AutoConfiguration.imports新版本或spring.factories旧版本加载候选配置类再用ConditionalOnClass、ConditionalOnMissingBean这类条件注解决定要不要生效。理解了这一层你就能回答“为什么引了 starter 就有默认数据源而我定义了一个 DataSource 之后默认的就不生效了”。// 自定义一个 starter 的核心配置类演示条件装配的思路 Configuration ConditionalOnClass(name com.example.demo.SomeClient) // 类路径存在才生效 public class DemoAutoConfiguration { Bean ConditionalOnMissingBean // 用户自己定义了就不再覆盖 public SomeClient someClient(DemoProperties props) { // props 绑定 application.yml 里 demo.* 开头的配置 return new SomeClient(props.getEndpoint(), props.getTimeout()); } }这段代码的关键在条件注解的顺序先判断依赖是否存在再判断用户是否已经自定义。整条自动配置链的设计哲学是“约定优于配置但任何时候用户的手动配置优先级更高”这也是排查“我的配置为什么不生效”时的第一直觉来源。事务是 Spring 里最容易出错的部分。Transactional的传播行为有七种常用的只有REQUIRED有则加入、无则新建和REQUIRES_NEW挂起当前、独立新建两种。要记住几个失效场景同类内部方法直接调用不走代理、异常被 catch 掉不回滚、非 public 方法在默认代理模式下不生效、以及只对运行时异常回滚而受检异常默认不回滚。这几个点比背传播行为表实用得多。权限框架方面Shiro 轻量、上手快适合单体应用Spring Security 与 Spring 生态结合更紧适合需要 OAuth2、SSO 的场景。复习时不必两边都钻抓住认证与授权分离、过滤器链的执行顺序这两条主干即可。3.2 缓存与消息队列先想清楚解决什么再挑组件缓存的第一课不是 Redis 命令而是“缓存放哪一层”。本地缓存如基于 Caffeine 的方案纳秒级、无网络开销但多实例之间不一致分布式缓存Redis、Memcached一致性好但多一跳网络。常见做法是本地缓存扛热点、分布式缓存兜底两级缓存之间用失效通知同步。Redis 的复习顺序建议是五种数据类型的适用场景 → 过期与淘汰策略 → 持久化 → 高可用 → 常见问题。String 适合计数和序列化对象Hash 适合存对象的部分字段更新List 适合简单队列Set 适合去重和交并集ZSet 适合排行榜和延时队列。持久化要能说清 RDB 是快照、AOF 是追加日志、混合持久化怎么折中。缓存穿透、击穿、雪崩三个词的应对手段要能一一对应布隆过滤器或空值缓存防穿透互斥锁或逻辑过期防击穿随机过期时间加多级缓存防雪崩。注意分布式锁的可靠性依赖“加锁与过期必须原子”手写setnx再expire中间会留出窗口用一条带 NX 和 EX 参数的命令才能闭环。消息队列的价值只有三个词解耦、异步、削峰。所有 MQ 的选型讨论都围绕这三点展开。RabbitMQ 路由灵活、延迟低适合业务解耦和复杂路由Kafka 吞吐极高、天然支持分区顺序适合日志与埋点这类大数据量场景RocketMQ 在事务消息、顺序消息、延时消息上支持较完整适合订单、支付这类对可靠性要求高的链路。消息可靠性要按“生产端、存储端、消费端”三段拆生产端用发送确认机制防止丢消息存储端靠刷盘策略和副本保证不丢消费端用 ACK 加手动确认保证处理完再提交位点。但只要引入重试幂等就成了必答题消息带唯一业务 ID消费端用去重表或状态机判断是否已处理。顺序消息则要保证同一业务键路由到同一分区且消费端单线程处理。3.3 数据访问与 RPCORM、连接池、分库分表和远程调用数据访问层的复习要从 SQL 往上走而不是从框架往下走。SQL 部分的核心是索引B 树为什么适合做索引、聚簇索引与二级索引的区别、回表是什么、最左前缀原则为什么成立、覆盖索引怎么用。explain要能看懂type、key、rows、Extra四个字段看到Using filesort和Using temporary就知道该优化了。-- 联合索引 (user_id, status, created_at) 的典型用法 EXPLAIN SELECT id, amount FROM orders WHERE user_id 10086 -- 命中索引第一列 AND status 1 -- 命中第二列 AND created_at 2024-01-01 -- 第三列用于范围之后的条件不再走索引 ORDER BY created_at DESC;这段查询能走索引的原因是条件顺序与索引列顺序一致且id、amount若在索引里就能避免回表。最容易踩的坑是范围查询之后的列失效以及status这种区分度极低的列单独建索引几乎没有收益。事务与隔离级别是数据库部分的深水区。四种隔离级别要能对应到具体现象读未提交会脏读读已提交会不可重复读可重复读在标准定义下仍可能幻读串行化全锁上但性能最差。MySQL 的默认级别是可重复读并通过 MVCC 加间隙锁在很大程度上规避了幻读这个“标准定义”与“具体实现”的差异是最容易被追问的地方。ORM 框架方面MyBatis 胜在 SQL 可控、易于优化JPA 和 Hibernate 胜在对象映射和跨库移植。连接池选型上Druid 带监控、HikariCP 性能好选哪个不如搞清楚“连接池大小怎么定”这个真问题连接数不是越大越好超过数据库承载能力后只会互相争抢。分库分表属于“不到万不得已不用”的手段真要用先想清楚分片键怎么选、跨分片查询和聚合怎么处理、扩容时数据怎么迁移分片中间件如基于代理的 MyCat 与基于客户端的 ShardingSphere只是把这些问题换了个地方暴露。RPC 框架的复习主线是序列化协议、通信框架、服务注册发现、负载均衡、容错。Dubbo 在国内使用广gRPC 依托 HTTP/2 和 Protobuf 适合多语言场景Thrift 胜在跨语言代码生成而 Netty 是这些框架底下的通信底座理解它的 Reactor 线程模型和零拷贝机制看任何 RPC 框架的源码都能对上号。4. 分布式与工程化微服务组件、运维体系与工具链到了这一层知识点从“怎么写代码”变成“怎么让一堆服务稳定地跑起来”。这一层的复习难点不在名词多而在于每个组件都要能回答“去掉它行不行、换一个行不行”。梳理下来微服务的所有组件都在解决两类问题服务之间怎么找到彼此并可靠通信以及出了问题怎么快速定位和止损。4.1 微服务六件套注册发现、网关、负载均衡、熔断、配置与分布式事务服务注册与发现是微服务的第一块砖。Eureka 偏向 AP节点间异步复制网络分区时仍能提供服务但可能读到旧数据Zookeeper 偏向 CP选举期间不可用Consul 与 Nacos 都支持两种模式切换Nacos 还额外提供配置中心能力。选型的关键不是谁更先进而是业务能否接受短暂的注册表不一致。网关是所有流量的统一入口承担路由、鉴权、限流、日志聚合四件事。Zuul 1 基于阻塞模型Spring Cloud Gateway 基于响应式模型在高并发下后者更有优势。网关鉴权的典型做法是在网关统一校验 Token 并把用户信息透传到下游避免每个服务重复实现。负载均衡分客户端和服务端两种。Ribbon 属于客户端负载均衡调用方自己持有服务列表并选择实例优点是少一跳、缺点是列表更新有延迟服务端负载均衡由中间代理完成省心但多一次转发。轮询、加权、最少连接、一致性哈希几种策略的差异要能对应到场景会话粘性用一致性哈希机器性能不均用加权。熔断与降级解决的是雪崩问题。Hystrix 的隔离方式有线程池隔离和信号量隔离两种前者彻底但有线程切换开销后者轻量但无法真正超时中断。核心参数有三个超时时间、熔断窗口内的失败率阈值、半开状态的试探请求数。很多团队配了这些参数却没验证过链路结果真出故障时熔断没触发这是典型的“配置了等于没配”。配置中心的价值在于“改配置不发版”。Config、Apollo、Nacos 三者的差异主要在推拉模式、灰度能力、权限模型上。复习时要能说清一次配置变更的生效路径改配置 → 发布 → 客户端监听或轮询 → 本地刷新 → 是否需要重启。分布式事务是最容易背成名词表的一节。2PC 与 3PC 是强一致路线靠协调者两阶段提交代价是同步阻塞和协调者单点XA 是 2PC 的标准化实现TCC 是业务层的补偿模式需要写 Try、Confirm、Cancel 三个方法侵入性强但性能好SAGA 把长事务拆成一系列本地事务加补偿本地消息表靠可靠消息加消费端幂等实现最终一致Seata 的 AT 模式通过解析 SQL 生成反向快照来简化补偿逻辑。真正要理解的是不要问哪个方案最好要问这条业务链路能不能接受最终一致、补偿失败的兜底由谁来做。4.2 服务器与运维Nginx、Tomcat、CI/CD、日志与链路追踪Nginx 的复习重点是反向代理、负载均衡、静态资源服务和限流。最基本的配置要能看懂 upstream 块和 location 匹配优先级proxy_pass结尾带不带斜杠会改变路径拼接结果这是部署时最常见的 404 来源。# nginx.conf 片段把 /api/ 前缀转发到后端集群并做简单的连接数限流 upstream backend_pool { least_conn; # 最少连接策略适合请求耗时差异大的场景 server 127.0.0.1:8081 weight2; # 权重高承接更多流量 server 127.0.0.1:8082; } limit_req_zone $binary_remote_addr zoneapi_limit:10m rate20r/s; location /api/ { limit_req zoneapi_limit burst40 nodelay; # 允许突发 40 个其余排队或拒绝 proxy_pass http://backend_pool; # 注意此处不带路径会保留 /api/ 前缀 proxy_set_header X-Real-IP $remote_addr; # 透传真实客户端 IP }这段配置的意图是上游按权重分配流量least_conn让慢请求少的机器多接活限流按 IP 每秒 20 个请求突发允许 40 个。实际部署时最容易踩的坑是proxy_pass的斜杠语义和location的匹配优先级精确匹配优先于前缀匹配正则匹配又有自己的顺序配置改完必须用nginx -t验证。Tomcat、Jetty、Undertow 三者的差异在连接器模型和线程模型上复习时抓住“连接数、工作线程数、最大排队数”三个参数以及“为什么高并发下 Tomcat 的阻塞 IO 会拖垮线程池”这个核心问题就能理解 Netty 这类 NIO 框架为什么存在。持续集成与持续发布是工程化的关键能力。Jenkins 流水线的典型阶段是拉代码、构建、单测、代码质量检查、打镜像、部署。代码质量检查重点看重复率、圈复杂度和阻断级别的静态缺陷不要一上来就开全量规则否则老项目会永远红着。日志收集走采集、缓冲、存储、检索四段链路追踪则靠 TraceID 串联核心是“一次请求的上下文如何跨线程和跨服务传递”。4.3 研发工具与前端Git、Maven、Docker、K8s 与前端三大件工具链部分经常被当成“用熟就行”但真出问题时全靠这些细节救场。Git 要能说清工作区、暂存区、本地仓库的关系merge与rebase的取舍分支历史清晰度 vs 提交记录线性以及reset三种模式的区别。团队协作中最容易翻车的是“合并了别人的强制推送”和“误提交敏感配置”前者靠保护分支规避后者靠提交前钩子和gitignore兜底。Maven 的复习点是生命周期、依赖调解和私服。依赖冲突有两套原则最短路径优先和第一声明优先冲突排查靠mvn dependency:tree。多模块项目的依赖管理要靠父 POM 的dependencyManagement统一版本避免子模块各写各的版本号。容器化是这一层必须动手的部分。Docker 的镜像分层机制决定了 Dockerfile 的写法把变化频率低的指令放前面把拷贝代码放后面才能吃到构建缓存。多阶段构建可以把编译环境和运行环境分开最终镜像只留运行时产物。# 多阶段构建编译阶段用带完整 JDK 的镜像运行阶段只留精简版 FROM maven:3.9-eclipse-temurin-17 AS build WORKDIR /src COPY pom.xml . RUN mvn -q dependency:go-offline # 先拉依赖命中缓存 COPY src ./src RUN mvn -q package -DskipTests FROM eclipse-temurin:17-jre # 运行时镜像不含编译工具 WORKDIR /app COPY --frombuild /src/target/app.jar app.jar ENTRYPOINT [java, -jar, app.jar]这段写法的关键在于前后两段分离依赖下载单独成层源码修改不会导致依赖重新下载运行镜像不带 Maven 和编译器体积和攻击面都更小。Kubernetes 则要抓住 Pod、Deployment、Service、Ingress 四个基本对象的关系理解“声明式”与“自愈”的含义你描述期望状态控制器负责把实际状态拉回来。前端部分不必深入但三大件HTML、JavaScript、CSS至少要能改页面、调接口、看控制台报错。Ajax 与 fetch 的区别、跨域的本质同源策略加浏览器拦截、模板引擎与前后端分离的演进这几条理解了和后端联调时就不会把所有问题都推给对方。5. 易漏易错点五个“以为自己会了”的高频坑每个学完路线图的人都会产生一种错觉名词都认识就等于掌握了。实际上真正区分水平的是那些“能讲清细节”的地方。梳理下来下面五个坑几乎人人都踩过共同的成因是学习时停留在“名词层”没有下沉到“机制层”。5.1 并发会背 synchronized说不清 happens-before易漏点能写出synchronized和volatile的用法但被问到“两个线程先后写同一个变量另一个线程何时能看到”时答不上来。为什么漏JMM 是抽象模型没有对应的代码形态看书时容易被当成一段描述性文字跳过。而可见性问题在单机小流量下几乎不复现出问题时又表现为玄学般的偶发。怎么补把 happens-before 的几条规则程序顺序、监视器锁、volatile 变量、线程启动与终止、传递性抄在一张纸上然后拿三个真实场景去套双重检查锁为什么要给实例加volatile、final域为什么能保证构造完成后的可见性、线程池提交任务前的写入为什么对工作线程可见。套不通就回去重读直到每条规则都能找到一个真实代码片段。5.2 JVM参数背了一堆不会读 GC 日志易漏点能说出-Xms、-Xmx、-Xmn、-XX:MetaspaceSize的含义但给一份 GC 日志不知道从哪看起。为什么漏调优场景在真实项目里出现频率低大多数人没有亲手制造过一次内存溢出自然没有看过日志。怎么补本地起一个会持续创建对象的 Demo把堆设小一点用-Xlog:gc*或旧版本的-XX:PrintGCDetails打印日志然后加jmap -histo:live看对象分布再用jmap -dump导出快照最后用工具打开看引用链。这一套走完一遍你会突然明白“内存泄漏”和“内存不足”在日志里的表现完全不同。整个过程不追求记住每个参数追求的是排查动作形成肌肉记忆。5.3 数据库隔离级别倒背如流不知道 MySQL 的 RR 是怎么防幻读的易漏点四种隔离级别和对应现象能默写但被追问“MySQL 默认 RR 为什么在标准里允许幻读、它又怎么规避的”就卡住。为什么漏教材讲的是 SQL 标准而实际实现是另一套逻辑两者的差异不在课本的同一页上。怎么补把 MVCC 的 ReadView、undo log 版本链、当前读与快照读的区别串起来看一遍然后自己开两个会话做实验会话 A 开启事务查询一次会话 B 插入并提交会话 A 再查一次看结果接着在会话 A 里执行select ... for update再看一次。实验比背书有效十倍因为你能亲眼看到快照读和当前读返回不同结果。间隙锁的作用也要在这个实验里一并体会。5.4 Spring循环依赖能说出三级缓存说不清 AOP 为什么在自调用时失效易漏点知道 AOP 基于动态代理但写了一个同类内部方法互调的代码发现事务注解没生效不知道原因。为什么漏代理机制是“容器替你做的事”写业务代码时看不见所以从来不会想到去验证。怎么补先明确一个判断标准——只有通过代理对象调用才会走增强逻辑this.method()走的是原始对象。然后在同一个类里写一个方法调用带事务注解的方法分别在同类内调用和从外部注入调用两种方式下观察结果差异会非常直观。真要解决无非三种做法拆到另一个 Bean、注入自身代理、用AopContext配合暴露代理。理解了这个Async、Cacheable失效的问题也就一并解决了。5.5 分布式事务方案名字全知道讲不清一条下单链路的事务边界易漏点能列出 2PC、TCC、SAGA、本地消息表、AT 各自的原理但给一条包含下单、扣库存、发优惠券、发通知的链路说不清该在哪切分事务。为什么漏分布式事务本质是业务建模问题不是技术选型问题而大多数资料只讲方案不讲建模。怎么补拿一条真实的业务链路把每个步骤标注三个属性是否强一致、能否补偿、失败后谁兜底。你会发现大部分步骤其实只需要最终一致真正需要强一致的可能只有“扣库存与创建订单”这一小段。标完之后再选方案通常比先选方案再硬套要省事得多。同时要盯住三个工程细节幂等键怎么设计、补偿失败后进哪张表、人工介入的入口在哪。6. 查漏补缺把路线图变成一张能打勾的复习清单复习到最后阶段最有效的方式不是再看一遍资料而是拿一张清单逐项自检。自检的颗粒度决定效果只写“JVM”三个字的清单等于没写必须写到“能用 jstat 判断是 Young GC 频繁还是 Full GC 频繁”这种可验证的动作级别。我习惯把每一项分成三个层级能讲清能向别人解释原理、能写出能手写关键代码或命令、能调通在本地跑起来并看到结果。三层都过的项可以直接划掉只过前两层的要补动手一层都没过的回炉。下面这张表是我自己用的分组样例可以直接照着扩成完整版。模块自检动作达标标准容器手写 HashMap 的 put 与扩容逻辑能解释树化阈值与扩容时机并发手写一个有界线程池并压测能说明拒绝策略触发条件JVM用 jmap 导出快照并定位大对象能说出对象为何晋升老年代数据库用 explain 优化一条慢查询能判断回表与索引失效原因Spring复现一次事务失效并修复能解释代理与自调用的关系微服务画一次请求经过网关到落库的全链路能标出每个组件的失败点工程化写一条从提交到部署的流水线能说明每个阶段的失败处理执行这张表时有两个经验值得记住。第一个是限时每个自检动作给 40 分钟超时就标记为“不熟”不要在一个点上耗一整天那样复习节奏会崩。第二个是留痕每个动作写三行笔记一行写结论一行写踩到的坑一行写下次怎么快速回忆。攒到几十条之后这份笔记本身就是最好的考前材料。# 复习环境自检脚本示例一条条确认工具链是否可用 java -version 21 | head -n 1 # 确认 JDK 版本与路线图一致 mvn -v | head -n 1 # 确认构建工具可用 docker ps /dev/null echo docker ok # 容器环境是否就绪 jps # 能列出 Java 进程才谈得上后续排查这个脚本的意义不在命令本身而在建立“环境先于知识”的意识很多次复习卡住其实是 JDK 版本不对、Maven 拉不到依赖、Docker 没启动这类环境问题把时间浪费在了错误的方向上。从那以后我每次复习任何一块新内容都会强制走一遍“讲一遍、写一遍、跑一遍”的流程哪怕是最熟的集合和线程池也不例外因为翻车往往就发生在自以为最熟的地方。希望帮到你。本文还有配套的精品资源点击获取
简介《Java学习路线》PDF 面向Java初学者及希望系统进阶的后端开发者用一条从语言基础到工程落地的路径解决知识点零散、学习顺序不清的问题。内容按Java语法与面向对象、JVM与GC调优、并发编程、数据结构与算法、计算机网络、数据库与SQL、Web开发、Spring生态、微服务、前端基础、研发工具、Linux、设计模式等模块展开并延伸到任务调度、链路追踪、ELK日志分析及Docker/Kubernetes容器化形成较完整的后端知识图谱。资源包为1个PDF文件大小约92KB轻量便于随时查阅适合按模块制定计划或在项目中查漏补缺。已有492人学习可帮助读者理清从入门到后端开发的能力层级、技术栈关联与进阶方向并结合实际项目巩固重点知识。1. 一张后端知识地图Java 学习路线为什么按「层」切而不是按「书」切多数人的 Java 学习路线是从一本语法书起步的把集合和 IO 啃完就以为地基打完了真进项目才发现还要写 SQL、配 Nginx、解释为什么加了索引还是慢。这份路线图真正的价值不在技术名词的数量而在它按调用链分层语言与运行时在最底下框架与中间件居中分布式与工程化在最上面算法、网络、操作系统像钢筋一样贯穿三层。按层复习的好处是每一层都能回答“上一层凭什么调用我”而不是把 JVM、Spring、消息队列背成三座互不相连的孤岛。已经在写业务代码的人可以拿它当查漏清单准备面试的人可以拿它当追问路径。2. 语言与运行时底座语法、JVM、并发与算法这四块怎么串这一层是整张图里最容易被低估的部分。语法书翻完只需两周但容器源码、JVM 内存布局、并发可见性这些问题往往要花掉几个月才能真正讲明白。梳理下来会发现这一层的知识点不是并列关系而是层层递进语法决定你能不能写出来容器和泛型决定代码质量JVM 决定你知道程序在机器上怎么跑并发决定你在多核场景下会不会写出看起来对、跑起来错的代码。算法与网络、操作系统则是面试与排查问题的公共底座。2.1 语言基本功语法之后真正拉开差距的是容器、泛型与异常基础语法、面向对象、接口这几块几乎没有复习价值会就是会不会也写不出能跑的代码。真正需要反复过的是容器体系List、Map、Set 三大家族的实现差异决定了你在十万级数据量下是毫秒还是秒级响应。最典型的对比是 ArrayList 与 LinkedList很多人背了“链表插入快”就无脑选后者实际上头部插入之外LinkedList 的随机访问和缓存局部性都更差绝大多数业务场景 ArrayList 反而更稳。容器底层结构典型适用场景复习时要能讲清的点ArrayList动态数组读多写少、按下标访问扩容倍数、1.5 倍与拷贝成本LinkedList双向链表频繁头尾增删、队列语义为何实际项目里用得少HashMap数组 链表 红黑树通用键值存储负载因子 0.75、树化阈值 8 与退化阈值 6TreeMap红黑树需要有序遍历或范围查询与 LinkedHashMap 的顺序语义区别ConcurrentHashMap分段思想演进到 CAS synchronized多线程共享缓存1.8 之后为何放弃 Segment泛型和反射是另一个分水岭。泛型擦除意味着运行时拿不到ListString里的 String这直接解释了为什么不能new T[]、为什么重载f(ListString)和f(ListInteger)会编译失败。反射和注解则构成了所有框架的地基Spring 扫描注解、MyBatis 映射字段、JSON 序列化取属性全都走的是反射这条链理解了Class、Method、Field三件套看框架源码才不至于全程懵。异常处理要分清 checked 与 unchecked 的边界业务可恢复的用受检异常编程错误用运行时异常吞异常和catch (Exception e) {}是代码评审里的高频扣分项。I/O 部分重点不在会写FileInputStream而在理解 BIO、NIO、多路复用的模型差异这块和后面 Netty、Tomcat 的连接器设计是同一套知识。2.2 JVM 与并发能画出来才算真会背参数是最低配JVM 的复习顺序建议是类加载机制 → 运行时数据区 → 垃圾回收 → 性能监控与调优。类加载五个阶段中验证、准备、解析容易被跳过但“准备阶段给静态变量赋零值、初始化阶段才赋真实值”这个细节是无数道面试题的源头。双亲委派模型要能说清它解决了什么问题同一个类不被重复加载、核心类库不被篡改以及为什么 Tomcat、热部署这些场景要打破它。运行时数据区里堆和虚拟机栈的区别几乎人人会背真正的分水岭是能不能说清一个方法调用发生时栈帧里发生了什么、对象在哪一刻从新生代进入老年代、方法区在 1.8 之后为什么换成了元空间。垃圾回收部分不要只记“标记清除、复制、标记整理”三个词要能把分代假设和收集器对应起来新生代对象朝生夕灭所以用复制算法老年代存活率高所以用标记整理CMS 追求低停顿但会产生碎片G1 用 Region 划分把停顿做成可预测的。提示调优题的答题顺序永远是“先定位问题再改参数”直接报-Xmx数值的答案基本会被追问穿。工具层面jps看进程、jstat -gc看回收频率和耗时、jmap导出堆快照、jstack抓线程栈这四个足够应付绝大多数线上排查。调优之前先问三个问题是 GC 频繁还是单次停顿长是内存泄漏还是内存不足是锁竞争还是 CPU 打满答案不同改的参数完全不同。并发部分的知识密度最高。JMM 定义了主内存与工作内存的抽象volatile保证可见性和禁止指令重排但不保证原子性synchronized保证原子性、可见性和有序性。happens-before 规则是判断“这段代码在多线程下有没有问题”的推理工具比背结论可靠得多。锁升级路径无锁 → 偏向锁 → 轻量级锁 → 重量级锁要能对应到具体的竞争场景AQS 的 state 与 CLH 队列则是理解ReentrantLock、CountDownLatch、Semaphore的统一入口。线程池是这一节最该动手写一遍的东西七个参数少一个都答不完整// 手动创建线程池避免 Executors 工厂方法的无界队列风险 ThreadPoolExecutor pool new ThreadPoolExecutor( 4, // corePoolSize常驻核心线程数 8, // maximumPoolSize峰值可扩到多少 60L, TimeUnit.SECONDS, // 非核心线程空闲回收时间 new ArrayBlockingQueue(200), // 有界队列防止任务无限堆积 new ThreadFactory() { // 自定义线程名方便 jstack 定位 private int i 0; public Thread newThread(Runnable r) { return new Thread(r, biz-pool- i); } }, new ThreadPoolExecutor.CallerRunsPolicy() // 满了之后回退给调用线程 );这段配置的逻辑是核心 4 线程先顶着队列积压到 200 之后再扩到 8 线程还满就触发拒绝策略。参数怎么改取决于任务类型CPU 密集型大致设成核数加一IO 密集型可以放大到核数的数倍但前提是队列必须有界Executors.newFixedThreadPool的无界队列在流量突增时会把内存吃干净这是血泪经验级别的坑。四种拒绝策略里CallerRunsPolicy适合能容忍降速但不能丢任务的场景AbortPolicy适合必须快速失败的场景。2.3 算法、网络与操作系统被当成公共课其实是排查问题的底层数据结构与算法的复习要区分两条线一条是面试线重点是复杂度分析、二分边界、链表操作、二叉树遍历、动态规划的状态定义另一条是工程线重点是能不能判断出这段循环是 O(n²) 从而在数据量上来前改掉。排序算法不必默写全部但要能说清快排为什么平均 O(n log n) 而最坏退化到 O(n²)、归并为什么稳定、堆排序为什么适合求 TopK。算法思想典型题型复习重点二分查找有序数组查找、边界问题左右区间的开闭写法必须统一双指针链表、数组去重指针移动条件与终止判断动态规划背包、最长子序列状态定义与转移方程不是背题回溯排列组合、棋盘类剪枝条件决定会不会超时贪心区间调度能否证明局部最优推出全局最优计算机网络的重点是 TCP 与 HTTP 两条线。三次握手要能解释“为什么不是两次”四次挥手要能解释 TIME_WAIT 存在的意义HTTP 要能从报文结构讲到 1.1 的持久连接、2 的多路复用、HTTPS 的握手与证书校验。Cookie 与 Session 的区别背后是“状态放在客户端还是服务端”的架构选择再往后延伸到 Token 与无状态鉴权这条线索能一直连到微服务的网关鉴权。操作系统部分不用啃教材抓住进程与线程的区别、上下文切换的成本、死锁的四个必要条件、I/O 模型演进这几块就够了它们和 JVM 线程模型、Netty 的 Reactor 模式是同一套语言。3. 框架与中间件层Spring、缓存、消息队列与数据访问的分工这一层的复习目标是建立“谁负责解决什么问题”的直觉。很多人能说出 Spring 有 IoC 和 AOP却说不出一个请求从进网关到落库到底经过了哪些组件能背出 Redis 五种数据类型却说不清什么场景该用它而不是本地缓存。梳理下来这一层的所有技术都在回答四个问题对象谁来管、数据放哪里、服务之间怎么通信、数据库压力怎么卸。3.1 Spring 家族一条从 Bean 容器到自动配置的完整链Spring 的核心只有两件事IoC 容器负责对象的生命周期和依赖注入AOP 负责把日志、事务、权限这类横切逻辑从业务代码里抽出来。Bean 的生命周期是面试高频区要能按顺序说出实例化、属性填充、BeanPostProcessor前置处理、初始化方法、后置处理、使用、销毁这几步并且知道PostConstruct和InitializingBean在链条里的位置。循环依赖是另一个必考点。三级缓存的设计意图是一级放成品 Bean二级放半成品三级放能生成半成品的工厂从而在 A 依赖 B、B 又依赖 A 时让 B 拿到 A 的早期引用。但要注意构造器注入的循环依赖三级缓存也救不了Async这类需要代理的场景也可能绕不过去这解释了为什么官方更推荐构造器注入加设计上的解耦。Spring MVC 要抓住 DispatcherServlet 这一个入口请求进来先过 HandlerMapping 找处理器再过 HandlerAdapter 执行返回值经 ViewResolver 或消息转换器输出。把这条链画一遍拦截器、参数绑定、全局异常处理各自插在哪一步就都清楚了。Spring Boot 的自动配置是这层的价值高点。SpringBootApplication拆开是三个注解其中EnableAutoConfiguration通过AutoConfiguration.imports新版本或spring.factories旧版本加载候选配置类再用ConditionalOnClass、ConditionalOnMissingBean这类条件注解决定要不要生效。理解了这一层你就能回答“为什么引了 starter 就有默认数据源而我定义了一个 DataSource 之后默认的就不生效了”。// 自定义一个 starter 的核心配置类演示条件装配的思路 Configuration ConditionalOnClass(name com.example.demo.SomeClient) // 类路径存在才生效 public class DemoAutoConfiguration { Bean ConditionalOnMissingBean // 用户自己定义了就不再覆盖 public SomeClient someClient(DemoProperties props) { // props 绑定 application.yml 里 demo.* 开头的配置 return new SomeClient(props.getEndpoint(), props.getTimeout()); } }这段代码的关键在条件注解的顺序先判断依赖是否存在再判断用户是否已经自定义。整条自动配置链的设计哲学是“约定优于配置但任何时候用户的手动配置优先级更高”这也是排查“我的配置为什么不生效”时的第一直觉来源。事务是 Spring 里最容易出错的部分。Transactional的传播行为有七种常用的只有REQUIRED有则加入、无则新建和REQUIRES_NEW挂起当前、独立新建两种。要记住几个失效场景同类内部方法直接调用不走代理、异常被 catch 掉不回滚、非 public 方法在默认代理模式下不生效、以及只对运行时异常回滚而受检异常默认不回滚。这几个点比背传播行为表实用得多。权限框架方面Shiro 轻量、上手快适合单体应用Spring Security 与 Spring 生态结合更紧适合需要 OAuth2、SSO 的场景。复习时不必两边都钻抓住认证与授权分离、过滤器链的执行顺序这两条主干即可。3.2 缓存与消息队列先想清楚解决什么再挑组件缓存的第一课不是 Redis 命令而是“缓存放哪一层”。本地缓存如基于 Caffeine 的方案纳秒级、无网络开销但多实例之间不一致分布式缓存Redis、Memcached一致性好但多一跳网络。常见做法是本地缓存扛热点、分布式缓存兜底两级缓存之间用失效通知同步。Redis 的复习顺序建议是五种数据类型的适用场景 → 过期与淘汰策略 → 持久化 → 高可用 → 常见问题。String 适合计数和序列化对象Hash 适合存对象的部分字段更新List 适合简单队列Set 适合去重和交并集ZSet 适合排行榜和延时队列。持久化要能说清 RDB 是快照、AOF 是追加日志、混合持久化怎么折中。缓存穿透、击穿、雪崩三个词的应对手段要能一一对应布隆过滤器或空值缓存防穿透互斥锁或逻辑过期防击穿随机过期时间加多级缓存防雪崩。注意分布式锁的可靠性依赖“加锁与过期必须原子”手写setnx再expire中间会留出窗口用一条带 NX 和 EX 参数的命令才能闭环。消息队列的价值只有三个词解耦、异步、削峰。所有 MQ 的选型讨论都围绕这三点展开。RabbitMQ 路由灵活、延迟低适合业务解耦和复杂路由Kafka 吞吐极高、天然支持分区顺序适合日志与埋点这类大数据量场景RocketMQ 在事务消息、顺序消息、延时消息上支持较完整适合订单、支付这类对可靠性要求高的链路。消息可靠性要按“生产端、存储端、消费端”三段拆生产端用发送确认机制防止丢消息存储端靠刷盘策略和副本保证不丢消费端用 ACK 加手动确认保证处理完再提交位点。但只要引入重试幂等就成了必答题消息带唯一业务 ID消费端用去重表或状态机判断是否已处理。顺序消息则要保证同一业务键路由到同一分区且消费端单线程处理。3.3 数据访问与 RPCORM、连接池、分库分表和远程调用数据访问层的复习要从 SQL 往上走而不是从框架往下走。SQL 部分的核心是索引B 树为什么适合做索引、聚簇索引与二级索引的区别、回表是什么、最左前缀原则为什么成立、覆盖索引怎么用。explain要能看懂type、key、rows、Extra四个字段看到Using filesort和Using temporary就知道该优化了。-- 联合索引 (user_id, status, created_at) 的典型用法 EXPLAIN SELECT id, amount FROM orders WHERE user_id 10086 -- 命中索引第一列 AND status 1 -- 命中第二列 AND created_at 2024-01-01 -- 第三列用于范围之后的条件不再走索引 ORDER BY created_at DESC;这段查询能走索引的原因是条件顺序与索引列顺序一致且id、amount若在索引里就能避免回表。最容易踩的坑是范围查询之后的列失效以及status这种区分度极低的列单独建索引几乎没有收益。事务与隔离级别是数据库部分的深水区。四种隔离级别要能对应到具体现象读未提交会脏读读已提交会不可重复读可重复读在标准定义下仍可能幻读串行化全锁上但性能最差。MySQL 的默认级别是可重复读并通过 MVCC 加间隙锁在很大程度上规避了幻读这个“标准定义”与“具体实现”的差异是最容易被追问的地方。ORM 框架方面MyBatis 胜在 SQL 可控、易于优化JPA 和 Hibernate 胜在对象映射和跨库移植。连接池选型上Druid 带监控、HikariCP 性能好选哪个不如搞清楚“连接池大小怎么定”这个真问题连接数不是越大越好超过数据库承载能力后只会互相争抢。分库分表属于“不到万不得已不用”的手段真要用先想清楚分片键怎么选、跨分片查询和聚合怎么处理、扩容时数据怎么迁移分片中间件如基于代理的 MyCat 与基于客户端的 ShardingSphere只是把这些问题换了个地方暴露。RPC 框架的复习主线是序列化协议、通信框架、服务注册发现、负载均衡、容错。Dubbo 在国内使用广gRPC 依托 HTTP/2 和 Protobuf 适合多语言场景Thrift 胜在跨语言代码生成而 Netty 是这些框架底下的通信底座理解它的 Reactor 线程模型和零拷贝机制看任何 RPC 框架的源码都能对上号。4. 分布式与工程化微服务组件、运维体系与工具链到了这一层知识点从“怎么写代码”变成“怎么让一堆服务稳定地跑起来”。这一层的复习难点不在名词多而在于每个组件都要能回答“去掉它行不行、换一个行不行”。梳理下来微服务的所有组件都在解决两类问题服务之间怎么找到彼此并可靠通信以及出了问题怎么快速定位和止损。4.1 微服务六件套注册发现、网关、负载均衡、熔断、配置与分布式事务服务注册与发现是微服务的第一块砖。Eureka 偏向 AP节点间异步复制网络分区时仍能提供服务但可能读到旧数据Zookeeper 偏向 CP选举期间不可用Consul 与 Nacos 都支持两种模式切换Nacos 还额外提供配置中心能力。选型的关键不是谁更先进而是业务能否接受短暂的注册表不一致。网关是所有流量的统一入口承担路由、鉴权、限流、日志聚合四件事。Zuul 1 基于阻塞模型Spring Cloud Gateway 基于响应式模型在高并发下后者更有优势。网关鉴权的典型做法是在网关统一校验 Token 并把用户信息透传到下游避免每个服务重复实现。负载均衡分客户端和服务端两种。Ribbon 属于客户端负载均衡调用方自己持有服务列表并选择实例优点是少一跳、缺点是列表更新有延迟服务端负载均衡由中间代理完成省心但多一次转发。轮询、加权、最少连接、一致性哈希几种策略的差异要能对应到场景会话粘性用一致性哈希机器性能不均用加权。熔断与降级解决的是雪崩问题。Hystrix 的隔离方式有线程池隔离和信号量隔离两种前者彻底但有线程切换开销后者轻量但无法真正超时中断。核心参数有三个超时时间、熔断窗口内的失败率阈值、半开状态的试探请求数。很多团队配了这些参数却没验证过链路结果真出故障时熔断没触发这是典型的“配置了等于没配”。配置中心的价值在于“改配置不发版”。Config、Apollo、Nacos 三者的差异主要在推拉模式、灰度能力、权限模型上。复习时要能说清一次配置变更的生效路径改配置 → 发布 → 客户端监听或轮询 → 本地刷新 → 是否需要重启。分布式事务是最容易背成名词表的一节。2PC 与 3PC 是强一致路线靠协调者两阶段提交代价是同步阻塞和协调者单点XA 是 2PC 的标准化实现TCC 是业务层的补偿模式需要写 Try、Confirm、Cancel 三个方法侵入性强但性能好SAGA 把长事务拆成一系列本地事务加补偿本地消息表靠可靠消息加消费端幂等实现最终一致Seata 的 AT 模式通过解析 SQL 生成反向快照来简化补偿逻辑。真正要理解的是不要问哪个方案最好要问这条业务链路能不能接受最终一致、补偿失败的兜底由谁来做。4.2 服务器与运维Nginx、Tomcat、CI/CD、日志与链路追踪Nginx 的复习重点是反向代理、负载均衡、静态资源服务和限流。最基本的配置要能看懂 upstream 块和 location 匹配优先级proxy_pass结尾带不带斜杠会改变路径拼接结果这是部署时最常见的 404 来源。# nginx.conf 片段把 /api/ 前缀转发到后端集群并做简单的连接数限流 upstream backend_pool { least_conn; # 最少连接策略适合请求耗时差异大的场景 server 127.0.0.1:8081 weight2; # 权重高承接更多流量 server 127.0.0.1:8082; } limit_req_zone $binary_remote_addr zoneapi_limit:10m rate20r/s; location /api/ { limit_req zoneapi_limit burst40 nodelay; # 允许突发 40 个其余排队或拒绝 proxy_pass http://backend_pool; # 注意此处不带路径会保留 /api/ 前缀 proxy_set_header X-Real-IP $remote_addr; # 透传真实客户端 IP }这段配置的意图是上游按权重分配流量least_conn让慢请求少的机器多接活限流按 IP 每秒 20 个请求突发允许 40 个。实际部署时最容易踩的坑是proxy_pass的斜杠语义和location的匹配优先级精确匹配优先于前缀匹配正则匹配又有自己的顺序配置改完必须用nginx -t验证。Tomcat、Jetty、Undertow 三者的差异在连接器模型和线程模型上复习时抓住“连接数、工作线程数、最大排队数”三个参数以及“为什么高并发下 Tomcat 的阻塞 IO 会拖垮线程池”这个核心问题就能理解 Netty 这类 NIO 框架为什么存在。持续集成与持续发布是工程化的关键能力。Jenkins 流水线的典型阶段是拉代码、构建、单测、代码质量检查、打镜像、部署。代码质量检查重点看重复率、圈复杂度和阻断级别的静态缺陷不要一上来就开全量规则否则老项目会永远红着。日志收集走采集、缓冲、存储、检索四段链路追踪则靠 TraceID 串联核心是“一次请求的上下文如何跨线程和跨服务传递”。4.3 研发工具与前端Git、Maven、Docker、K8s 与前端三大件工具链部分经常被当成“用熟就行”但真出问题时全靠这些细节救场。Git 要能说清工作区、暂存区、本地仓库的关系merge与rebase的取舍分支历史清晰度 vs 提交记录线性以及reset三种模式的区别。团队协作中最容易翻车的是“合并了别人的强制推送”和“误提交敏感配置”前者靠保护分支规避后者靠提交前钩子和gitignore兜底。Maven 的复习点是生命周期、依赖调解和私服。依赖冲突有两套原则最短路径优先和第一声明优先冲突排查靠mvn dependency:tree。多模块项目的依赖管理要靠父 POM 的dependencyManagement统一版本避免子模块各写各的版本号。容器化是这一层必须动手的部分。Docker 的镜像分层机制决定了 Dockerfile 的写法把变化频率低的指令放前面把拷贝代码放后面才能吃到构建缓存。多阶段构建可以把编译环境和运行环境分开最终镜像只留运行时产物。# 多阶段构建编译阶段用带完整 JDK 的镜像运行阶段只留精简版 FROM maven:3.9-eclipse-temurin-17 AS build WORKDIR /src COPY pom.xml . RUN mvn -q dependency:go-offline # 先拉依赖命中缓存 COPY src ./src RUN mvn -q package -DskipTests FROM eclipse-temurin:17-jre # 运行时镜像不含编译工具 WORKDIR /app COPY --frombuild /src/target/app.jar app.jar ENTRYPOINT [java, -jar, app.jar]这段写法的关键在于前后两段分离依赖下载单独成层源码修改不会导致依赖重新下载运行镜像不带 Maven 和编译器体积和攻击面都更小。Kubernetes 则要抓住 Pod、Deployment、Service、Ingress 四个基本对象的关系理解“声明式”与“自愈”的含义你描述期望状态控制器负责把实际状态拉回来。前端部分不必深入但三大件HTML、JavaScript、CSS至少要能改页面、调接口、看控制台报错。Ajax 与 fetch 的区别、跨域的本质同源策略加浏览器拦截、模板引擎与前后端分离的演进这几条理解了和后端联调时就不会把所有问题都推给对方。5. 易漏易错点五个“以为自己会了”的高频坑每个学完路线图的人都会产生一种错觉名词都认识就等于掌握了。实际上真正区分水平的是那些“能讲清细节”的地方。梳理下来下面五个坑几乎人人都踩过共同的成因是学习时停留在“名词层”没有下沉到“机制层”。5.1 并发会背 synchronized说不清 happens-before易漏点能写出synchronized和volatile的用法但被问到“两个线程先后写同一个变量另一个线程何时能看到”时答不上来。为什么漏JMM 是抽象模型没有对应的代码形态看书时容易被当成一段描述性文字跳过。而可见性问题在单机小流量下几乎不复现出问题时又表现为玄学般的偶发。怎么补把 happens-before 的几条规则程序顺序、监视器锁、volatile 变量、线程启动与终止、传递性抄在一张纸上然后拿三个真实场景去套双重检查锁为什么要给实例加volatile、final域为什么能保证构造完成后的可见性、线程池提交任务前的写入为什么对工作线程可见。套不通就回去重读直到每条规则都能找到一个真实代码片段。5.2 JVM参数背了一堆不会读 GC 日志易漏点能说出-Xms、-Xmx、-Xmn、-XX:MetaspaceSize的含义但给一份 GC 日志不知道从哪看起。为什么漏调优场景在真实项目里出现频率低大多数人没有亲手制造过一次内存溢出自然没有看过日志。怎么补本地起一个会持续创建对象的 Demo把堆设小一点用-Xlog:gc*或旧版本的-XX:PrintGCDetails打印日志然后加jmap -histo:live看对象分布再用jmap -dump导出快照最后用工具打开看引用链。这一套走完一遍你会突然明白“内存泄漏”和“内存不足”在日志里的表现完全不同。整个过程不追求记住每个参数追求的是排查动作形成肌肉记忆。5.3 数据库隔离级别倒背如流不知道 MySQL 的 RR 是怎么防幻读的易漏点四种隔离级别和对应现象能默写但被追问“MySQL 默认 RR 为什么在标准里允许幻读、它又怎么规避的”就卡住。为什么漏教材讲的是 SQL 标准而实际实现是另一套逻辑两者的差异不在课本的同一页上。怎么补把 MVCC 的 ReadView、undo log 版本链、当前读与快照读的区别串起来看一遍然后自己开两个会话做实验会话 A 开启事务查询一次会话 B 插入并提交会话 A 再查一次看结果接着在会话 A 里执行select ... for update再看一次。实验比背书有效十倍因为你能亲眼看到快照读和当前读返回不同结果。间隙锁的作用也要在这个实验里一并体会。5.4 Spring循环依赖能说出三级缓存说不清 AOP 为什么在自调用时失效易漏点知道 AOP 基于动态代理但写了一个同类内部方法互调的代码发现事务注解没生效不知道原因。为什么漏代理机制是“容器替你做的事”写业务代码时看不见所以从来不会想到去验证。怎么补先明确一个判断标准——只有通过代理对象调用才会走增强逻辑this.method()走的是原始对象。然后在同一个类里写一个方法调用带事务注解的方法分别在同类内调用和从外部注入调用两种方式下观察结果差异会非常直观。真要解决无非三种做法拆到另一个 Bean、注入自身代理、用AopContext配合暴露代理。理解了这个Async、Cacheable失效的问题也就一并解决了。5.5 分布式事务方案名字全知道讲不清一条下单链路的事务边界易漏点能列出 2PC、TCC、SAGA、本地消息表、AT 各自的原理但给一条包含下单、扣库存、发优惠券、发通知的链路说不清该在哪切分事务。为什么漏分布式事务本质是业务建模问题不是技术选型问题而大多数资料只讲方案不讲建模。怎么补拿一条真实的业务链路把每个步骤标注三个属性是否强一致、能否补偿、失败后谁兜底。你会发现大部分步骤其实只需要最终一致真正需要强一致的可能只有“扣库存与创建订单”这一小段。标完之后再选方案通常比先选方案再硬套要省事得多。同时要盯住三个工程细节幂等键怎么设计、补偿失败后进哪张表、人工介入的入口在哪。6. 查漏补缺把路线图变成一张能打勾的复习清单复习到最后阶段最有效的方式不是再看一遍资料而是拿一张清单逐项自检。自检的颗粒度决定效果只写“JVM”三个字的清单等于没写必须写到“能用 jstat 判断是 Young GC 频繁还是 Full GC 频繁”这种可验证的动作级别。我习惯把每一项分成三个层级能讲清能向别人解释原理、能写出能手写关键代码或命令、能调通在本地跑起来并看到结果。三层都过的项可以直接划掉只过前两层的要补动手一层都没过的回炉。下面这张表是我自己用的分组样例可以直接照着扩成完整版。模块自检动作达标标准容器手写 HashMap 的 put 与扩容逻辑能解释树化阈值与扩容时机并发手写一个有界线程池并压测能说明拒绝策略触发条件JVM用 jmap 导出快照并定位大对象能说出对象为何晋升老年代数据库用 explain 优化一条慢查询能判断回表与索引失效原因Spring复现一次事务失效并修复能解释代理与自调用的关系微服务画一次请求经过网关到落库的全链路能标出每个组件的失败点工程化写一条从提交到部署的流水线能说明每个阶段的失败处理执行这张表时有两个经验值得记住。第一个是限时每个自检动作给 40 分钟超时就标记为“不熟”不要在一个点上耗一整天那样复习节奏会崩。第二个是留痕每个动作写三行笔记一行写结论一行写踩到的坑一行写下次怎么快速回忆。攒到几十条之后这份笔记本身就是最好的考前材料。# 复习环境自检脚本示例一条条确认工具链是否可用 java -version 21 | head -n 1 # 确认 JDK 版本与路线图一致 mvn -v | head -n 1 # 确认构建工具可用 docker ps /dev/null echo docker ok # 容器环境是否就绪 jps # 能列出 Java 进程才谈得上后续排查这个脚本的意义不在命令本身而在建立“环境先于知识”的意识很多次复习卡住其实是 JDK 版本不对、Maven 拉不到依赖、Docker 没启动这类环境问题把时间浪费在了错误的方向上。从那以后我每次复习任何一块新内容都会强制走一遍“讲一遍、写一遍、跑一遍”的流程哪怕是最熟的集合和线程池也不例外因为翻车往往就发生在自以为最熟的地方。希望帮到你。本文还有配套的精品资源点击获取
