基于 “不可变类” 实现一个线程安全的 Integer 计数器

本文介绍如何通过创建不可变类ImmutableIntegerCounter实现线程安全的计数器。不可变类的特性确保在多线程环境下,每次操作都返回新的对象,避免了同步和锁带来的性能问题,确保数据一致性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

写在前面

众所周知,java.lang.String 类没有任何强制同步的代码,但它是线程安全的,原因在于它是不可变类,每次对其操作都是返回一个新的 String 对象。合理使用不可变对象可以达到 lock-free 的效果。

不可变对象最核心的地方在于不给外部修改共享资源的机会,从而避免多线程情况下由于争抢共享资源导致的数据不一致,又是 lock-free 的,避免了用锁带来的性能损耗。

ImmutableIntegerCounter

// final 修饰,不能继承
public final class ImmutableIntegerCounter {

    // final 修饰,不允许其他线程对其更改
    private final int initial;

    public ImmutableIntegerCounter(int initial) {
        this.initial = initial;
    }

    public ImmutableIntegerCounter(ImmutableIntegerCounter counter, int i) {
        this.initial = counter.getInitial() + i;
    }

    // 每次调用 increment 都会新构造一个 ImmutableIntegerCounter
    public ImmutableIntegerCounter increment(int i) {
        return new ImmutableIntegerCounter(this, i);
    }

    public int getInitial() {
        return initial;
    }
}

测试

import org.junit.Before;
import org.junit.Test;

import java.util.concurrent.TimeUnit;
import java.util.stream.IntStream;

public class ImmutableIntegerCounterTest {

    private ImmutableIntegerCounter integerCounter = null;

    @Before
    public void init() {
        integerCounter = new ImmutableIntegerCounter(0);
    }

    @Test
    public void incrementTest() throws InterruptedException {

        IntStream.range(0, 3).forEach(i -> new Thread(() -> {
            int increment = 1;
            while(true) {
                int oldValue = integerCounter.getInitial();
                int result = integerCounter.increment(increment).getInitial();
                System.out.println(oldValue + "+" + increment + "=" + result);
                assert (oldValue + increment) == result;
                increment++;
                try {
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start());

        TimeUnit.SECONDS.sleep(10);

    }
}

输出结果

三个线程的输出结果均是正确的

0+1=1
0+1=1
0+1=1
0+2=2
0+2=2
0+2=2
0+3=3
0+3=3
0+3=3
0+4=4
0+4=4
0+4=4

Process finished with exit code 130 (interrupted by signal 2: SIGINT)
<think>好的,我现在需要回答用户关于LinkedBlockingQueue如何实现线程安全的问题。首先,我得回忆一下LinkedBlockingQueue的基本结构和用途。它是一个基于链表实现的阻塞队列,常用于多线程环境下的生产者-消费者模型。线程安全是关键特性,所以用户想知道其内部机制。 接下来,我应该分解LinkedBlockingQueue的线程安全实现。首先想到的是锁机制。LinkedBlockingQueue通常使用两个ReentrantLock锁,一个用于入队(putLock),一个用于出队(takeLock)。这样可以分离入队和出队的操作,减少竞争,提高并发性能。但需要确认是否正确,比如是否真的用了两个锁,或者有没有例外情况。 然后是内部数据结构。链表结构由节点构成,每个节点包含元素和指向下一个节点的引用。头节点和尾节点的操作需要保证原子性,这时候锁的作用就体现出来了。比如,入队操作在尾部添加节点,需要获取putLock,而出队操作从头部移除节点,需要获取takeLock。这样同时进行入队和出队不会互相阻塞。 接下来是条件变量(Condition)。当队列为空时,消费者线程需要等待,直到有元素入队;当队列满时,生产者线程需要等待,直到有空间。这里可能使用了notEmpty和notFull这两个条件变量,分别由对应的锁管理。例如,put操作在队列满时调用notFull.await(),而take操作在取出元素后调用notFull.signal(),反之亦然。 还需要考虑容量控制。LinkedBlockingQueue可以有界或无界,当有界时,容量达到上限会阻塞生产者线程。容量通过原子变量(如AtomicInteger)来维护吗?或者是否通过锁来同步?实际上,容量可能由内部的count变量来维护,而count变量由putLock和takeLock共同管理,使用原子操作或者volatile关键字保证可见性。但具体实现可能用到了双重检查,或者使用锁来保护count的修改。 原子操作方面,比如入队和出队时对count的增减是否线程安全。由于入队和出队分别由不同的锁控制,但count可能被两个锁同时影响,所以需要使用原子变量或者在操作count时用主锁(比如,是否有一个全局锁?不过我记得LinkedBlockingQueue是用了两个锁,所以count的修改可能需要在两个锁的保护下进行,或者使用volatile加上原子操作。例如,count是AtomicInteger类型,或者用volatile int,再结合锁来保证原子性。) 另外,迭代器的线程安全。虽然LinkedBlockingQueue本身是线程安全的,但它的迭代器是弱一致性的,这意味着迭代器创建后可能不会反映所有修改。这部分是否需要提及?用户可能想知道迭代时是否安全,所以应该说明迭代器不会抛出ConcurrentModificationException,但数据可能不是最新的。 还有,入队和出队的具体操作步骤。比如,入队操作需要获取putLock,插入节点到尾部,然后判断如果之前队列为空,可能需要唤醒等待的消费者线程。同时,如果插入后队列未满,继续唤醒其他生产者线程。这里需要确保在释放锁之前正确发出信号。 可能存在的边界情况,比如队列为空或满时的处理,如何正确使用条件变量来等待和唤醒线程。例如,当执行take()时,如果队列为空,线程会阻塞在notEmpty条件上,直到有元素被放入队列,此时入队操作会唤醒notEmpty上的线程。 此外,需要确认LinkedBlockingQueue的默认容量是多少,比如Integer.MAX_VALUE,即无界队列,但用户也可以指定容量。容量的大小影响阻塞行为,当有界时,put操作在队列满时阻塞,offer操作可以设置超时或立即返回false。 最后,总结其线程安全的关键点:分离锁设计、条件变量控制阻塞与唤醒、原子变量维护状态、以及链表操作的线程安全。需要将这些点组织成清晰的步骤,用中文逐步解释,确保用户容易理解。 可能还需要比较其他阻塞队列的实现,比如ArrayBlockingQueue使用单一锁,而LinkedBlockingQueue使用双锁,因此在高并发下性能更好。但用户的问题不需要比较,只要解释LinkedBlockingQueue的实现,所以可能不需要展开这部分。 检查是否有遗漏的关键点,比如节点对象的不可变性?或者内存可见性如何保证?比如,Node中的item是volatile的吗?或者通过锁的释放来保证happens-before关系。例如,在入队时,更新tail节点后,释放putLock,这样其他线程获取putLock时能看到之前的修改。同样,出队操作通过takeLock来保证可见性。 总结起来,回答的结构应该是: 1. 分离锁机制(入队和出队锁) 2. 条件变量管理线程阻塞与唤醒 3. 原子变量维护队列状态(count) 4. 链表操作的线程安全 5. 迭代器的弱一致性 6. 容量控制与阻塞策略 这样分点详细说明,每个部分解释其如何保证线程安全,确保回答结构清晰,用户容易理解。</think>LinkedBlockingQueue 是 Java 并发包中基于链表的阻塞队列,其线程安全通过以下机制实现: --- ### **1. 分离锁设计(双锁机制)** - **入队锁 (`putLock`) 和出队锁 (`takeLock`)** 入队操作(如 `put()`)使用 `putLock`,出队操作(如 `take()`)使用 `takeLock`。两者独立,允许生产者和消费者线程并发执行,减少竞争。 ```java private final ReentrantLock putLock = new ReentrantLock(); private final ReentrantLock takeLock = new ReentrantLock(); ``` --- ### **2. 条件变量控制阻塞与唤醒** - **队列非空条件 (`notEmpty`)** 消费者线程在队列为空时通过 `notEmpty.await()` 阻塞,生产者插入元素后通过 `notEmpty.signal()` 唤醒消费者。 - **队列非满条件 (`notFull`)** 生产者线程在队列满时通过 `notFull.await()` 阻塞,消费者取出元素后通过 `notFull.signal()` 唤醒生产者。 ```java private final Condition notEmpty = takeLock.newCondition(); private final Condition notFull = putLock.newCondition(); ``` --- ### **3. 原子变量维护队列状态** - **容量计数器 (`count`)** 通过原子变量 `AtomicInteger` 记录队列元素数量,确保入队和出队操作的原子性。 ```java private final AtomicInteger count = new AtomicInteger(0); ``` - **入队时**:先加锁 `putLock`,插入元素后原子性增加 `count`。 - **出队时**:先加锁 `takeLock`,移除元素后原子性减少 `count`。 --- ### **4. 链表操作的线程安全** - **头节点 (`head`) 和尾节点 (`last`)** 链表操作在锁的保护下进行: - **入队**:在尾部追加节点,更新 `last`(受 `putLock` 保护)。 - **出队**:移除头节点,更新 `head`(受 `takeLock` 保护)。 - **内存可见性** 锁的释放会强制刷新内存状态,确保其他线程能感知到最新修改。 --- ### **5. 容量控制与阻塞策略** - **有界队列** 初始化时指定容量上限,队列满时 `put()` 阻塞,`offer()` 返回 `false`。 - **无界队列** 默认容量为 `Integer.MAX_VALUE`,`put()` 永不阻塞。 --- ### **6. 迭代器的弱一致性** 迭代器通过遍历链表快照实现,不保证实时一致性,但避免抛出 `ConcurrentModificationException`。 --- ### **总结** LinkedBlockingQueue 通过 **分离锁、条件变量、原子计数和链表操作同步** 实现高效线程安全,适用于高并发生产-消费场景。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值