从分段锁到桶级锁：ConcurrentHashMap并发设计演进与实战解析

1. 从JDK 7到JDK 8：分段锁为什么被推翻

1.1 JDK 7的Segment分段锁到底做了什么

很多讲ConcurrentHashMap的文章喜欢直接讲JDK 8的源码，但我建议先花点时间看明白JDK 7的Segment设计。原因很简单：任何设计哲学都是带着历史包袱向前走的，不懂"过去为什么这样选"，就很难理解"现在为什么改掉"。

JDK 7的ConcurrentHashMap采用了一个叫Segment的内部类作为锁主体。Segment本身继承了ReentrantLock，也就是说每个Segment天生就是一把可重入锁。整个Map被分成16个Segment（默认值），put操作先经过一次hash定位到某个Segment，然后只锁住这个Segment，其他15个Segment照常读写。这种设计在当时的硬件环境下确实是巨大的进步，因为它把"整个Map一把锁"的粒度一下子缩小到了1/16，理论上写并发能提升16倍。

但这里要泼一盆冷水：所谓"提升16倍"只是一个线性的理论上限。真实场景下，如果你的数据分布不够均匀，某个Segment上的流量可能远高于其他Segment，这个Segment就会成为瓶颈。JDK 7没有机制动态调整Segment数量，一旦初始化就是固定16个，这也带来了问题——Map越大，每个Segment维护的桶越多，链表越长，查询退化成链表遍历的概率越高。

1.2 从"分段"到"桶级"：锁粒度的一次彻底收敛

JDK 8是把ConcurrentHashMap推翻重写的一版，不是简单优化，而是整个并发控制策略都换了。核心变化有两个：一是放弃了Segment这种重型锁对象，直接用table数组的每个桶（bin）作为同步点；二是把原来"无脑加锁"的写法改成了"CAS优先、synchronized兜底"。锁粒度从Segment级缩小到了桶级，理论上并发度从固定的16变成"只要hash均匀，每个桶都能同时写"。

这个改变的哲学意义比性能数字更值得关注。Java的synchronized经过多年优化，在无竞争场景下已经轻量到几乎可以忽略不计，而JDK 7用ReentrantLock作为Segment锁，反而显得笨重。JDK 8换用synchronized锁桶节点，既吃到了JVM内置锁的优化红利（偏向锁、轻量级锁、重量级锁的升级路径），又让代码结构大幅简化——你可以直接读到put方法的完整逻辑，不再需要跨类去理解Segment的继承体系。

1.3 设计目标的变化：从"尽力提升并发"到"并发安全下的极限吞吐"

其实JDK 8的ConcurrentHashMap还有一个暗藏的目标，那就是让并发安全不要成为性能的代价。JDK 7时代，Segment锁毕竟是真锁，读写之间也有竞争；JDK 8的get操作完全无锁，只有写写才在桶级别上竞争一下。这个转变的背后，是对现实场景的重新审视——大多数分布式系统里，读多写少是常态，读的吞吐往往比写的吞吐更敏感，所以把读路径优化到"无锁"才是收益最大的方向。

我看到过很多技术文章喜欢吹捧"分段锁"的设计，把它称为并发编程的典范。但从工程实践来看，JDK 8之所以抛弃这个典范，恰恰说明所谓"最佳实践"永远要服从于硬件的演进和真实场景的反馈。分段锁在当时是进步，在今天是包袱。这个"推翻自己"的勇气，才是ConcurrentHashMap设计哲学里最值得学习的一点。

2. get()方法凭什么敢不加锁

2.1 volatile、final与内存可见性的三重配合

如果你打开JDK 8的源码，会看到getNode方法里并没有任何加锁操作，它只做了几件事：定位桶、遍历链表或红黑树、比较hash和key、返回value。那问题来了，并发写入时，get怎么保证不读到脏数据？怎么保证不会读到一半链路断裂？

答案藏在两个修饰符里：table数组是volatile的，Node的val和next字段是volatile的。volatile保证的是"发生写操作之后，其他线程的读操作立即可见"，而不是很多初学者理解的"读操作永远拿到最新值"。这里有个微妙点——get不加锁，意味着它可能读取到某个线程写入前的旧值，但只要满足线性一致性（linearizability），旧值也是合法的。ConcurrentHashMap的语义不是"每次读取都拿到最新值"，而是"每次读取都能拿到某一个已完成写操作的值，且不会读到写了一半的中间状态"。

这句话怎么理解？我给你打个比方。你在一个公告栏上查看今天的值班表，有人正在用新的值班表替换旧的。如果你恰好在替换过程中看了一眼公告栏，看到的内容可能还是昨天的值班表——这可以接受；但你绝不应该看到"姓名已经更新了、时间还是旧的"这种残缺组合。volatile保证的是后者——要么看到完整的旧表，要么看到完整的新表，不存在看到中间状态的可能。

2.2 红黑树结构下的读安全：TreeBin的锁机制

不过链路断裂的风险并不只存在于链表上。当某个桶的链表长度超过阈值后，会转换成红黑树。红黑树的节点和链表节点不一样，Node本身是单向链表的形态，而红黑树节点TreeNode有parent、left、right、prev等指针，这些字段没法全部用volatile修饰，否则内存开销太大。

所以TreeBin在设计上动了个心眼：读操作走红黑树时，先检查一个volatile的lockState字段。如果当前没有写线程持有锁，读线程可以直接无锁遍历红黑树；如果lockState表明有一个写线程正在修改红黑树，读线程会退化成"锁住整个TreeBin"再读，或者走另一个近似链表遍历的通道。这种"能无锁就无锁，必须有锁才加锁"的思路，本质上是把读操作从完全无锁变成了大部分时间无锁，偶尔退化。

这里有一个很实际的性能细节：红黑树的查找时间复杂度是O(log n)，但它只有在桶内节点数足够多时才会启动。大多数真实Map中，桶的深度很浅，链表遍历反而比红黑树快。所以JDK 8的树化阈值设置为8是有讲究的，这个我在后面单独讲，现在先记住一个结论：红黑树只是ConcurrentHashMap在极端桶深情况下的兜底方案，不是常规路径。

2.3 弱一致性的迭代器：你以为的快照其实不是快照

很多使用ConcurrentHashMap的同学都知道它的迭代器是"弱一致"的，但弱在哪，很多人说不清楚。HashTable的迭代器是强一致的——遍历时如果其他线程修改了Map，会立刻抛出ConcurrentModificationException。而ConcurrentHashMap的迭代器允许遍历期间有其他线程并发修改，它不会抛异常，但也不会保证遍历到的数据是某一时刻的完整快照。

具体来说，弱一致性体现在三个层面：迭代过程中新插入的节点可能遍历到，也可能遍历不到；被删除的节点，已经遍历到的还能继续访问它的值；迭代器和写操作之间没有任何锁竞争，所以遍历期间CPU的开销完全不受并发写入影响。

我举个例子，你正在遍历Map的前半段，此时另一个线程往Map里插入了大量数据，触发了扩容。扩容发生之后，新表和老表之间会通过ForwardingNode过渡（这个在后面扩容章节细讲）。迭代器走到某个已经被迁移完的桶时，会通过ForwardingNode找到新的桶地址继续遍历——它不会停下来说"对不起，我遍历不了"，而是会尝试跟上数据搬家的节奏。正是因为这种设计，这种迭代器在某些实时计算场景下（比如每隔几百毫秒扫描一次全量配置）表现非常好，不会因为遍历而阻塞任何写操作。

3. put写入路径的锁博弈：从CAS自旋到synchronized

3.1 空桶插入的CAS为什么不用锁

put方法的第一层判断，是定位到数组下标后，如果发现这个桶是空的，就尝试用CAS把这个新节点放进去。CAS是Compare-And-Swap的缩写，它的语义是"如果内存中的值是我期望的值，才把它改成新值，否则什么都不做"。这个操作是CPU指令级别的原子操作，不需要操作系统介入，也没有线程调度和上下文切换的开销。

选择CAS + 自旋，而不是直接加锁，原因是空桶插入是put路径上最高频的分支——大量写入的key如果hash足够分散，很多桶的第一次插入都会走这条路。如果在这里加锁，即使是synchronized轻量级锁，也会有不小的开销。而CAS只需要一条cmpxchg指令，失败了再试一次，几个循环内基本都能成功。

但CAS不是万能的，它有一个著名的ABA问题——别的线程把A改成B又改回A，CAS无法感知这个过程。ConcurrentHashMap里CAS操作的对象是桶节点的引用，节点本身是不可变的（一旦创建，hash、key、val都不再变化），所以"节点被改掉又改回来"的场景不可能发生，这等于从设计上规避了ABA问题。这种"用不变性消除风险"的思路，也是并发编程里很高级的手法。

3.2 桶不为空时，synchronized锁的究竟是谁

如果桶不为空，意味着已经有别的线程在这个桶上插入了节点。此时put方法会锁住这个桶的头节点，然后开始遍历链表或者红黑树。这里有个非常关键的概念：锁的是桶的头节点，而不是整个桶的对象。头节点作为锁对象的好处是，它是一个普通的Node实例，作为锁时不需要额外创建锁对象；而且相同hash桶的新写入都会落到同一个头节点上，互相之间自然互斥；不同桶则各自有不同的头节点，互不干扰。

这跟JDK 7的方案有本质区别。JDK 7的锁是放在Segment上的，16个Segment锁住了所有的桶；JDK 8的锁放在头节点上，理论上每个桶都有一把独立的锁。两个线程同时写两个不同桶，完全不会互相阻塞；两个线程同时写同一个桶，才会发生锁竞争。这就是"锁粒度从分段到桶级"的真正落地。

说到synchronized，这里还有一个旧时代的人很难接受的点：JDK 8之后，synchronized经过JIT的锁消除、锁粗化、偏向锁等一系列优化，在低竞争场景下性能已经优于ReentrantLock。JDK的维护者用synchronized锁桶头节点，不仅是语法上更简洁，也是实实在在的性能选择。这里没有"高级锁一定比低级锁好"的道理，适合自己的才是最好的。

3.3 树化阈值为8：泊松分布背后的"玄学"与数学

这个"8"是Java并发面试题里出现频率最高的数字之一。官方注释给过一个泊松分布的计算：在负载因子0.75、哈希函数随机分布的前提下，单个桶内出现链表长度达到8的概率约为千万分之六。也就是说，链表长度达到8是极小概率事件，如果真发生了，通常意味着hash函数出了问题，或者这个key被恶意构造，专门把大量key映射到同一个桶。

但我要提醒你别对这个数字过于迷信。官方注释说的是"理想随机分布下的概率"，实际业务中的key分布不可能完全理想。比如你用String作为key，String的hashCode算法是固定的，如果有人恶意构造一批hash碰撞的字符串，桶深瞬间就能到8。这就是为什么JDK 8在树化之外还保留了链表转树的另一个条件：table数组的长度必须达到64。如果数组长度只有16或32，即使某个桶链表很长，也不会树化，而是先走扩容，把桶分散开。这套"先扩容、再树化"的双重判断，才是工程上防DDoS攻击的完整方案。

我建议你在业务代码里把"树化阈值"理解成一个恢复阈值，而不是触发阈值。真正的触发链路是：桶内节点数超过8且table长度超过64，链表转红黑树；当红黑树节点数降到6以下时，再转回链表。中间留了7这个缓冲带，避免在8和6之间来回抖动，反复转换导致性能损耗。这类"阈值之间留余量"的设计，在很多并发组件里都能看到，本质上是给系统的振荡提供阻尼。

4. 多线程协助扩容：一场"拆迁"工程

4.1 扩容为什么需要"协作"而不是"互斥"

如果你只看Hashtable的扩容，它的流程很简单：锁住整个map，新建一个更大的数组，然后一个线程把旧数组所有数据重新哈希搬过去，搬完再释放锁。这个过程是"独占式"的——扩容期间其他线程全都得等。当Map数据量达到千万级别时，这样一次全局锁扩容，可能要阻塞几十毫秒甚至更久，这对高并发业务来说是不可接受的。

ConcurrentHashMap给出的答案是"协作式"扩容。它不要求一个线程把整个搬迁包圆，而是把迁移任务拆分成一块一块的，多个线程同时参与搬迁，你搬一段、我搬一段，互相不冲突、各有分工，谁有空谁就来帮忙。这种"多线程拆迁"的设计哲学，核心挑战是如何保证搬迁过程中读写操作不出现错乱。

4.2 transferIndex与stride：任务怎么切

扩容任务被切成一个个连续区间，区间的长度由stride决定。stride的计算公式在源码里是 stride = (n >>> 3) / NCPU，其中n是旧数组长度，NCPU是CPU核数。简单来说，就是让每个线程平均分到的迁移量大致相当，下限是16，因为小于16个桶区间就没有切分的意义了。

整个任务池由一个volatile变量transferIndex来分配。比如旧数组长度是1024，stride是16，那队列就是1024/16=64个任务。某个线程需要迁移时，先通过CAS将transferIndex从634改成618，这表示"最后16个桶由我来搬"。拿到自己的任务区间后，这个线程从后往前搬。这种"从后往前"的方向选择也是有讲究的——后部的桶通常是最近新插入的数据所在区域，先用它来引导扩容时的并发写入，可以减少插入线程与新搬迁任务之间的冲突。

每次搬完一个区间的桶，线程会再次CAS更新transferIndex，领下一段任务。如果transferIndex已经变成0，说明所有旧桶都被认领完了，那就退出搬迁。最终，只有最后一个完成所有搬迁的线程负责把nextTable赋值给table，并清理一些临时状态。整个过程没有锁，全靠volatile的可见性和CAS的原子性来驱动任务分配。

4.3 ForwardingNode：拆迁现场的路标

扩容期间，读写线程怎么知道一个桶已经被搬走了？答案就是ForwardingNode，简称FWD节点。源码里FWD节点继承自Node，hash值是一个特殊常量MOVED（-1）。扩容刚开始时，每个桶在搬迁完成后，旧数组的这个位置会被放入一个FWD节点。任何线程看到FWD节点，就明白"这个位置已经处理过了，别再管它了"。

具体到读写操作，规则是这样：写线程在put时如果发现桶头是FWD节点，会主动调用helpTransfer方法，加入到协助扩容的大军中；读线程在get时如果发现桶头是FWD节点，会沿着节点里的nextTable引用跳到新数组对应的桶去继续查找。这个设计非常精妙：FWD节点同时起到了"标记已完成"和"指向新地址"的双重作用，让旧数组在扩容期间的任意时刻都可以安全地接受读请求。

看到这里你应该能理解，为什么get方法在扩容期间不需要等待——它总能顺着FWD节点找到数据的新位置。整个扩容过程对读线程是几乎无感知的，只是偶尔多跳一次指针而已。而对写线程来说，最坏的情况不过是"先帮别人搬砖，搬完再写自己的数据"。这种"让阻塞变成协作"的思路，才是整个扩容设计的灵魂。

4.4 扩容时的新数据到底写哪

这里有个容易被忽略的问题：扩容期间，如果有一个新数据要插入到已经搬迁完成的桶里，它写到旧数组还是新数组？

答案是：写到新数组。因为旧数组那个位置已经被FWD节点占领了，put线程看到FWD后就会参与扩容，扩容完成后再把数据插入到新数组对应位置。但如果这个桶还没被搬迁，put线程会直接把数据插入旧数组的对应桶——这个桶将来迁移时，会把新插入的节点一并搬过去。这个设计保证了扩容期间不会有数据写丢，也不会有数据重复，每个桶的数据要么在旧数组原封不动地等着搬迁，要么已经带着新插入的数据搬到了新数组。

很多人在分析代码时会困惑："迁移时万一有线程正在写这个链表的尾部怎么办？"答案是：搬迁动作本身会锁住这个桶的头节点。在迁移线程锁住头节点的瞬间，写线程无法再往这条链表上追加新节点，所以迁移看到的是一个稳定的链表快照。这个"迁移时加锁、平时不加锁"的策略，是整个扩容正确性的最后一块拼图。

5. 这些"暗坑"才是真实的面试考点

5.1 为什么ConcurrentHashMap不允许null的key或value

这是一个面试高频题，但回答角度往往都很浅。很多人说"因为代码里会NPE"，那为什么HashTable允许null而ConcurrentHashMap不允许？标准答案常引用Doug Lea的观点：并发环境下无法区分"值为null"和"键不存在"。但我的理解更倾向于从源码的约束来看，get方法返回null有两种可能：一是不存在这个key，二是存在但value恰好是null。在没有加锁的情况下，即使你判定了"结果为null说明不存在"，也无法阻止另一个线程瞬间插入这个key并赋值null。这个逻辑上的模糊地带，会在依赖返回值做判断的业务代码里制造难以复现的隐性bug。

还有一个更实际的考虑：如果允许null作为value，那get方法就必须区分"该key不存在"和"该key的value为null"，否则外部就无法区分。但ConcurrentHashMap内部putVal方法里有一条判断，如果key或value为null，直接抛出NullPointerException。这样做的好处是，调用方的语义变得极简单——只要看到null返回值，就已经确定了key不存在，不需要额外的containsKey检查。给使用方减少一个并发判断分支，这才是设计者的真实意图。

5.2 computeIfAbsent的"锁内干活"陷阱

这是我在生产环境里真正踩过坑的地方。computeIfAbsent方法在JDK 8中新增，语义是"如果key不存在，则用mappingFunction计算并放入新值"。看起来是个很便捷的原子操作，但它有个特性很多人没意识到：当桶不为空时，整个函数在锁住桶头节点的同步块内执行。如果mappingFunction里做了一些耗时操作——比如查数据库、调远程接口、做复杂计算——那这个桶的写入操作会被长时间阻塞。

还有更隐蔽的问题：mappingFunction里如果反过来操作同一个ConcurrentHashMap，比如调用这个map的get或者put方法，会引发死锁吗？不会死锁，因为synchronized是可重入的。但如果你递归地调用computeIfAbsent去计算同一个key，就可能造成无限递归，最终栈溢出。我曾经见过一个线上OOM，排查到最后就是同事在computeIfAbsent里对同一个map做了一次"安全"的get，本以为没问题，结果get触发了另一个key的computeIfAbsent，最终形成了环。

我的建议是：computeIfAbsent里的mappingFunction只做纯内存计算，不做任何IO。如果你需要"不存在才初始化"的逻辑，并且初始化操作涉及网络调用，先把它拆开写——先get判断，再单独加锁初始化，或者改用putIfAbsent配合提前构建好的值，这样能避免锁内干活带来的性能劣化。

5.3 size()与mappingCount()的差异

ConcurrentHashMap的size()方法返回值是int，而mappingCount()返回long。官方文档甚至建议，当Map容量可能超过int范围时，用mappingCount()更合适。但在实际使用中，这个问题比"int不够用"更微妙。

JDK 8的size()不像JDK 7那样需要给所有Segment加锁来统计，而是通过维护一个baseCount变量，以及在写入时通过CAS递增，在元素数量变化时更新一个CounterCell数组来避免多线程竞争。但注意，计算size()时并不会加锁，它只是把baseCount和所有CounterCell的value加起来。因此，统计结果是一个近似值——在统计过程中发生的插入和删除，可能导致结果偏大或偏小。这跟迭代器的弱一致性是一脉相承的。

所以如果你依赖size()做精确判断，比如"当前缓存数量超过1000就淘汰一批"，在高并发环境下会出问题。好的做法是保留一个自己的AtomicLong计数器，在put和remove的成功路径上手动维护。ConcurrentHashMap不是不能让你用，而是你要理解它的统计语义是"尽力而为"。

5.4 并发场景下的复合操作：先检查后写入不是原子的

很多同学以为用了ConcurrentHashMap就万事大吉，这是最大的认知误区。ConcurrentHashMap只保证单操作的线程安全，不保证你业务层面"先读后写"的复合操作是原子的。

比如你这个逻辑："先检查key是否存在，不存在才写入"。用containsKey判断后put，两个操作之间可能存在另一个线程抢先插入了相同key，最终导致重复创建，或者覆盖了你不想覆盖的数据。正确的做法是用putIfAbsent方法，把"检查+写入"变成一个原子操作；或者在get之后根据业务要求做进一步判断，然后再决定是否put。

这个道理听起来简单，但在实际代码里我见过太多"用着并发容器、犯着并发错误"的例子。容器提供的原子方法就那么几个：putIfAbsent、remove(k,v)、replace(k, oldV, newV)、compute系列。当你发现自己在用一个"读"加上一个"写"拼业务逻辑时，大概率需要换一个原子方法，或者自己引入分布式锁。这是一个设计警觉问题。

6. 从设计哲学看使用：场景决定容器选择

6.1 读多写少 vs 写多读少的两种命运

ConcurrentHashMap的读路径无锁、写路径锁桶，这个设计让它天然适合"读多写少"的场景。典型的应用有：本地缓存、配置中心客户端缓存、注册中心的服务列表、Spring的单例Bean缓存。这些场景的共同特征是：读取频率极高，写入频率较低，偶尔发生一次全量刷新或局部更新。

但如果你有一个"写多读少"的场景，比如每秒写入上万条日志统计，ConcurrentHashMap就没那么合适了。每个不同的key虽然分布在不同的桶，但写入动作本身涉及CAS和可能的锁竞争，开销还是比专门的写入优化结构（比如LongAdder用于计数、ConcurrentSkipListMap用于有序写入）要大。这种情况下，我更建议先明确你的核心瓶颈是读还是写，而不是无脑上ConcurrentHashMap。

另外还有一种常见的"误解式使用"：拿ConcurrentHashMap当消息队列用，用put和remove模拟offer和poll。这种用法虽不会出错，但它的扩容机制、桶锁策略、弱一致性迭代器都不是为FIFO场景设计的，还不如用LinkedBlockingQueue或者ConcurrentLinkedQueue来得清晰。容器选型这件事，其实是先定义清楚读写模型再选，而不是反过来。

6.2 ConcurrentHashMap与Collections.synchronizedMap的对比

在ConcurrentHashMap出现之前，Collections.synchronizedMap是最常用的线程安全Map方案。它的实现方式极其朴素：内部包装一个普通Map，再把所有方法都用synchronized(this)锁起来，让所有读写互斥。优点是实现简单、默认行为可预测，缺点是任何读操作都会阻塞，并发越高越明显。

我用一个简单的对比表帮你建立直观感受：

这个表格只是帮你理解差异，真正决定选择的是业务对"读延迟"的敏感度。如果你能接受读操作偶尔等待写锁，用synchronizedMap也能跑；但一旦你想让读吞吐量最大化，ConcurrentHashMap几乎是唯一的正道。

6.3 初始容量与并发级别：两个参数到底调哪个

ConcurrentHashMap有两个构造参数：initialCapacity和concurrencyLevel。JDK 7中concurrencyLevel决定Segment数量，直接影响并发度；JDK 8中concurrencyLevel被重新定义了，它只作为"预估并发线程数"来帮助计算初始容量大小，不再决定内部锁结构。如果你不传concurrencyLevel，JDK 8会根据initialCapacity计算一个合适的table容量，保证平均每个桶预估只放一个元素。

实际调优时我会建议：如果你能预估大概会存10万条数据，初始容量就给10万除以负载因子0.75再加一点余量，也就是大概14万。如果你设置得过小，ConcurrentHashMap会频繁扩容，而扩容虽然在JDK 8里是协作式的、不阻塞读，但多线程协助扩容毕竟也会占用CPU，高QPS下扩容带来的开销不能忽视。如果设置得过大，内存浪费在空桶的Node数组上也不划算。

这里还有一个技巧：如果你能提前知道Map的最大容量，可以把initialCapacity设置为 预估容量 / 0.75 + 1，保证不触发扩容。因为默认达到容量的75%就会触发，留出余量是必须的。我在实际项目中压过一个500万条数据的配置缓存，按这个公式设置容量后，系统运行一整天的扩容次数从几十次降到了个位数，明显看到GC压力下降。

6.4 我在压测里发现的一个性能细节

最后分享一个我在生产环境压测时发现的细节。JDK 8的ConcurrentHashMap虽然在读路径上无锁，但它的read操作会读取volatile变量。volatile的读在x86平台上开销很小（基本和普通读差不多），但在ARM等弱内存模型平台上开销会明显高一些。如果你在安卓端或ARM服务器上使用ConcurrentHashMap做高频读取，性能表现会不如x86。这个差异平时感知不到，但当你做百万QPS级别的压测时就能看出差距。

所以如果你的部署环境是ARM架构，且读写比例极高、数据量又小，可以考虑用普通的HashMap配合读写锁，或者干脆用CopyOnWriteMap这类读完全无锁的实现——只要你能接受写复制整个Map的开销。说到底，没有银弹容器，只有适配场景的取舍。

回到ComcurrentHashMap的设计哲学，我还想补一句个人体会：它最值得学习的不是那些锁技巧和源码细节，而是那种"为读让步、按概率取舍、用协作代替阻塞"的系统性思维。理解了这套取舍逻辑，你去看任何并发框架的源码，都会觉得豁然开朗。平时写业务代码不妨多想想"如果让我来设计，我会把锁放在哪个粒度"，比背多少面试题都管用。