Java线程安全计数器实现方式

编程并不是一个机械性的工作，而是需要有思考，有创新的工作，语法是固定的，但解决问题的思路则是依靠人的思维，这就需要我们坚持学习和更新自己的知识。今天golang学习网就整理分享《Java线程安全计数器实现方法》，文章讲解的知识点主要包括，如果你对文章方面的知识点感兴趣，就不要错过golang学习网，在这可以对大家的知识积累有所帮助，助力开发能力的提升。

使用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 < numberOfThreads; i++) {
            threads[i] = new Thread(() -> {
                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），非常麻烦，因为这种错误往往不是每次都发生，而是偶尔出现，调试起来能把人逼疯。尤其在那些对数据一致性要求高的业务场景，比如订单数量、库存统计、访问量统计等等，一旦出现这种问题，轻则数据失真，重则业务逻辑混乱，造成难以估量的损失。所以，理解并解决线程安全问题，是构建健壮并发应用的第一步。

除了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线程安全计数器实现方式》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！