如何在Java中实现线程安全的计数器

使用AtomicInteger是实现线程安全计数器最常用且高效的方法，它基于CAS原子操作，避免锁开销，适用于多数并发场景。

在Java里要弄个线程安全的计数器，其实有几种搞法，最常见的也最省心的，多半就是用

AtomicInteger

直接说解决方案吧，用

AtomicInteger

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

立即学习“Java免费学习笔记（深入）”；

除了AtomicInteger，还有哪些实现线程安全计数器的方法？

当然了，

AtomicInteger

• synchronized

  关键字： 这是最老牌、最直接的办法。你可以直接在方法签名上加

  synchronized

  ，或者用

  synchronized (this)

  或

  synchronized (某个对象)

  来包裹代码块。它的好处是简单粗暴，上手快。但缺点也很明显，它是一种悲观锁，只要有一个线程进去了，其他想进来的线程就得排队等着，哪怕它们只是想读一下计数器的值。在高并发场景下，这可能会成为性能瓶颈，因为它会导致大量的线程上下文切换和阻塞。

• ReentrantLock

  ： 这是

  java.util.concurrent.locks

  包下的一个类，提供了比

  synchronized

  更细粒度的控制。你可以手动地

  lock()

  和

  unlock()

  ，甚至尝试非阻塞地获取锁（

  tryLock()

  ），或者设置公平锁。它的灵活性更高，可以实现更复杂的同步策略，比如读写锁

  ReentrantReadWriteLock

  。但相应的，代码量也会增加，而且你得确保在

  finally

  块里把锁释放掉，否则就可能死锁。对于计数器这种简单的操作，可能有点‘杀鸡用牛刀’，但如果你需要更复杂的逻辑，比如在计数器更新前后执行其他操作，并且这些操作也需要锁保护，那

  ReentrantLock

  就能派上用场了。

• LongAdder

  /

  DoubleAdder

  ： 这俩是

  AtomicInteger

  和

  AtomicLong

  的增强版，特别为高并发、低竞争的场景优化。它们的核心思想是把一个变量分解成多个变量，每个线程在自己的‘小格子’里累加，最后再把这些‘小格子’里的值汇总起来。这样就大大减少了单个变量上的竞争，因为不同线程可能操作不同的内部变量。如果你有一个计数器，只做增量操作，并且并发量特别大，比如每秒几十万次甚至上百万次的计数，那

  LongAdder

  绝对是你的首选，性能表现会非常惊艳，它在高并发下的吞吐量远超

  AtomicInteger

  。

如何根据实际场景选择最合适的线程安全计数器方案？

选择哪种方案，说到底还是得看你的具体需求和应用场景，没有银弹。

BJXSHOP网上开店专家

BJXShop网上购物系统是一个高效、稳定、安全的电子商店销售平台，经过近三年市场的考验，在中国网购系统中属领先水平；完善的订单管理、销售统计系统；网站模版可DIY、亦可导入导出；会员、商品种类和价格均实现无限等级；管理员权限可细分；整合了多种在线支付接口；强有力搜索引擎支持... 程序更新：此版本是伴江行官方商业版程序，已经终止销售，现于免费给大家使用。比其以前的免费版功能增加了：1，整合了论坛

下载

• 如果你只是需要一个简单的、并发量不是特别高的计数器，或者你的业务逻辑本身就带有锁，那

  synchronized

  可能就够用了。 它代码简洁，可读性好，而且现代JVM对

  synchronized

  也做了很多优化，小并发场景下性能不一定差。它的优势在于易用性，不需要引入额外的类。

• 对于大多数通用场景，特别是需要高效率的原子操作，

  AtomicInteger

  几乎是默认的选择。 它的性能通常比

  synchronized

  好，因为它避免了操作系统级别的线程上下文切换，直接在用户空间通过CAS指令完成操作。而且代码也比较简洁，不需要手动管理锁。它适用于并发量中等偏高，且只需要对单个变量进行原子操作的场景。

• 如果你的计数器操作非常频繁，而且并发度极高，比如每秒几十万甚至上百万次的增量操作，并且你只关心最终的累加结果，不关心中间的瞬时值，那么

  LongAdder

  会是最佳选择。 它的设计就是为了应对这种极端情况，通过分散热点来减少竞争，从而提供更高的吞吐量。它牺牲了一点点获取当前准确值的效率（需要汇总所有内部变量），来换取极高的写入性能。

• 而

  ReentrantLock

  呢，它更适用于那些需要更复杂同步逻辑的场景，比如需要条件变量（

  Condition

  ）来协调线程，或者需要尝试获取锁、限时获取锁等高级功能。 对于单纯的计数器，它的优势并不明显，反而会增加代码的复杂性，因为你需要手动地管理锁的获取和释放，这增加了出错的可能性。

总的来说，我的建议是：优先考虑

AtomicInteger

LongAdder

synchronized

ReentrantLock