上个月帮一个学弟改简历他两年时间把市面上能买到的Java课程几乎刷了个遍简历上罗列的项目有四个结果投出去两周只有两个面试还都在一面就挂了。他问我是不是学历问题我把他简历翻了一遍发现真正的问题不在学历四个项目里有三个是XX商城技术栈写着SSM加Redis问一句你这个Redis缓存的数据一致性怎么保证的他就卡住了。这两年我陆续带过七八个走Java后端路线的朋友也面过不少候选人越来越确定一件事——路线本身没错错的是大多数人把学完当成了学会把用过当成了想过。这篇内容我想把2026年Java后端这条路线重新拆一遍不是再给你一份XXX天从入门到精通的目录而是把每个阶段真正卡人的地方、简历和面试里被追问最多的点、以及我自己踩过的坑讲清楚。适合刚决定转后端的新人也适合学了一两年但总觉得使不上劲的中间态选手。全篇会围绕Java基础、并发与JVM、框架工程化、分布式中间件、项目实战、面试准备这几个关键词展开每个阶段我都会给出判断标准而不是学时。1. 2026年的Java后端岗筛人的尺子换了几把1.1 招聘描述里的高频词三年间换了三轮如果你现在去翻主流招聘平台上的Java后端JD会发现一个很明显的变化。2021年前后大量岗位的要求写的是熟悉Spring、SpringMVC、MyBatis了解MySQL、Redis这是一套典型的单体应用技术栈。到2024年之后熟悉分布式、微服务、消息队列开始变成中高级岗位的默认项而到了现在越来越多的岗位会额外加一句有性能优化经验者优先或者具备线上问题排查能力。这个变化背后的逻辑不复杂。单体应用的开发门槛已经被框架和脚手架压得很低一个熟练的人两三天就能搭出一套带登录、带权限管理的后台系统。当能搭起来不再是稀缺能力筛人的尺子自然就往后面挪——挪到了跑起来之后怎么办这个层面。数据库慢查询、接口响应时间抖动、定时任务重复执行、缓存和数据库不一致这些才是真正把人和人拉开差距的地方。我自己的判断是未来的Java后端岗位会分成两条明显不同的路径。一条是业务开发核心考察点会落在业务抽象能力、接口设计和工程规范上另一条是偏基础设施或者中间件方向考察点落在并发、网络、JVM调优这些硬功底上。你在学的时候不必现在就选边但心里要清楚这两条路径前期打的基础是同一套后期补的东西不一样。1.2 AI编码工具普及之后代码能力的定价方式变了这两年AI辅助编码工具的普及对后端学习路线的影响非常直接。以前手写一个CRUD接口是基本功现在这件事的边际价值被压得很低——工具几秒钟就能生成而且生成质量还不差。于是很多刚入门的人会产生一种错觉既然代码都能生成那我是不是不用学这么细了我的观察恰恰相反。工具能帮你省掉的是敲键盘的时间省不掉的是判断的时间。同样一段工具生成的代码一个懂并发的人一眼能看出线程池参数配置不合理一个不懂的人只能照着用。工具把下限抬高了同时也把能看懂并改对这个能力变得更重要了。面试里现在很常见的一种问法是这段代码如果并发量上来会有什么问题——这种题工具帮不了你只能靠底子。所以我后面讲每个阶段的时候都会强调一件事不要以能写出来作为掌握标准要以能说出这么写的原因和风险作为标准。1.3 三条最常见的走偏路线我见过太多次第一条是囤课不落地。硬盘里存着十几个G的视频收藏夹里躺着几十篇全网最全路线图但真正动手写过的代码不超过两千行。学习这件事有个很讨厌的特性看视频会产生我在进步的错觉因为大脑在处理信息的时候确实在消耗能量但理解和输出之间的鸿沟从来没被填上。第二条是跳过基础直接上框架。上来就学Spring Boot能跑起来一个接口但不知道IoC容器是什么不知道Bean是什么时候创建的遇到循环依赖报错就懵了。这种学习方式能让你在初期跑得很快但天花板极低因为框架的所有设计都是对底层机制的封装你不懂底层就只能死记配置。第三条是项目撞车。百分之七八十的人简历上都是商城、外卖、秒杀。面试官一天看几十份简历看到第三个商城就已经开始走神了。项目同质化本身不是致命问题致命的是你做的商城和别人做的没有任何区别——同样的表结构、同样的功能、同样的技术栈没有任何一个点能讲出深度。提示这三条走偏路线的共同点是跳过了不舒服的环节。基础枯燥、项目难写、深度思考费脑而囤课和套用现成项目都很舒服。学习路线的本质其实是选择在哪些地方主动吃苦。2. 语言底座Java基础这块地基怎么打才算够2.1 集合与泛型面试问得最细也最容易翻车的区域很多人觉得集合就是会用来存取数据这远远不够。以HashMap为例面试里被追问的频率高到离谱初始容量是多少、负载因子为什么是0.75、什么时候扩容、扩容时元素怎么迁移、为什么线程不安全、JDK8之后为什么引入红黑树、树化阈值为什么是8。这些问题如果你只是背答案很容易在为什么那一层露馅。我建议的学习方式是自己动手写一遍简化版的HashMap不用写全把数组加链表的结构、hash扰动函数、扩容逻辑实现出来就够了。写的过程中你会自然理解为什么要用红黑树来兜底极端情况也会明白负载因子为什么不能设得太高或太低——太高会导致冲突加剧太低会导致频繁扩容浪费空间。这种理解是背不出来的。泛型要重点关注类型擦除。为什么不能直接new T[]为什么ListString和ListInteger在运行时的类对象是同一个通配符? extends T和? super T分别适合什么场景。这几个问题背后其实是同一件事泛型是编译期的语法糖运行时并不存在。理解了这一点很多看似奇怪的编译报错就都能解释了。集合类底层结构线程安全典型使用场景面试高频追问ArrayList动态数组否读多写少、随机访问密集扩容倍数为什么是1.5LinkedList双向链表否频繁头尾插入删除为什么实际很少用它HashMap数组链表红黑树否通用键值存储扩容、树化、并发问题ConcurrentHashMap分段/CASsynchronized是高并发缓存JDK7和JDK8的实现差异CopyOnWriteArrayList写时复制数组是读极多写极少的配置类数据为什么不适合写多场景2.2 反射、动态代理与IO框架的底层都用得到反射这块重点不是会写Class.forName而是理解它到底慢在哪里。反射调用需要做访问检查、参数装箱、方法查找这些步骤正常情况下都比直接调用慢。但Spring的Bean创建也大量用了反射为什么性能还能接受因为它在创建Bean的时候会缓存方法句柄而且Bean的创建只在启动时发生一次。这个缓存加一次执行的思路本身就是很值得学的工程手段。动态代理是理解AOP的钥匙。JDK动态代理基于接口要求目标类必须实现接口CGLIB基于继承通过生成子类来增强。Spring在需要给没有接口的类做增强时会切换到CGLIB较新的版本默认行为也偏向CGLIB。你如果能自己手写一个基于JDK Proxy的简单拦截器在方法执行前后打印耗时那AOP对你来说就不再是配置一下就行的黑盒了。IO这块把BIO、NIO的区别搞清楚就够用了。核心在于BIO一个连接对应一个线程连接数一多线程就爆了NIO用多路复用一个线程可以管理大量连接。至于底层是select、poll还是epoll知道结论就行不必死磕。更重要的是理解Netty为什么会出现以及它的线程模型大致长什么样——面试问到RPC或者网关的时候这一段是必问的。2.3 怎么把语法变成肌肉记忆我给的建议是每个知识点配一个不超过一百行的可运行Demo。学完线程池就写一个模拟下单的Demo学完反射就写一个简易的对象属性拷贝工具学完动态代理就写一个方法耗时统计。这些Demo不需要多完整但它们能让你在面试里被问到的时候脑子里有画面而不是只有文字。另外强烈建议养成读源码的习惯但不要一上来就读Spring。先从JDK自带的类开始比如ArrayList的add方法、HashMap的putVal方法这些代码量不大逻辑也相对独立读起来不容易劝退。读完一批之后你会发现看框架源码的心理负担小了很多。3. 并发与JVM区分会写代码和能扛线上的分水岭3.1 线程池参数配置是最容易出事的地方线程池几乎是我面人时必问的一个点因为它能把一个人对并发的理解从浅到深全部暴露出来。基础的问法是线程池有哪几个核心参数、任务提交后的执行流程是什么。进阶的问法是核心线程数怎么定、队列该用有界还是无界、拒绝策略怎么选、线程池满了之后会发生什么。这里有个非常典型的坑就是用Executors提供的快捷工厂方法去创建线程池。newFixedThreadPool用的是无界队列任务堆积起来会一直吃内存最后OOMnewCachedThreadPool的最大线程数是Integer.MAX_VALUE理论上可以无限创建线程。这两个在工具类里看着很方便实际生产环境基本不能直接用。正确的做法是自己new ThreadPoolExecutor把队列容量和拒绝策略都显式写出来。ThreadPoolExecutor executor new ThreadPoolExecutor( 8, 16, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(200), new ThreadFactory() { private final AtomicInteger idx new AtomicInteger(1); Override public Thread newThread(Runnable r) { Thread t new Thread(r, order-pool- idx.getAndIncrement()); t.setDaemon(false); return t; } }, new ThreadPoolExecutor.CallerRunsPolicy() );线程数的估算网上流传CPU密集设N1、IO密集设2N这个说法可以当作起点但别当成公式。真正靠谱的做法是根据实际压测结果调。如果任务里IO等待占比很高比如要调下游接口那么线程数 ≈ 核数 × (1 等待时间/计算时间)这个思路更贴近实际。我一般在压测环境里从8开始往上加盯着吞吐量和响应时间找到拐点之后往下取一档留余量。注意线程池的监控比配置更重要。至少要暴露活跃线程数、队列长度、已完成任务数这几个指标队列长度持续增长就是明确的告警信号说明任务处理速度跟不上提交速度。3.2 JMM、volatile和synchronized绕不开的底层Java内存模型解决的是可见性、有序性和原子性三个问题。可见性是说一个线程改了共享变量另一个线程能不能立刻看到有序性是说编译器和处理器会不会为了优化而重排指令原子性是说一个操作会不会被打断。这三个概念理解了后面所有的并发工具都只是它们的应用。volatile保证可见性和有序性但不保证原子性。经典例子是i这种复合操作即使变量声明成 volatile多线程下依然会丢更新因为读和写是两步。面试里让你用 volatile 写一个计数器你如果直接写count基本就凉了正确做法是用AtomicInteger或者加锁。synchronized的锁升级过程是另一个高频考点无锁、偏向锁、轻量级锁、重量级锁。这里有个细节值得注意偏向锁在较新的JDK版本里已经被默认关闭并逐步移除因为它在高并发场景下的收益不稳定反而带来了额外的复杂度。你如果被问到可以答出这个演变会显得是真的关注过这块而不是只背了老版本的书。3.3 JVM从内存结构到一次真实的调优推演JVM这块的知识点很散我建议用一条主线串起来一个对象从被创建到被回收中间经过了什么。沿着这条线你会依次碰到堆和栈的分区、对象在Eden区分配、Minor GC、对象晋升到老年代、Full GC、各种垃圾回收器。垃圾回收器不用全部深挖把G1和ZGC的特点搞清楚就够。G1把堆分成一个个Region可以设定预期的停顿时间适合堆比较大的场景ZGC的目标是极低停顿代价是需要更多的内存和更新的JDK版本。至于CMS它在较新的版本里已经被移除了解一下它的并发标记清除思路就行。调优这件事我最想说的是**不要为了调而调。**很多人一看到JVM调优这四个字就兴奋上来就改一堆参数结果把本来跑得好好的服务搞出了新问题。正确的顺序是先用GC日志和监控看清楚现状确认确实存在频繁Full GC、停顿时间过长这类问题再针对性调整。常见的有效手段包括把-Xms和-Xmx设成一样避免堆反复伸缩、合理设置新生代比例、给大对象留出足够空间避免过早晋升。排查内存问题jmap配合 MAT 是老牌组合但在容器环境里我更常用 Arthas因为它可以attach到运行中的进程直接看对象分布、看方法调用耗时不用重启服务。这个工具值得花一个下午专门学一下后面会反复用到。3.4 网络这块后端躲不开TCP的三次握手四次挥手属于基础中的基础但很多人只知道流程不知道为什么要三次。简单说三次是为了让双方都确认对方的收发能力正常两次的话服务端无法确认客户端是否收到了自己的确认。四次挥手是因为TCP是全双工的两个方向需要分别关闭。更有实用价值的是粘包拆包问题。TCP是字节流协议没有消息边界所以应用层必须自己定义边界常见方案有定长、分隔符、长度字段三种。Netty对这三种都有内置的编解码器用起来很方便但面试官更想听你解释为什么会出现粘包而不是你会用哪个类。HTTP这块重点在状态码语义、幂等性、缓存控制头。RESTful风格本身不是考点但一个接口该用GET还是POST、PUT该不该幂等、错误码怎么设计这些在实际工作里天天用得到面试里也经常顺带问一句。4. 框架与工程化把代码写进规范里4.1 Spring Boot的正确打开方式不是会写ControllerSpring Boot现在几乎是标配但绝大多数人只停留在会写Controller和Service这个层面。真要拉开差距得往三个方向走。第一个方向是理解自动配置的原理SpringBootApplication背后做了什么、条件注解是怎么生效的、为什么引入一个starter就能用。第二个方向是Bean的生命周期从实例化、属性注入、初始化到销毁每一步有哪些扩展点BeanPostProcessor在什么时候介入。第三个方向是AOP的实际应用场景日志、事务、权限校验、接口耗时统计这些都是日常会遇到的。循环依赖是个特别能考察理解深度的问题。三级缓存这个概念很多人背得出来但如果你被追问为什么需要三级而不是两级就得解释清楚早期引用和代理对象之间的关系。我的建议是自己动手复现一次循环依赖报错然后看Spring是怎么解决的这种带着问题去读源码的效率比从头到尾啃一遍高得多。事务这块最容易出事的是自调用失效。同一个类里A方法调用B方法B方法上标了Transactional这个事务是不会生效的因为调用走的是对象内部引用而不是代理对象。这个问题我在实际项目里见过不止一次表现是数据写了一半没回滚排查起来还挺费劲。4.2 SQL能力被严重低估了后端这个岗位SQL能力的重要性怎么强调都不过分。很多人的状态是能写出来能跑就行至于走不走索引、扫描了多少行、有没有回表完全不关心。等到线上接口变慢才发现是某个查询把表全扫了一遍。索引这块必须掌握的是最左前缀原则、覆盖索引、回表这几个概念以及怎么用EXPLAIN看执行计划。看执行计划的时候重点盯type、key、rows和Extra这几列。type从ALL、index、range到ref、eq_ref是逐级变好的出现ALL基本就是全表扫描Extra里出现Using filesort或者Using temporary通常意味着有优化空间。-- 联合索引 (user_id, status, created_at) -- 下面的查询可以用上索引 SELECT id, amount FROM orders WHERE user_id 1001 AND status 1 ORDER BY created_at DESC LIMIT 20; -- 这个查询用不上索引因为跳过了最左列 SELECT id FROM orders WHERE status 1; -- 这个也用不上因为对索引列做了函数运算 SELECT id FROM orders WHERE DATE(created_at) 2026-01-01;最后一条特别值得留意索引列上做函数运算或者隐式类型转换都会导致索引失效。字符串类型的字段用数字去查MySQL会做隐式转换同样用不上索引。这类问题很隐蔽写代码的时候完全看不出来得靠上线后看慢查询日志才能发现。4.3 前后端分离下的接口设计细节决定体验前后端分离现在已经是默认形态这也让接口设计的质量变得非常显性。我见过的接口设计问题里排在前面的几个是分页参数命名不统一、时间格式一会儿是时间戳一会儿是字符串、错误码没有统一定义、参数校验靠前端做。统一规范这件事最好在项目一开始就定下来后面再改成本很高。我一般会约定几个基本点所有列表接口统一用pageNum和pageSize时间统一用 ISO 8601 字符串格式避免时区歧义返回体统一封装成code、message、data三段业务错误码分段管理比如1开头是通用错误、2开头是用户相关、3开头是订单相关。跨域是分离部署必然遇到的问题。CORS的预检请求机制值得搞清楚当请求方法不是简单方法或者带了自定义头浏览器会先发一个OPTIONS请求去探路服务端返回允许的头信息之后才发真实请求。这里有个常见的坑如果前端带了凭证服务端的Allow-Origin就不能写*必须指定具体域名否则浏览器会拒绝。很多人卡在这个问题上排查半天其实原因就是这一条规则。4.4 缓存的引入时机和失效策略Redis几乎成了后端的标配组件但什么时候该用缓存、怎么保证一致性很多人是模糊的。我的判断标准是读多写少、数据能容忍短暂不一致、数据库压力确实大这三个条件同时满足才值得上缓存。反过来如果数据变更频繁或者对一致性要求极高用缓存反而会引入更多麻烦。缓存的三个经典问题是穿透、击穿和雪崩区别在于穿透是查一个数据库里根本不存在的key每次都要打到数据库击穿是某个热点key过期瞬间大量请求涌进来雪崩是大量key同时过期。对应的处理手段也不一样穿透可以用空值缓存加布隆过滤器击穿可以用互斥锁或者逻辑过期雪崩主要靠过期时间加随机值来打散。数据一致性这块我实际用下来最稳的还是先更新数据库、再删除缓存这个顺序配合延迟双删来兜底。虽然理论上依然有不一致的时间窗口但工程上够用实现也简单。至于先删缓存再更新数据库、或者用消息队列做异步补偿在没有强一致要求的场景下我不太推荐复杂度和收益不成正比。5. 分布式与中间件让简历有做过系统的质感5.1 消息队列解决的是什么问题学消息队列之前先想清楚它到底解决什么问题。我总结下来主要是三类解耦、异步、削峰。解耦是说生产者不用关心消费者是谁、有几个异步是说主流程不用等耗时操作完成先把消息发出去就返回削峰是说把瞬时高并发的请求先落到队列里消费者按自己的能力慢慢处理。这三类里削峰是最容易讲出效果的。举个我实际遇到的场景下单之后需要发短信、加积分、更新推荐数据如果同步执行接口响应时间可能要三秒以上。改成发一条消息出去异步处理主流程响应时间能压到两百毫秒以内。这个改造前后的对比数字写进简历和面试里都比熟悉Kafka这句话有说服力。消息队列必须搞清楚的是重复消费问题。绝大多数消息队列只能保证至少一次投递所以消费者必须做幂等。实现幂等的思路有很多比如用数据库唯一索引、用Redis记录已处理的业务ID、或者把操作设计成天然幂等的比如状态机流转。面试里被问到怎么保证不重复消费直接答保证不重复消费做不到要做的是消费端幂等这个回答的分量比背一堆方案要重。5.2 分布式锁和分布式事务的适用边界分布式锁用Redis实现是最常见的方案核心是SET key value NX PX timeout这条命令。这里有个细节释放锁的时候要判断是不是自己加的锁而且判断和删除必须是原子的所以要用Lua脚本。String lockKey lock:order: orderId; String requestId UUID.randomUUID().toString(); boolean locked redis.opsForValue() .setIfAbsent(lockKey, requestId, 30, TimeUnit.SECONDS); if (!locked) { throw new BizException(操作过于频繁请稍后再试); } try { // 业务逻辑 } finally { // Lua脚本保证判断和删除的原子性 redis.execute(new DefaultRedisScript(UNLOCK_SCRIPT, Long.class), Collections.singletonList(lockKey), requestId); }分布式事务我个人的态度是能不用就不用。绝大多数业务场景通过合理的设计可以把跨服务的事务拆解掉比如用状态机加补偿、用本地消息表保证最终一致。真正需要强一致的场景其实很少。如果非要选Seata的AT模式上手最快但它的原理是基于全局锁加回滚日志对性能有影响得评估清楚再上。5.3 微服务别为了学而学微服务是这几年最容易被过度设计的技术方向。很多团队业务体量并不大硬拆成十几个服务结果运维复杂度飙升一个接口调用链路要跨五个服务出问题都不知道从哪查。如果你是为了学习我的建议是先把单体应用写好理解清楚分层、模块边界、依赖方向然后再去理解微服务解决了单体的哪些具体问题独立部署、独立扩容、技术栈隔离。带着问题去学Nacos、Gateway、Sentinel这些组件效率会高很多。注册中心解决的是服务发现网关解决的是统一入口和鉴权熔断限流解决的是故障隔离每个组件都对应一个具体的痛点不要孤立地背功能。5.4 可观测性排查问题的三板斧日志、指标、链路追踪这三样东西在实际工作里的价值极高但在学习阶段最容易被忽略。我见过不少工作两三年的人线上出问题还在靠grep翻日志文件不知道有统一的日志平台也不知道怎么根据traceId串联整个调用链。日志这块最基本的要求是打日志要带traceId并且在跨服务调用的时候透传下去。MDC是常用的实现方式配合拦截器在请求进来的时候把traceId塞进去后面所有日志自动带上。这个改造只要半小时但能省下无数排查时间。指标这块Prometheus加Grafana是主流组合重点是把几个核心指标暴露出来接口的QPS、响应时间的P50和P99、错误率、线程池队列长度、数据库连接池使用率。有了这些大部分问题在爆发之前就能看到苗头。链路追踪这块SkyWalking对Java应用基本是零侵入接入加个启动参数就行。它能直接画出调用链路每个环节的耗时一目了然排查性能问题的时候特别有用。6. 项目实战怎么把做过变成做过且想清楚6.1 选题避开红海找一个能讲透的场景我前面说过项目同质化的问题那怎么破我的建议是不要去卷商城和秒杀而是找一个你真正熟悉、有细节可讲的场景。比如你之前做过某个行业的兼职或者对某个领域感兴趣从这个场景出发去做一个系统讲起来会有很多真实的业务细节。具体一点可以选择的方向有面向小团队的协作工具、某个细分领域的数据管理系统、带实时计算的分析平台、或者是一个有调度需求的自动化工具。重点不在于系统多复杂而在于你能不能讲清楚为什么这么设计。6.2 从CRUD到有亮点中间差了哪些改造一个能讲的项目通常需要具备几个特征有并发场景、有性能考量、有数据一致性处理、有可观测性。这些不需要一开始就全部具备可以在基础功能跑通之后逐步改造。改造方向具体做法能讲出的面试点缓存层热点数据加Redis缓存做空值缓存防穿透缓存一致性策略、过期时间设计异步化耗时操作改为消息队列异步处理幂等设计、消息可靠性性能优化慢查询加索引、接口加本地缓存执行计划分析、压测数据对比并发控制秒杀类场景用分布式锁锁粒度、超时与续期稳定性加限流、熔断、降级开关熔断阈值设定依据每个改造都要留下数据。加索引前后的查询耗时对比、加缓存前后的数据库QPS对比、异步化前后的接口响应时间对比这些数字是你面试时最有力的论据。没有数字的优化描述说服力会大打折扣。6.3 部署上线这一步很多人直接跳过了项目能在本地跑起来和能部署上线是两回事。我强烈建议每个项目都至少完整部署一次用Docker打包镜像用docker-compose或者一台低配服务器跑起来配好Nginx反向代理域名和HTTPS能配就配。这个过程会逼着你接触一堆平时写代码碰不到的东西环境变量配置、日志挂载、容器时区、健康检查、优雅停机。这些问题在本地开发环境里永远不会出现但线上的故障有一大半跟它们有关。做过一遍之后你对生产环境这四个字会有完全不同的理解。压测也建议做一次JMeter或者wrk都行。压测的意义不在于跑出多高的数字而在于让你第一次真实看到并发量上来之后系统会发生什么。很多人做完压测之后才发现自己以为的性能瓶颈在后端实际卡在数据库连接池上。7. 面试准备八股文之外还得准备什么7.1 八股文的正确用法是往下追三层八股文这个东西被骂得很惨但它确实是面试的通行证。问题不在于背不背而在于背到什么程度。我的经验是每个知识点至少要能往下追三层。举个例子什么是线程池是第一层线程池的参数和执行流程是第二层为什么用有界队列而不是无界队列、拒绝策略怎么选是第三层。面试官通常会从第一层问到第三层答到第三层就基本稳了。面试大全类的资料可以看但不要只背结论。看到每个问题的时候多问自己一句为什么把答案里的因果关系理清楚。这样即使面试官换个问法你也能答上来。7.2 项目追问怎么应对项目部分最怕的是一问就露底。面试官常见的追问路径是这个功能的实现思路是什么、为什么这么设计、如果并发量翻十倍会怎么样、遇到过什么问题、怎么解决的。这几个问题任何一个答不上来前面的讲述都会被怀疑。准备的方法是提前把项目的每一层都过一遍尤其是你写在简历上的那些技术点。写了Redis就要能说清楚缓存了什么数据、过期时间怎么定的、怎么防穿透写了消息队列就要能说清楚消息格式、幂等怎么做的、消息丢了怎么办。写上去就要能扛住追问扛不住的点不如不写。7.3 一份可以照着走的时间表最后给一个相对务实的节奏参考前提是每天能投入三小时以上周末能拿出完整的一天。这个节奏不追求快追求的是每一阶段都有可验证的产出。阶段时长核心任务验收标准语法与集合6周语法、集合、异常、IO、泛型能手写简化版HashMap并解释扩容并发与JVM8周线程池、锁、JMM、GC、排查工具能分析GC日志并给出调整方案框架与数据库8周Spring体系、MyBatis、SQL优化能独立完成一个分层清晰的模块中间件与分布式8周Redis、MQ、微服务组件、可观测性能画出系统的完整链路图项目与部署8周完整项目、Docker部署、压测有可访问的线上地址和压测数据面试冲刺4周八股复习、项目复盘、模拟面试能连续讲三十分钟项目不卡壳这个表里我最想强调的是最后两列。很多人学习的时候没有验收标准导致永远不知道自己学到位没有只能靠感觉学了很久来判断这非常不可靠。每个阶段给自己定一个可验证的产出学起来会踏实很多。最后分享一个我自己用了很多年的小技巧每学完一个模块试着用大白话把它讲给一个完全不懂技术的朋友听。如果你讲的时候卡壳了或者对方追问两句你就答不上来那说明这块你还没真正理解。这个自检方式的准确率比做十道选择题都高。