ConcurrentHashMap线程安全与性能演进：从分段锁到CAS+synchronized

1. 从电商库存扣减看并发容器的必要性

想象一下双十一零点秒杀的场景：十万用户同时点击"立即购买"，系统需要在毫秒级完成库存校验和扣减。如果用普通的HashMap来存储库存数据，很可能会出现超卖——也就是库存减到负数的情况。这背后的根本原因在于HashMap的线程不安全特性。

我在早期参与电商系统开发时，就遇到过这样的坑。当时为了快速上线，直接用HashMap存储商品库存。测试环境一切正常，但大促时出现了几十笔超卖订单。排查发现，当多个线程同时执行"查询当前库存-1-更新结果"这个操作序列时，由于没有同步机制，两个线程可能同时读到库存为1，各自减1后都认为库存应该为0，但实际结果却是-1。

HashTable虽然通过synchronized关键字实现了线程安全，但在我们的压测中发现，当并发量达到5000TPS时，系统吞吐量下降了60%。这是因为HashTable的锁粒度太大——整个表共用一把锁，不同线程哪怕操作的是完全不相干的键值对，也需要排队等待。

java复制// 典型的问题代码示例
public class UnsafeInventory {
    private Map<String, Integer> stock = new HashMap<>();
    
    public boolean deduct(String itemId) {
        if(stock.get(itemId) > 0) {
            stock.put(itemId, stock.get(itemId) - 1);
            return true;
        }
        return false;
    }
}

这个案例让我深刻理解了ConcurrentHashMap的设计价值：它要在保证线程安全的前提下，尽可能减少锁带来的性能损耗。就像超市结账，HashTable相当于整个超市只开一个收银台，而ConcurrentHashMap则是根据商品类别开放多个专用通道，买食品的和买家电的顾客可以并行结账。

2. JDK1.7的分段锁设计解析

2.1 分段锁的物理结构

JDK1.7的ConcurrentHashMap采用了精妙的分段锁设计。我更喜欢把它比喻成一个大型图书馆的管理