Java求职Day51：并发编程深水区与面试复盘指南

今天是我java求职学习day51的第51天。说实话能坚持到这个数字的人并不多。身边同期备考的朋友有的在第二周就转投考研有的在第四周陷入越学越焦虑的循环真正按计划推进到这里的一只手数得过来。Day51是一个很微妙的时间节点。基础语法早过完了SpringBoot项目能撸能跑力扣也刷了一百多道但心里清楚离从容进面试还有一段距离。这个阶段的典型特征是——已经过了学新东西的兴奋期进入查漏补缺的深水区每天拼的不是冲劲而是稳定的输出。今天我完整记录了这一天的安排上午深挖并发编程的高频考点下午做了一场模拟面试晚上刷两道算法题再重新打磨简历里项目的讲述逻辑。这篇文章既是复盘也是写给同样在求职路上的人的一份参考——如果你也走到第40到60天这个区间这些内容大概率用得上。1. 第51天的坐标你的知识地图该铺到什么位置1.1 回看前50天一份可复制的节奏先把前50天的节奏摊开讲。这个阶段能不能走得稳很大程度上取决于前期知识地图铺得是否均匀。我把自己50天的安排复盘了一遍大致是这个结构时间段主线任务核心产出Day1-10Java基础语法、集合源码、IO、泛型与反射集合类源码能讲出扩容机制Map的哈希冲突处理随口能答Day11-20JVM内存模型、GC算法与调优、类加载、并发基础能画出堆内部分区说清对象晋升流程Day21-30Spring/SpringBoot原理、MyBatis、MySQL索引与事务隔离能徒手搭接口对慢SQL有优化思路Day31-40Redis核心数据结构、缓存一致性、消息队列、分布式基础能聊缓存穿透与雪崩能画出分布式锁的时序Day41-50项目打磨、LeetCode刷到100道、第一次模拟面试简历定稿开始熟悉面试的追问节奏这个安排有一个核心原则每十天一个主题主题内只做主线加配套两件事。主线是某一类技术深度配套是算法题的持续跟进。前期容易犯的错是东一榔头西一棒子今天看并发明天看Spring后天又去刷MySQL看起来每天都很忙最后什么都是半吊子。我的建议是把技术栈按面试权重排好序一个块一个块地啃透再进入下一块。举个例子我当时在Day12到Day18专门啃JVM每天只干两件事读一段《深入理解Java虚拟机》的章节再用jvisualvm连上一个本地项目观察堆和GC的实际情况。刚开始觉得慢但到了Day20左右遇到面试题说说对象什么时候进入老年代我能直接背出年龄阈值、动态年龄判定、大对象直接进入老年代这三个维度这就是模块化学习的回报。1.2 深水区状态判断你是在复习还是在假装努力到了第51天最怕的不是不会而是用新东西很多来掩盖旧东西没消化。我自己有一个很简单的判断标准能不能在不看笔记的情况下把某个知识点讲给一个不懂技术的人听。如果讲得出来对方也能听懂说明真的理解了如果讲的时候要嗯……那个……说明还处于记忆层面。费曼学习法在这个阶段非常管用。每天抽出半小时随便挑一个今天复习过的概念录一段两分钟的语音讲给自己听回放的时候会发现很多自以为懂、其实含混的地方。我Day48那天录了MySQL的MVCC机制回放才发现自己连当前读和快照读的区别都说不利索这个短板如果不暴露面试现场大概率也会卡壳。Day51这种深水区拼的就是谁能先意识到我知道自己不知道什么。另外一个状态判断是做题正确率。如果力扣简单题还要想半天或者高频题看到题号能说出解法但代码写不利索那就说明前期的算法手感还没沉淀下来。这个阶段不需要再开新专题把错题反复刷比刷新题重要得多。我自己有一个硬性指标一道做过标记的错题隔五天重新做如果能独立在20分钟内写对且跑通测试用例才算真正过关否则继续进回收站。2. 今日主攻并发编程高频考点逐个过成肌肉记忆2.1 synchronized和ReentrantLock别再停留在背八股上午第一个专题是锁。很多面试一开口就是synchronized是重量级锁ReentrantLock更灵活这种回答只能证明你背过八股证明不了你理解。真正需要讲清楚的是它们各自的实现机理和取舍。synchronized是JVM指令级的锁编译后对应monitorenter和monitorexit指令底层依赖Monitor对象。JDK1.6之后引入锁升级机制偏向锁、轻量级锁、重量级锁。锁升级的目的很直接——大多数场景下并发竞争并不激烈没必要一上来就上重量级锁能用偏向锁解决的就不升级。这里有一个面试官常问的细节偏向锁在什么条件下会撤销答案是当有另一个线程尝试竞争该锁时偏向锁会撤销并升级为轻量级锁如果竞争更激烈轻量级锁自旋失败后会膨胀为重量级锁。ReentrantLock是JDK层面的API基于AQS实现。它和synchronized的核心差异我从面试角度整理了一张表对比维度synchronizedReentrantLock实现层面JVM指令级Monitor机制JDK API基于AQS与LockSupport公平性只支持非公平可选公平与非公平锁超时不支持tryLock(timeout, unit)可设置等待上限中断响应不响应中断lockInterruptibly()可被中断条件队列只有一个隐式等待集可通过newCondition()创建多个条件队列锁升级有偏向锁到重量锁的升级路径无升级概念核心是state状态维护这里再说一个容易被问倒的点既然synchronized有锁升级机制性能已经不输ReentrantLock为什么很多框架还是偏好ReentrantLock因为ReentrantLock的灵活度是synchronized给不了的。典型场景是tryLock带超时获取锁拿不到就做降级处理避免线程无限期阻塞还有多个条件队列的场景典型的是生产者-消费者模型里区分缓冲区满和缓冲区空两种等待条件。这些需求用synchronized实现起来非常别扭。再补充一个容易被忽视的细节synchronized在JDK14以后引入了虚拟线程相关的改进但在面试中聊到这个层面的人很少我建议你不要主动往这个方向引除非面试官自己提。多数情况下把锁升级机制和ReentrantLock的条件队列讲透就足够建立区分度了。2.2 AQS源码怎么读从acquire到队列唤醒ReentrantLock的核心在AQSAbstractQueuedSynchronizer。Day51这个阶段源码不能只看结论至少要能画清调用链。我建议按这个顺序读先看ReentrantLock的lock()入口然后进到Sync的lock()再到AbstractQueuedSynchronizer的acquire()。acquire(int arg)的核心逻辑是三步先tryAcquire尝试获取锁如果失败就addWaiter把当前线程包装成Node节点放进CLH队列尾部然后acquireQueued在队列里自旋或挂起等待前驱节点释放锁后唤醒自己。源码核心可以抽象成下面这个伪代码public final void acquire(int arg) { if (!tryAcquire(arg)) { Node node addWaiter(Node.EXCLUSIVE); // 入队 boolean interrupted acquireQueued(node, arg); // 自旋或阻塞 if (interrupted) { Thread.currentThread().interrupt(); } } }看这段代码有两个关键点。第一tryAcquire是一个由子类实现的模板方法ReentrantLock的公平锁与非公平锁就是在这个方法里分叉的。非公平锁直接CAS设置state谁抢到算谁公平锁会先检查hasQueuedPredecessors()如果队列里已经有等待线程就乖乖排到后面不参与竞争。第二acquireQueued内部是一个for循环循环体里先判断前驱节点是不是头节点是的话再tryAcquire一次成功就把自己设为头节点返回否则用shouldParkAfterFailedAcquire判断前驱节点的waitStatus需要挂起就调用LockSupport.park挂起当前线程。我用一个生活类比帮助理解AQS的队列就像餐厅门口排队叫号。每个新来的都要先取号addWaiter队伍里每个人都盯着前一个人前驱节点前一个人走了释放锁才会通知你。叫到号tryAcquire成功才能进去等不及的人可以走取消排队但他前面的人并不知道所以要靠waitStatus状态位去通知后一个节点。读AQS不要一上来就啃全部代码。先读独占模式ReentrantLock再读共享模式CountDownLatch、Semaphore最后看读写锁ReentrantReadWriteLock在共享和独占之间切换的细节。每一步都要配合debug跟踪打印线程名和队列变化比自己盯着源码空想要高效得多。我当时在本地起了一个多线程的小demo故意让几个线程争抢同一把锁然后在intellij里设置条件断点看队列节点的变化这样印象会比干读深好几倍。2.3 线程池七个参数以及面试官最爱追问的三种场景线程池是并发高频考点中的高频。七个参数要能默写corePoolSize核心线程数、maximumPoolSize最大线程数、keepAliveTime空闲存活时间、unit时间单位、workQueue任务队列、threadFactory线程工厂、handler拒绝策略。面试官不会满足于让你背参数。最经典的追问是一个任务提交进来后执行流程是怎样的标准答案是先判断核心线程是否满没满就创建核心线程执行满了就把任务放到工作队列队列也满了再创建非核心线程执行线程数达到maximumPoolSize后触发拒绝策略。这个顺序如果记混后面所有延伸问题都会答歪。第二个高频追问是线程池大小怎么定这个问题没有标准答案但有通用的估算思路。CPU密集型任务线程数建议设为CPU核数加1IO密集型任务可以设为CPU核数乘以2或者用公式CPU核数乘以1加上等待时间除以计算时间。实际项目中很少精确计算通常是压测后调整。面试时能说出我是这么定大小的先按业务类型判断是CPU密集还是IO密集给一个理论值再压测调整比直接报一个数字有价值得多。这里顺便给一个本地压测的方法用JDK自带的ThreadPoolExecutor写一个小程序循环提交模拟任务通过ThreadPoolExecutor的getPoolSize()、getQueue().size()、getActiveCount()等指标观察线程池状态变化再配合JMCJDK Mission Control的线程诊断视图基本能判断出参数是否合理。第三个追问是拒绝策略分别适合什么场景这张表需要记清楚拒绝策略行为表现适用场景AbortPolicy直接抛RejectedExecutionException默认策略任务不能丢且要快速感知CallerRunsPolicy由提交任务的线程自己执行不想丢任务允许任务执行变慢DiscardPolicy静默丢弃任务允许丢弃对数据不敏感DiscardOldestPolicy丢弃队列中最旧的任务任务有有效期如缓存刷新这里我想强调一个容易被忽略的坑自定义线程池时不要用Executors自带的便捷方法尤其不要用newFixedThreadPool和newSingleThreadExecutor它们内部用的都是无界队列LinkedBlockingQueue任务堆积时不会有拒绝策略兜底极端情况下内存会被撑爆。业界流传较广的Java开发规范里明确建议线程池要手动创建显式传入有界队列和饱和策略。比如用ArrayBlockingQueue且容量设一个合理上限配合CallerRunsPolicy让生产者在队列满时自己承担执行压力反而能形成天然的背压机制。最后一个实用细节核心线程默认不会预创建要等任务提交才创建。如果希望系统启动时就准备好核心线程可以调用prestartAllCoreThreads()这在流量突刺明显的场景下很管用能省去冷启动阶段的线程创建时间。另外线程池里的线程命名千万别用默认的pool-1-thread-1排查问题时日志里根本分不清谁是谁自定义一个ThreadFactory加上业务前缀线上定位问题会轻松很多。3. 下午模拟面试一场对话暴露三个真实短板3.1 追问一队列满了新任务到底去哪下午的模拟面试我拉了同为求职者的好友来当面试官约定好只做技术追问全程录音。第一道题就是线程池流程的连环追问。我答到队列满了就创建非核心线程的时候对方突然追问如果maximumPoolSize也满了任务交给谁我卡了两秒才想起拒绝策略但只说出一个AbortPolicy另外三个说不全。复盘时发现这次卡壳不是不会而是平时没有把拒绝策略当成一个独立的知识块来组织只是零散地记了几个名词。正确回答的框架是先说流程再说兜底核心线程满到队列满到非核心线程满最终触发拒绝策略拒绝策略有四种默认AbortPolicy抛异常项目上我一般用CallerRunsPolicy做背压或者自定义策略做降级记录。把这个流程练成肌肉记忆再遇到任何延伸问题比如队列用有界还是无界、为什么不用Executors默认线程池就都能接住。模拟面试的价值就在这里平时看资料是线性输入面试是跳跃式追问两种思维模式完全不一样。录音回放之后我才发现自己回答问题喜欢绕弯子先说一堆背景才给结论。面试官的耐心是有限的正确做法是先给结论再展开细节。这一点不改真实面试要吃大亏。3.2 追问二ThreadLocal为什么内存泄漏第二个没答好的是ThreadLocal的内存泄漏。我能说出ThreadLocalMap的key是弱引用value是强引用所以会泄漏但当面试官追问为什么弱引用反而会导致泄漏时我解释不清楚。回来重新梳理这次彻底弄明白了。ThreadLocal的每个线程里都有一个ThreadLocalMap它的Entry继承WeakReferencekey是ThreadLocal对象value是开发者set进去的值。key被设计成弱引用的本意是当外部不再持有ThreadLocal对象时key可以被GC回收。但问题在于value是强引用key被回收后Entry变成key为null、value还活着的状态如果线程不销毁这个value就永远没机会被回收。什么场景最容易触发线程池。线程池里的线程会复用生命周期很长ThreadLocalMap一直挂在线程上value就一直在内存里。解决方式也简单用完必须remove。规范写法是用try-finally包裹ThreadLocalSomething local new ThreadLocal(); try { local.set(value); // 业务逻辑 } finally { local.remove(); // 必须清理防止线程池场景下的内存泄漏 }这个问题的颗粒度今天算彻底补齐了。从知道会泄漏到能讲清楚为什么泄漏、什么场景触发、怎么预防这才是面试要的深度。3.3 追问三现场给你一个死锁你会怎么查最后一个追问是线上服务突然卡住所有请求都不响应怀疑是死锁你会怎么排查我之前只准备了死锁的定义两个线程互相持有对方需要的锁真到排查环节就懵了。面试官点了一句你会用什么命令我才想起jstack。排查死锁的标准流程其实很固定背下来就是肌肉记忆。先用jps找到Java进程ID再用jstack输出线程快照jstack本身会在末尾自动检测死锁输出一行Found one Java-level deadlock。那段输出里会明确指出哪两个线程互相等待哪把锁。实际操作命令如下jps -l jstack pid thread_dump.txt # 在dump文件里搜索 deadlock 关键字除了死锁这个命令还能顺手查另外两类线上问题线程长时间BLOCKED说明锁竞争激烈线程大量WAITING且堆栈停在等待队列上可能是线程池配置不合理。很多线上问题第一现场都在线程快照里Day51的求职者最好能做到手写jps和jstack的用法。我也顺手补了jmap -heap看堆内存、jstat -gcutil看GC频率这些在面试聊JVM调优时都会用到。模拟面试结束后我把三个短板记进了错题本每一条都写了一句话版标准答案方便早晚过一遍。错题本这个习惯从Day20坚持到现在已经积累了四十多条考前翻一遍比临时抱佛脚刷新知识有效得多。4. 晚间算法两道手热题的复盘与刷题节奏管理4.1 二叉树的最近公共祖先递归解法拆解算法部分今晚做了两道。第一道是二叉树的最近公共祖先是一道出现频率很高的树类题目。题目描述很简单给定一个二叉树和两个节点p、q找到它们的最近公共祖先。递归解法核心是定义清晰在当前节点root这棵子树里找p和q的最近公共祖先找到就返回该祖先节点找不到但子树中包含p或q就返回对应节点都不包含返回null。代码可以写得非常短public TreeNode lowestCommonAncestor(TreeNode root, TreeNode p, TreeNode q) { if (root null || root p || root q) { return root; } TreeNode left lowestCommonAncestor(root.left, p, q); TreeNode right lowestCommonAncestor(root.right, p, q); if (left ! null right ! null) { return root; } return left ! null ? left : right; }这道题的关键在于理解递归返回值的三层含义返回null表示这个子树里既没有p也没有q返回p或q表示子树中找到了其中一个返回其他节点说明这个节点就是p和q的最近公共祖先。面试时如果只把代码写出来而不解释返回值语义很容易被追问到语法细节上卡壳。进阶版本二叉搜索树的最近公共祖先可以用更简单的解法利用BST的节点值大小关系从根节点向下走找到第一个值介于p和q之间的节点就是答案。这个变体很容易被拿来作为追问最好一并准备。我当时把两个版本的代码放在同一页笔记里对比记忆效果不错。4.2 无重复字符的最长子串滑窗思路的边界处理第二道是无重复字符的最长子串滑窗的经典题。这类题目的通用套路是右指针不断向右扩展把字符加入窗口用一个哈希表记录字符最后出现的位置遇到重复字符时左指针跳到重复字符上一次出现位置的下一个位置每次右指针移动后更新答案。public int lengthOfLongestSubstring(String s) { MapCharacter, Integer map new HashMap(); int left 0; int maxLen 0; for (int right 0; right s.length(); right) { char c s.charAt(right); if (map.containsKey(c)) { left Math.max(left, map.get(c) 1); // left只向右跳不可能回退 } map.put(c, right); maxLen Math.max(maxLen, right - left 1); } return maxLen; }这里有一个很容易写错的细节左指针更新时为什么要用Math.max而不是直接left map.get(c) 1因为在滑窗过程中left可能已经超过某个重复字符上一次出现的位置此时如果把left回退到更小的位置窗口内会出现新的重复字符。这类边界问题光看题解体会不到自己多写错几次就记住了。我第一次提交就是在这个地方踩坑用了一个反而把窗口扩大的bug用例才反应过来。4.3 第51天的刷题节奏两新两旧复盘优先进入第51天我的刷题节奏已经固定成两新两旧每天两道新题两道之前做错的旧题周日停下来完整复盘本周的错题。这个安排看起来慢实际上比每天狂刷五道新题高效得多。错题重做时如果第二遍还要看题解说明第一遍就没彻底掌握需要再标记、隔一周再重做如果独立写出且时间达标才算真正过关。刷题还有一个容易被忽视的细节一定要写注释标注每道题的核心思路和易错点。一个月后翻看相当于有一本自己的算法错题集。面试前一天不需要重新刷题把错题集过一遍就够了。5. 简历项目怎么讲才能在一分钟内建立区分度5.1 三个维度业务理解、技术难点、量化数据晚上花了两个小时重新打磨项目的讲述逻辑。到了Day51这个阶段项目已经没有时间做大改了能优化的主要是怎么讲。同样是做过一个商城项目有人讲得像流水账有人能讲出亮点差距在这三个维度。第一是业务理解。你能不能介绍清楚这个项目解决的是谁的问题、业务流程的完整链路是什么、核心表结构怎么设计的、为什么订单和库存要分表。业务理解不行技术细节讲得再花哨面试官也只当你在背项目。我准备项目时给自己列了一个问题清单这个系统有几个核心角色、每个角色有哪些操作、这些操作涉及哪些表、表的关联关系是什么。能把这些问题不假思索答出来业务这一关才算过了。第二是技术难点。项目里一定要有一两个能讲深的技术点。比如秒杀场景你怎么防超卖、高并发下你怎么保证缓存与数据库的一致性、分布式场景下订单号怎么做全局唯一。难点不在于多而在于你能不能把背后的原理讲透包括为什么用这个方案、还有什么替代方案、各自的缺陷是什么。我给自己定的标准是准备两个技术难点每个难点都要能讲到三个层次——方案是什么、为什么选它、它有什么局限。第三是量化数据。没有数据的项目描述是没有说服力的。不要说系统性能提升了要说经过优化后接口压测QPS从200提升到1500P99响应时间从480ms降到120ms。数据从哪里来没有线上环境就自己压测本地JMeter压测也能跑出数据。面试官听到具体数字印象分会高不少。5.2 一段自我演示的话术拆解我给自己设计了一个模板按背景-职责-难点-结果四步来讲一个模块大概控制在三分钟以内。拿一个典型的订单超时关闭功能举例背景是项目里有一个用户下单后30分钟未支付就自动关闭订单的需求最初实现方案是定时任务每分钟扫描一次订单表但订单量大之后扫描效率很低而且存在bug风险。我的职责是把这个方案改造成延迟消息机制。难点有两个第一是怎么保证消息不丢失第二是怎么在分布式环境下避免同一个订单被重复关闭。我的做法是消息队列延迟消息加消费端幂等校验压测结果是订单关闭的及时率从平均两分钟提升到秒级重复关闭的问题完全消除。这段话术的要点是先给结论再讲过程用数字兜底主动交代方案的不足。面试官听完会觉得你既有思考深度又有落地能力。建议每个人都根据自己的项目写一个这样的版本反复练习到不用看稿。5.3 面试官最常追问的三个问题提前准备答案项目讲完之后面试官一定会有追问。我把高频追问整理成了三类。第一类为什么选这个技术方案比如为什么用消息队列而不是定时任务这个问题考察的就是你做技术选型时的思考过程。标准回答思路是从两个维度对比实时性要求和资源消耗。定时任务的实时性差扫描间隔决定了延迟上限消息队列可以做到事件驱动几乎实时触发但引入了一个中间件增加了运维复杂度。说出这两者的取舍关系比只夸消息队列好用强得多。第二类这个方案的瓶颈在哪里正确做法是自己指出短板并说明改进思路。比如延迟消息依赖消息队列如果消息队列挂了订单就可能一直不关闭所以我会加一个兜底定时任务扫描超时未支付且没有关闭的订单。主动交代短板并给出兜底方案反而会让面试官放心。第三类如果数据量涨十倍你的方案还扛得住吗这类问题考察的是可扩展性意识。回答时不要慌可以从水平扩展、读写分离、缓存分层等方向展开。重点是让面试官看到你有这个意识而不是真的要求你现在就把新方案设计出来。6. 求职中后期避坑清单来自踩坑者的直接忠告6.1 学习资源怎么选做减法而不是囤积第51天回头看我在学习资源上踩过最大的坑是贪多。收藏夹里躺着几十个课程和学习资料真正刷完的没几个。求职准备进入中后期资源选择的原则应该是做减法主线技术各选一份系统的资料配合官方文档和源码最多再加一份高质量的面经汇总其余的收藏等于没收藏。面经的使用方法也有讲究。不要只把题目和答案抄下来背正确做法是拿到一道题先不看答案自己写一版回答再对着参考修正。只有自己组织过的答案才记得牢。我前面提到的错题本就是面经消化后的产物。6.2 时间分配别用战术勤奋掩盖战略懒惰很多人在这个阶段仍然把大量时间花在学新知识上这是很危险的。Day51的正确时间分配应该是六成时间复习和深挖已有知识三成时间模拟面试和整理错题一成时间保持算法手感。如果你还在花大量时间看新的技术栈说明前期知识地图铺得不够这时候更要停下来补短板而不是继续往前赶。我每天晚上的例行动作是翻一遍当天的错题本计划明天的三个任务。任务控制在三个以内完成一个勾掉一个。这个习惯帮我避免了很多次感觉学了一天回想起来什么都没学的情况。Day51这天也不例外明天的任务已经列好了重写一遍线程池的实现流程、整理JVM调优命令、重做两道链表错题。6.3 心态崩盘自救指南Day51的倦怠期怎么过走到第51天倦怠感是真实存在的。你可能会觉得知识越学越多、忘得越来越快也可能因为某次模拟面试的糟糕表现而怀疑自己。我自己的几个自救方法分享给同样在坚持的人。第一把目标切小。不要总想着我要进某家公司太重了容易压垮人。把目标改成今天要把线程池流程讲清楚明天要把这个项目的缓存一致性方案整理完小目标完成带来的正反馈比大目标管用得多。第二主动找人交流。一个人闷头复习很容易陷入自我怀疑找到一个水平相当的朋友互相模拟面试、互相检查错题效率会成倍提升。我今天的模拟面试就是这种交流的产物。第三接受遗忘是正常的。记忆的本质是遗忘后的再提取复习一遍忘一些、再复习再忘反复几轮之后才真正变成长期记忆。不要因为今天忘了昨天的内容就焦虑这恰恰说明你在正常地学习。我在模拟面试里暴露短板的时候第一反应确实是有点沮丧但冷静下来想想这其实是好事。面试前暴露的问题越多真实面试时踩的坑就越少。Day51的意义不在于你完成了多少学习量而在于你终于开始像一个求职者那样思考不是我学了什么而是面试官会怎么问、我怎么答得更好。最后分享一个这几十天坚持下来的小技巧每周日晚用半小时写一篇本周复盘只写三个内容——本周搞定的三个知识点、本周暴露的两个短板、下周最想补的一个方向。这个节奏让我在第51天回头看时能清楚看到自己从Day1到现在走过了多远。走到这里不容易剩下的事就是把这些天的积累稳稳地倒出来。