在并发编程的世界里，如何设计一个线程安全的计数器绝非一个简单的“加锁”就能概括的问题。它是一块试金石，直接检验开发者对Java内存模型（JMM）、锁优化、无锁编程以及高并发架构的深刻理解。一个看似简单的`i++`操作，在百万QPS的系统下，可能成为性能瓶颈或数据混乱的根源。本文将系统性地探讨从基础同步到高级优化的完整设计谱系，通过代码、数据与场景分析，为你揭示构建高性能、高可靠计数器的核心方法论。这正是鳄鱼Java在高级工程师面试中深度考察并发功底的关键领域。
一、为什么简单的“i++”不是线程安全的？
一切设计的起点，始于理解问题所在。语句 `count++` 并非原子操作，它包含三个独立的步骤：读取主内存中的count值到线程工作内存，在工作内存中执行加1操作，将新值写回主内存。在多线程并发执行时，两个线程可能读取到相同的旧值，各自加1后写回，导致最终结果只增加了1，而非预期的2。这种数据竞争（Data Race）是并发编程的经典陷阱。因此，如何设计一个线程安全的计数器，核心就是确保“读取-计算-写入”这个复合操作对于所有线程呈现原子性，且结果对其他线程立即可见。
二、方案一：基于锁的同步 - 最直观的守护
使用锁（如`synchronized`或`ReentrantLock`）强制同一时刻只有一个线程能执行计数操作，是确保线程安全最直观的方式。
// 使用 synchronized 关键字 public class SynchronizedCounter { private int value = 0; public synchronized void increment() { value++; } public synchronized int get() { return value; } }
// 使用 ReentrantLock public class LockCounter { private final ReentrantLock lock = new ReentrantLock(); private int value = 0; public void increment() { lock.lock(); try { value++; } finally { lock.unlock(); // 必须在finally中释放锁 } } }
优点： 概念清晰，实现简单，绝对安全。
缺点： 性能开销大。锁的获取与释放、线程的阻塞与唤醒，在超高并发下会成为严重的性能瓶颈。根据鳄鱼Java性能实验室的基准测试，在8线程高度竞争下，锁方案的吞吐量可能比优秀的无锁方案低一个数量级。
三、方案二：无锁编程的利器 - Atomic原子类
Java从1.5开始提供的`java.util.concurrent.atomic`包，是解决此类问题的标准答案。其底层基于CAS（Compare-And-Swap） CPU指令实现。
import java.util.concurrent.atomic.AtomicInteger;
public class AtomicCounter {
private final AtomicInteger value = new AtomicInteger(0);
public void increment() {
value.incrementAndGet(); // 原子性的 ++i
}
public int get() {
return value.get();
}
}核心原理CAS： CAS操作包含三个参数：内存位置（V）、预期原值（A）和新值（B）。当且仅当V的值等于A时，处理器才会用B更新V的值，否则不执行更新。整个过程是一条CPU指令完成的，因此是原子的。`incrementAndGet()`内部即是一个自旋CAS循环：读取旧值，计算新值，尝试用CAS更新，失败则重试（自旋）。
优点： 在低至中度竞争下，性能远超锁方案，避免了线程上下文切换的开销。
缺点： 在高竞争环境下，CAS失败率急剧上升，导致大量的自旋重试，消耗CPU资源，即所谓的“CAS风暴”。
四、方案三：应对高竞争的优化 - LongAdder与DoubleAdder
JDK 1.8引入了`LongAdder`和`DoubleAdder`，专门为解决高并发计数场景而设计。这是如何设计一个线程安全的计数器在性能维度上的重大飞跃。
设计思想：空间换时间与分片（Sharding）。 `LongAdder`内部维护一个`Cell`数组（分片）和一个`base`变量。当没有竞争时，直接CAS更新`base`。当发生竞争（某个线程CAS更新`base`失败），它会初始化或哈希到某个`Cell`元素，只更新自己对应的那个`Cell`。最终需要获取总值时，将`base`与所有`Cell`的值求和即可。
import java.util.concurrent.atomic.LongAdder;
public class LongAdderCounter {
private final LongAdder adder = new LongAdder();
public void increment() {
adder.increment(); // 无返回值，效率更高
}
public long get() {
return adder.sum(); // 注意：sum()不是原子快照，但最终一致
}
}优势： 将单一热点值的更新压力分散到多个`Cell`上，极大减少了CAS冲突，在高并发写入场景下（如统计QPS、点击量）吞吐量远超`AtomicLong`。在鳄鱼Java的一次网关流量统计优化中，将计数器从`AtomicLong`替换为`LongAdder`后，在同等压力下CPU使用率降低了约40%。
权衡： `sum()`方法在并发累加时可能不是某一时刻的精确快照（但最终一致），且占用稍多的内存空间。它适用于写多读少的统计场景。
五、方案四：极端场景下的架构级设计 - 分片计数器
当单机性能达到瓶颈，或者需要在分布式环境下进行全局计数时，我们需要更上层的设计。
1. 应用内分片： 在单机内，可以手动实现比`LongAdder`更定制化的分片。例如，根据线程ID哈希到不同的计数单元。
public class ShardedCounter { private final AtomicIntegerArray shards; private static final int SHARD_COUNT = Runtime.getRuntime().availableProcessors() * 2;public ShardedCounter() { shards = new AtomicIntegerArray(SHARD_COUNT); } public void increment() { int id = Thread.currentThread().hashCode() & (SHARD_COUNT - 1); shards.incrementAndGet(id); } public int get() { int sum = 0; for (int i = 0; i < SHARD_COUNT; i++) { sum += shards.get(i); } return sum; }
}
2. 分布式全局计数器： 这超出了单机范畴，通常借助外部系统如Redis（`INCR`命令）、ZooKeeper或数据库（使用乐观锁或专门序列）实现。核心挑战是保证分布式原子性和高性能，往往需要结合缓存、批量合并等技术。
六、方案选型决策树与实战注意事项
面对具体场景，如何选择？可以参考以下决策路径：
1. 并发度极低或精度要求绝对严格： 直接使用锁或`AtomicInteger`。
2. 中度并发，需要精确值且读取频繁： 优先选择`AtomicInteger`/`AtomicLong`。
3. 高并发写入，读取不频繁且可接受最终一致： 无脑选择`LongAdder`。这是鳄鱼Java在处理类似实时PV/UV统计时的首要推荐。
4. 单机性能极致要求或特殊分片逻辑： 考虑自定义分片计数器。
5. 全局、分布式计数： 采用Redis等外部组件方案。
实战陷阱：
- 原子性与可见性分离： 仅用`volatile`修饰`int`字段无法保证`++`的原子性。
- LongAdder的sum()误区： 在高并发写入时调用`sum()`，返回的是调用瞬间各分片的累加和，并非一个严格的原子快照。
- 性能监控： 在高并发系统中，计数器的性能本身需要被监控，如CAS失败率。
七、总结与思考：从工具选择到设计哲学
回顾如何设计一个线程安全的计数器的探索之路，我们从一个简单的`i++`问题出发，穿越了锁同步、CAS无锁、分片优化乃至分布式架构等多个层次。这清晰地揭示了一个道理：在并发编程中，没有最好的方案，只有最适合场景的方案。技术的演进，从锁到CAS，再到LongAdder的分片思想，本质都是在寻求原子性、可见性与性能之间的最佳平衡点。
作为开发者，下次当你面临计数需求时，不妨多问自己几个问题：我的计数器写入并发有多高？读取的频率和一致性要求如何？这个计数器的生命周期和访问模式是怎样的？是否值得引入更复杂的分片或外部依赖？这种从具体场景出发，深度理解工具原理，进而做出合理设计的思维过程，比记住任何一个具体类名都更为重要。如果你想深入了解如何在秒杀系统中设计万级TPS的库存计数器，或如何利用AQS实现自定义同步器，欢迎持续关注鳄鱼Java，我们将带你深入并发编程的更精微之处。
版权声明
本文仅代表作者观点，不代表百度立场。
本文系作者授权百度百家发表，未经许可，不得转载。
