使用AtomicInteger是实现线程安全计数器最常用且高效的方法，它基于CAS原子操作，避免锁开销，适用于多数并发场景。
在Java里要弄个线程安全的计数器，其实有几种搞法，最常见的也最省心的，多半就是用
AtomicInteger
了。它能保证你在多线程环境下，计数器的值不会乱套，每次加减都能稳稳当当的。这背后利用的是CPU底层的原子操作，效率高，而且写起来也挺简洁的。
直接说解决方案吧，用
AtomicInteger
是最直接的。你看，这玩意儿就是专门干这个的，利用了CPU底层的CAS（Compare-And-Swap）操作，基本是无锁的，效率还挺高。
import java.util.concurrent.atomic.AtomicInteger;public class ThreadSafeCounter { private AtomicInteger counter = new AtomicInteger(0); // 初始化为0 /** * 安全地增加计数器 */ public void increment() { counter.incrementAndGet(); // 原子性地增加并获取新值 } /** * 安全地减少计数器 */ public void decrement() { counter.decrementAndGet(); // 原子性地减少并获取新值 } /** * 获取当前计数器的值 * @return 当前计数值 */ public int getCount() { return counter.get(); } public static void main(String[] args) throws InterruptedException { ThreadSafeCounter tsc = new ThreadSafeCounter(); int numberOfThreads = 10; int incrementsPerThread = 1000; Thread[] threads = new Thread[numberOfThreads]; for (int i = 0; i { for (int j = 0; j < incrementsPerThread; j++) { tsc.increment(); } }); threads[i].start(); } for (Thread thread : threads) { thread.join(); // 等待所有线程执行完毕 } System.out.println("所有线程完成后的最终计数: " + tsc.getCount()); // 预期是 numberOfThreads * incrementsPerThread }}
当然，你也可以用
synchronized
关键字来实现，比如在
increment
和
getCount
方法上加
synchronized
修饰符。但通常来说，对于简单的计数器，
AtomicInteger
更优雅，性能也更好，因为它避免了锁的开销。
为什么Java计数器需要线程安全？
你看，这问题其实挺基础的，但又特别容易被忽略。想象一下，如果你的计数器不是线程安全的，那多个线程同时去‘加1’的时候，就可能出问题了。比如说，线程A读到当前值是5，正准备加1写回6；结果线程B也读到5，它也加1写回6。这下好了，两个线程都加了1，但最终结果却只增加了1，而不是2。这就是典型的‘丢失更新’，数据就这么悄无声息地出错了。这种现象我们管它叫竞态条件（Race Condition），非常麻烦，因为这种错误往往不是每次都发生，而是偶尔出现，调试起来能把人逼疯。尤其在那些对数据一致性要求高的业务场景，比如订单数量、库存统计、访问量统计等等，一旦出现这种问题，轻则数据失真，重则业务逻辑混乱，造成难以估量的损失。所以，理解并解决线程安全问题，是构建健壮并发应用的第一步。
立即学习“Java免费学习笔记（深入）”；
除了AtomicInteger，还有哪些实现线程安全计数器的方法？
当然了，
AtomicInteger
虽然好用，但它也不是唯一的选择，Java提供了一套完整的并发工具箱。
synchronized
关键字： 这是最老牌、最直接的办法。你可以直接在方法签名上加
synchronized
，或者用
synchronized (this)
或
synchronized (某个对象)
来包裹代码块。它的好处是简单粗暴，上手快。但缺点也很明显，它是一种悲观锁，只要有一个线程进去了，其他想进来的线程就得排队等着，哪怕它们只是想读一下计数器的值。在高并发场景下，这可能会成为性能瓶颈，因为它会导致大量的线程上下文切换和阻塞。
ReentrantLock
： 这是
java.util.concurrent.locks
包下的一个类，提供了比
synchronized
更细粒度的控制。你可以手动地
lock()
和
unlock()
，甚至尝试非阻塞地获取锁（
tryLock()
），或者设置公平锁。它的灵活性更高，可以实现更复杂的同步策略，比如读写锁
ReentrantReadWriteLock
。但相应的，代码量也会增加，而且你得确保在
finally
块里把锁释放掉，否则就可能死锁。对于计数器这种简单的操作，可能有点‘杀鸡用牛刀’，但如果你需要更复杂的逻辑，比如在计数器更新前后执行其他操作，并且这些操作也需要锁保护，那
ReentrantLock
就能派上用场了。
LongAdder
/
DoubleAdder
： 这俩是
AtomicInteger
和
AtomicLong
的增强版，特别为高并发、低竞争的场景优化。它们的核心思想是把一个变量分解成多个变量，每个线程在自己的‘小格子’里累加，最后再把这些‘小格子’里的值汇总起来。这样就大大减少了单个变量上的竞争，因为不同线程可能操作不同的内部变量。如果你有一个计数器，只做增量操作，并且并发量特别大，比如每秒几十万次甚至上百万次的计数，那
LongAdder
绝对是你的首选，性能表现会非常惊艳，它在高并发下的吞吐量远超
AtomicInteger
。
如何根据实际场景选择最合适的线程安全计数器方案？
选择哪种方案，说到底还是得看你的具体需求和应用场景，没有银弹。
如果你只是需要一个简单的、并发量不是特别高的计数器，或者你的业务逻辑本身就带有锁，那
synchronized
可能就够用了。 它代码简洁，可读性好，而且现代JVM对
synchronized
也做了很多优化，小并发场景下性能不一定差。它的优势在于易用性，不需要引入额外的类。
对于大多数通用场景，特别是需要高效率的原子操作，
AtomicInteger
几乎是默认的选择。 它的性能通常比
synchronized
好，因为它避免了操作系统级别的线程上下文切换，直接在用户空间通过CAS指令完成操作。而且代码也比较简洁，不需要手动管理锁。它适用于并发量中等偏高，且只需要对单个变量进行原子操作的场景。
如果你的计数器操作非常频繁，而且并发度极高，比如每秒几十万甚至上百万次的增量操作，并且你只关心最终的累加结果，不关心中间的瞬时值，那么
LongAdder
会是最佳选择。 它的设计就是为了应对这种极端情况，通过分散热点来减少竞争，从而提供更高的吞吐量。它牺牲了一点点获取当前准确值的效率（需要汇总所有内部变量），来换取极高的写入性能。
而
ReentrantLock
呢，它更适用于那些需要更复杂同步逻辑的场景，比如需要条件变量（
Condition
）来协调线程，或者需要尝试获取锁、限时获取锁等高级功能。 对于单纯的计数器，它的优势并不明显，反而会增加代码的复杂性，因为你需要手动地管理锁的获取和释放，这增加了出错的可能性。
总的来说，我的建议是：优先考虑
AtomicInteger
，它能满足绝大多数需求，是性能和简易性的一个良好平衡点。如果并发量实在太高，
LongAdder
是更好的选择。
synchronized
作为兜底方案，在简单场景下也能用。
ReentrantLock
则留给那些更复杂的同步问题。 实际开发中，性能测试往往是验证选择是否正确的最后一步，理论分析结合实践才是王道，有时候一个微小的改动就能带来巨大的性能提升。
以上就是如何在Java中实现线程安全的计数器的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/71002.html
微信扫一扫 
支付宝扫一扫 
