1. 从一次线上卡顿说起为什么Android开发绕不开ConcurrentHashMap先聊个真实经历。之前我负责的一个App首页Feed流做了一次“推荐内容排序权重实时调整”的改动。需求很简单后台推送用户行为数据App接收到之后往一个全局Map里累加权重值UI线程不定时读取并按权重重排列表。当时团队里有同事图省事直接用HashMap再在读写的地方包了一层synchronized。上线第一天就出问题主线程频繁和网络回调线程抢锁掉帧、ANR弹窗冒出来了。后来替换成ConcurrentHashMap问题直接消失。从那时候开始我对“Android并发容器选型”这件事有了很深的执念。作为Android开发者日常接触最多的容器无非HashMap、ArrayList这些单线程场景下的“老朋友”但一旦涉及跨线程共享数据——比如缓存池、全局配置、消息聚合、埋点缓冲——ConcurrentHashMap几乎是无可替代的标准答案。很多初级开发知道这个类名也知道它是“线程安全的HashMap”但问深一点它为什么安全JDK 7和JDK 8的实现有什么本质区别什么情况下它其实不保证正确性能答出来的就不多了。这篇文章就是把这些事掰开揉碎讲清楚。我会结合自己这些年做Android业务开发的实际使用场景把原理、实现、选型、深坑一条龙过一遍无论你是刚入行的新人还是已经开始带项目的同学都能在里面找到有价值的东西。至少下次面试官问你“HashMap和ConcurrentHashMap区别”的时候你能从数据结构讲到锁粒度再从锁粒度讲回Android的主线程卡顿治理而不是硬背两句话。2. 为什么是ConcurrentHashMap并发容器选型的底层逻辑2.1 HashMap不是不能用是并发场景下“不体面”先说HashMap。它内部是一个Node数组加链表JDK 8之后引入红黑树所有操作都没有任何锁保护。单线程下它的效率确实高因为不需要为“原子性”付出任何代价。但一旦多线程同时读写最典型的问题有两个第一数据覆盖。假设两个线程同时往HashMap里put恰好命中同一个桶先后的写入顺序完全取决于线程调度后面写入的键值会把前面的覆盖掉。而且HashMap在插入过程中会触发扩容扩容是“重新分配数组搬运旧节点”的过程两个线程同时触发resize会把其中一个线程搬好的引用直接重置丢了数据。第二链表成环。这个问题在JDK 7及之前的版本特别严重。头插法在并发扩容时可能导致某个桶的链表形成环形引用下次get的时候发生死循环CPU直接100%。JDK 8改成尾插法之后死循环问题从“大概率”变成“极低概率”但数据覆盖和丢失依然存在因为它根本就不是为并发设计的。所以很多人说“Java体系里有Hashtable干嘛不用Hashtable”Hashtable确实所有方法都加了synchronized但它是一个全局锁两个线程哪怕操作两个完全不相干的key也要排队抢同一把锁并发效率极其低下。在早期的Hashtable源码里你甚至能看到方法直接锁住整个对象这在只有一个核的当年可能无所谓放到今天的八核手机上这种设计完全就是性能杀手。2.2 同步包装器也好但粒度决定了天花板Collections.synchronizedMap(new HashMap())是很多教科书推荐的线程安全方案所有方法通通加synchronized用法简单粗暴。但它的性能和Hashtable是一个水平——锁粒度是整个Map对象。说得更直白一点一个App里如果有独立业务模块共享一个全局MapA模块往里面放数据B模块读数据虽然它们的key完全不会重叠但依然会被同一把锁卡住。在高并发读写场景下这种全局串行化方案注定是瓶颈。ConcurrentHashMap之所以是“正解”就是因为它把“一把大锁”拆成了“多把小锁”或者更进一步用无锁CAS的方式处理大部分操作。锁的粒度越小线程之间的竞争就越少吞吐量自然就上来了。这个思路不仅适用于Java后端在Android这种对主线程卡顿极其敏感的平台上尤其重要——我们把并发控制做得越精细其他线程对主线程的干扰就越小。2.3 Android平台的特殊性你不是在写纯Java很多人写Android的时候会把后端那套并发思维直接搬过来但Android和标准Java有一个非常大的区别内存和CPU资源都紧主线程还承担着全部UI渲染和事件分发。你不可能像后端那样为了追求极致吞吐量把并发容器配置得很激进——Android上CPU多核有限线程切换成本高一旦有线程频繁阻塞很容易把小型机的卡顿问题放大到日常使用体验中。所以ConcurrentHashMap在Android上的定位从来不是“高性能并发利器”那么简单而是“线程安全 尽量少的锁竞争 足够简单的使用方式”三者之间的平衡点。用好了它不会让你感觉复杂用歪了它又容易让你误以为一切安全了。这就是为什么值得把它的内部机制搞透。3. 知道怎么用很简单难的是知道它为什么这样实现3.1 JDK 7分段锁的设计思路JDK 7时代的ConcurrentHashMap内部结构是一个“Segment数组 HashEntry数组”的两层结构。Segment本身就是一把“可重入锁”继承ReentrantLock每个Segment锁着一部分桶。做put操作的时候先通过key的哈希找到对应Segment然后只锁这一个Segment其他Segment区域的读写完全不受影响。默认有16个Segment也就是说理论上并发度能达到16这是对比Hashtable的一个巨大飞跃。这种设计用生活类比来说就像一个大商场里分成16个独立的仓库每个仓库有自己的管理员你想进某个仓库搬货只需要找对应管理员拿钥匙其他仓库完全不用等。不过JDK 7的实现也有短板get操作虽然在大多数情况下不需要加锁因为HashEntry里的value和next是volatile的但整个结构相对复杂而且size()这种需要统计全局数据的操作要逐个Segment加锁求和这在Map很大的时候性能不够稳定。还有一个致命伤当某个Segment内的哈希冲突严重时链表查找退化成线性扫描没有引入红黑树来兜底。这也是JDK 8推翻重做的主要原因之一。3.2 JDK 8CAS synchronized 红黑树JDK 8之后ConcurrentHashMap丢弃了Segment数组回归到和HashMap类似的“Node数组 链表/红黑树”结构。锁的粒度从“Segment”细化到“单个桶的头节点”。具体流程是这样的put过程根据key哈希找到桶下标。如果桶为空用CAS直接写入新Node这一步无锁。如果有Node占用了对头节点加synchronized锁然后遍历链表/红黑树执行插入或更新。如果链表长度超过8且数组容量≥64把链表树化。这个设计的精妙之处在于大多数情况下桶为空并发put甚至不需要加锁CAS直接搞定只有真正的哈希冲突桶已经有人占用才会锁住这个桶的头节点。而由于哈希值随机分布并发线程同时命中同一个桶的概率本身就低所以绝大多数put操作都是无锁完成的。扩容过程也是JDK 8重点优化的方向引入了多线程协助扩容机制ForwardingNode标志位 从尾部到头部的遍历策略。大致意思扩容不再是单线程把整个数据搬完而是多个线程发现需要扩容后可以一起来搬谁搬完一个桶就把那个桶的标志位设好其他线程读数据时看到ForwardingNode就去新的数组里找保证读操作不被阻塞。get过程全程无锁因为Node的value域是volatile的读线程可以拿到最新写入的值。这里有个细节即使当前有其他线程正在某个桶上做更新操作读线程也不受影响因为它读的是“已经发布的Node引用”。这种设计意味着什么意味着JDK 8的ConcurrentHashMap在绝大多数场景下性能已经无限接近HashMap的非线程安全版本。这也解释了为什么你在Android上可以放心大胆地用它做高频读取的本地缓存容器而不需要像以前那样担心锁开销。3.3 为什么它不是“真”线程安全的比你想象中更重要的边界先把结论放在这ConcurrentHashMap只保证单个方法、单个操作的线程安全不保证复合操作的原子性。一个最经典的例子if (!map.containsKey(key)) { map.put(key, value); }这段代码看起来“很安全”因为containsKey和put都是线程安全的。但把两步拼在一起就成了一个“先查后写”的复合操作。线程A刚执行完containsKey发现key不存在线程B抢先把它put进去了线程A再执行put就会把B的值覆盖。这不是bug这是所有“线程安全”容器都会遇到的问题——你需要的其实是“computeIfAbsent”这种原子性的复合方法。再看一个例子多个线程同时对同一个key执行map.put每次put都会覆盖前一个值。如果你想实现“累加器”还想当然地用ConcurrentHashMap做加法那就会丢失一部分更新因为value map.get(key); map.put(key, value 1);是两个独立的操作中间可能有其他线程插进来。正确的姿势是用merge方法或者compute方法把这些逻辑包在容器内部的原子操作中。这些边界问题如果不搞清楚你在Android项目里就会踩到一个很隐蔽的坑线上看起来“偶尔丢数据”但查不到明显异常日志。因为问题根本不在并发容器本身而在你的调用模式没有用到它的原子能力。4. Android项目实战这几个场景我最常用它4.1 场景一全局缓存池做Android的人应该都有过类似的经历首页接口返回的数据、频繁用到的一些图片URL映射、用户设置开关等往往需要全局共享而且读多写少。我常用的做法是在一个单例里持有一个ConcurrentHashMap作为缓存池。object ConfigCache { private val cache ConcurrentHashMapString, Any() Volatile private var initialized false fun put(key: String, value: Any) { cache[key] value } fun get(key: String): Any? cache[key] fun remove(key: String) { cache.remove(key) } fun clear() { cache.clear() } }这里值得说几个实践细节第一keyset的遍历要小心。如果业务里需要“把所有缓存数据统一更新一遍”直接for (key in cache.keys)遍历此时如果有其他线程修改了数据会抛ConcurrentModificationException吗不会。ConcurrentHashMap的迭代器是弱一致性的它允许在遍历过程中修改但不保证能遍历到最新的元素。很多业务场景比如定时全量刷新缓存其实能承受这种弱一致性但如果你要求“遍历到的一定是最新快照”那就得自己额外做快照复制。第二不要用它存大量永远不会淘汰的数据。Android端内存是稀缺资源ConcurrentHashMap默认情况下不提供LRU淘汰能力。如果做缓存一定要配合总量控制或者直接引入LruCache做二级缓存。我在实际项目中通常是“ConcurrentHashMap负责跨线程安全存取LruCache负责容量淘汰”两者配合用。4.2 场景二异步任务去重控制App里经常遇到一种需求同一个页面短时间内被点击多次希望只发起一次网络请求。很多人会用AtomicBoolean做“是否正在请求”的标记但如果这个页面的请求入口有很多个下拉刷新、自动刷新、手动刷新、跳转二次请求一个boolean就不够用了——需要按请求标识维度做去重。class RequestDebouncer { private val inflightKeys ConcurrentHashMap.newKeySetString() fun tryAcquire(key: String): Boolean { return inflightKeys.add(key) } fun release(key: String) { inflightKeys.remove(key) } }你用newKeySet()拿到的Set底层就是ConcurrentHashMap天然线程安全。而且add操作本身就是原子性的多个线程同时“抢占同一个请求key”只有一个能成功。这种方式比我最早用“Map锁”的方案代码量少了不止一半可读性也更好。4.3 场景三本地埋点缓冲App端收集用户行为数据的时候往往是子线程往缓冲区写数据主线程定时或者App切换到后台时把缓冲区里的数据批量上报。埋点这块如果处理不好SubThread写、MainThread读就会产生大量“脏读”和“重复上报”。我用的方案是ConcurrentHashMap按业务类型分桶存埋点List写线程直接put/merge上报线程读取后remove清空。这里注意一点如果value本身是ArrayList那么两个线程同时对同一个key执行get再往List里add还是会有并发问题。ConcurrentHashMap只保证Map的读写安全不保证你塞进去的集合的线程安全。更稳妥的做法是value也用线程安全的容器或者干脆不用“Map包List”而是用ConcurrentHashMap.newKeySet()直接存单条埋点上报时一次性把整个set拿走再重建一个新的set。关闭“写入锁”换来的是简单和可靠。这个思路我觉得对Android这种内存紧张的平台特别重要——用内存换锁竞争值。4.4 实战中一个很重要的原则并发容器不是万能药聊点个人体会。我见过不少团队一遇到并发问题不管三七二十一把HashMap换成ConcurrentHashMap然后宣布“解决了”。但这种做法有一个隐性代价你放弃了语义上的明确性。举个例子如果你的业务要求是“在UI线程读取数据时绝对不被其他线程修改”——那么你用ConcurrentHashMap也只是把“读快照”变成“弱一致快照”UI可能拿到的是旧数据这比拿不到数据更坑。这种场景下你真正需要的不是并发容器的无锁读而是不可变对象Immutable Object CopyOnWrite策略或者干脆在合适的时机用replaceAll在锁内完成快照切换。所以在Android项目里我给团队定的规范很简单并发容器只用在“写者多、读者多、但单个value不要求强一致”的场景。复合逻辑必须用容器自带的原子方法compute、merge、computeIfAbsent。如果value是同一个对象的集合型字段必须自己保证内部线程安全。5. 那些官方文档不会写出来的逃坑指南5.1 key和value都不能为null这一条最容易踩雷ConcurrentHashMap的key和value都禁止为null。这不是选择问题是设计上的必然因为它用CAS和无锁读没办法区分“value为null”和“value不存在”这两种状态。如果你put了一个null值那么get返回null的时候你无法判断是“map里没有这个key的映射”还是“这个key对应的值就是null”。HashMap可以容忍这种含糊但并发的场景下不行。这个限制在实际开发里带来的麻烦很小但它有一个连锁反应很多新手把网络返回的数据直接put进ConcurrentHashMap如果服务端返回了null字段这里会直接抛NullPointerException。我的习惯是所有写入ConcurrentHashMap的数据都先做非空判断或者用computeIfAbsent的lambda里做兜底转换优雅地把null转换成默认值或空对象。5.2 size()和mappingCount()你用哪一个ConcurrentHashMap的size()方法在JDK 8的实现里并不是每次都精确统计而是先估算如果估算过程中发现数据变化频繁会退化成“加锁遍历计数”。所以官方其实更推荐用mappingCount()返回long类型因为size()返回int容器大了可能溢出。在Android上这个问题的现实意义是什么如果你用map.size()做一个“数据攒够N条才上报”的判断那么size()的估算误差可能会导致你提前或延后上报。虽然这种情况不致命但你要知道它确实存在。我的经验是判断空还是非空用isEmpty()判断累计数量用mappingCount()真要精确统计自己维护一个AtomicLong计数器。5.3 高并发下扩容“抄近道”initialCapacity和concurrencyLevelJDK 8之后的ConcurrentHashMap在构造时不需要再指定concurrencyLevel因为并发度已经和桶数量挂钩了。但有一个参数还是值得注意initialCapacity。如果你预估Map会装几万个元素但让它在默认的16个桶上开始那么中间会触发多次扩容每次扩容都要搬运节点在Android上就是CPU突刺。更好的做法是在构造时就给一个相对宽裕的容量。通常我会用new ConcurrentHashMap(预估最大元素数 / 0.75 1)这个公式来设置初始容量模拟HashMap的负载因子思想。不过强调一点Android上不要为了“性能”盲目把初始容量调得很大因为Map底层数组是常驻内存的你给它分配了100万个桶的数组空间哪怕只放10个元素这100万个引用约4M也占着实实在在的堆内存。在App这种内存敏感的平台上这个参数要酌情考量。5.4 弱一致性迭代器的双面性迭代器弱一致是一个很多人不了解的特性。简单说你用map.iterator()遍历的时候它会基于“遍历开始那一刻”的链表/红黑树快照往前走但如果遍历到一半有其他线程修改了Map迭代器不会抛ConcurrentModificationException而是继续走旧快照或者在某些实现下可能看到部分新数据。这个特性对Android的意义在于好的方面UI线程在遍历Map做列表渲染时后台线程持续更新数据UI不会crash。这在“实时刷新列表”场景下非常重要。坏的方面如果你在遍历的同时其他线程删除了一个你已经遍历过的key那么删除操作不生效元素仍然会出现在遍历结果中。如果你在做一个“给用户展示在线状态”的功能Map里存的是userId - 在线状态后台线程不断更新UI每秒钟遍历一次刷新列表。此时如果某个用户下线了后台线程执行remove但UI线程的遍历已经走过了那个用户的桶位置那么这一次刷新还是会展示“在线”状态——直到下一次遍历。这种“延迟一个周期才生效”的问题在生产环境很难发现但它就是弱一致性的边界。5.5 锁膨胀的代价别高频执行并发扩容JDK 8对单个桶头节点加锁的设计虽然粒度很细但有一个潜在问题如果大量线程恰好都命中同一个桶比如用同一个对象的hashCode拼出来的key那么它们会串行执行锁竞争上升。这种情况在Android上通常出现在“自定义类重写过hashCode但实现极烂”的情况下。排查方式很简单看到主线程频繁等待、CPU使用率高但业务逻辑代码没明显死循环时优先检查参与并发操作的key对象是否有一个“分布不佳”的hashCode。如果确实遇到了最简单的处理是给key包一层String.valueOf(key.hashCode())这类字符串让哈希值分布更均匀。这不是一个通用的方法但实测下来确实能缓解局部锁竞争。6. 面试视角ConcurrentHashMap在Android岗的典型提问与回答思路6.1 “ConcurrentHashMap和Hashtable有什么区别”这是一个高频的八股题但多数人的回答总是停留在“Hashtable加锁、ConcurrentHashMap也加锁”这种层面上。我的建议是分三条线回答第一锁粒度不同。Hashtable锁整个对象任何操作都全局串行ConcurrentHashMap JDK 7按Segment分段锁JDK 8按桶锁头节点空桶直接CAS无锁写入。第二数据结构不同。Hashtable内部是简单的数组加链表ConcurrentHashMap JDK 8在链表长度超过8时树化成红黑树能显著降低最坏情况下的查找耗时。第三迭代和统计的语义不同。Hashtable迭代时修改会抛ConcurrentModificationExceptionConcurrentHashMap的迭代器是弱一致的。6.2 “它的get方法需要加锁吗”这个问题的标准答案按JDK版本区分JDK 7的get在绝大多数情况下不加锁但遇到扩容相关的特殊情况会有处理JDK 8的get完全无锁因为Node的value和next是volatile的读取走volatile语义天然拿到了“最新发布”的引用。另外聊到size()的时候也要明确“size()不保证实时精确”JDK 7的size是锁所有Segment统计的JDK 8的size是估算优先。6.3 “在Android上你会怎么用它管理图片缓存”这是我会主动追问候选人的一个问题因为它能把“背八股”和“真做过”区分开。一个合格的回答应该覆盖这几个点先说存储维度可以用ConcurrentHashMapString, Bitmap存弱引用的Bitmap对象配合WeakReference但强调Bitmap在Android上放在Map里容易被GC回收通常会和LruCache配合。再说生命周期Activity或Fragment销毁时要清理对应的缓存条目避免内存泄漏——Map本身不管理生命周期是使用者的责任。最后说并发读写加载图片的线程池和UI主线程之间通过Map协作UI从Map里读无锁加载线程写CAS/局部锁不会卡主线程。能答到这个深度基本可以判断这个人确实在项目里用过它而不是只看了几篇博客。7. 一个可以立刻用起来的小技巧收个尾最后分享一个我在Android项目里私藏的小工具类。很多业务场景需要“按用户纬度缓存一份数据过期自动清理”用ConcurrentHashMap配合时间戳就能实现一个轻量级的TTL缓存class TtlMapK, V( private val ttlMillis: Long ) { private val map ConcurrentHashMapK, PairLong, V() fun put(key: K, value: V) { map[key] System.currentTimeMillis() to value } fun get(key: K): V? { val entry map[key] ?: return null if (System.currentTimeMillis() - entry.first ttlMillis) { map.remove(key, entry) return null } return entry.second } fun remove(key: K) { map.remove(key) } }用的时候注意一个点map.remove(key, entry)是“比较后再删除”的原子操作保证不会误删掉其他线程刚刚更新过的新值。这个工具类我在多个项目里复用简单、不依赖第三方库、并发安全30行代码不到却能省掉很多“缓存什么时候过期”的瞎操心。我从毕业到现在写过很多HashMap也被并发问题坑过很多次最后意识到容器本身永远只是工具真正值钱的是使用者对并发模型的理解。ConcurrentHashMap把它应该承担的那部分安全责任做到了极致剩下的复合逻辑、业务边界、生命周期管理终究需要我们自己想清楚。希望这篇内容能帮你少走一点弯路。