如何实现Long类型RequestID的线程互斥访问控制？

针对你的需求——不同RequestID可并行处理、同一RequestID互斥，最优实现是细粒度锁机制，核心是为每个唯一RequestID分配独立锁实例，同时兼顾线程安全与内存效率。以下是两种主流方案：

方案一：ConcurrentHashMap + ReentrantLock（无冲突精准锁） #

这是最直接的实现方式，为每个RequestID维护独立的可重入锁，确保完全无冲突的并行性。

代码实现 #

import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.locks.ReentrantLock;

public class RequestLockManager {
    // 线程安全的锁映射表，存储RequestID到锁的映射
    private final ConcurrentHashMap<Long, ReentrantLock> lockMap = new ConcurrentHashMap<>();

    public void handleRequest(Long requestId) {
        // 原子性获取或创建锁：若ID不存在则新建锁，避免并发创建重复锁
        ReentrantLock lock = lockMap.computeIfAbsent(requestId, k -> new ReentrantLock());
        
        lock.lock();
        try {
            // --------------------------
            // 这里写处理RequestID的业务逻辑
            // --------------------------
            System.out.printf("Thread %s processing RequestID: %d%n", 
                              Thread.currentThread().getName(), requestId);
            Thread.sleep(1000); // 模拟业务耗时
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            lock.unlock();
            // 仅当锁未被任何线程持有时移除，避免内存泄漏
            // 用双参数remove确保移除的是当前锁实例，防止并发误删
            if (!lock.isLocked()) {
                lockMap.remove(requestId, lock);
            }
        }
    }
}

核心优势 #

• 完全并行：不同RequestID的线程无锁竞争，性能最优
• 线程安全：computeIfAbsent保证原子性，不会出现同一ID对应多个锁的情况
• 内存可控：处理完成后自动移除未被持有的锁，避免长期占用内存
• 可重入支持：ReentrantLock允许同一线程多次获取同一ID的锁，避免死锁

方案二：Striped锁（内存优化型） #

如果你的场景中RequestID基数极大（比如百万级以上），用ConcurrentHashMap可能导致内存占用过高，此时可以用Striped锁——通过哈希将RequestID映射到固定数量的锁实例，以极小的冲突概率换取内存节省。

代码实现（基于Guava） #

import com.google.common.util.concurrent.Striped;
import java.util.concurrent.locks.Lock;

public class StripedRequestLockManager {
    // 初始化16个锁实例（可根据并发量调整，比如64、128）
    private final Striped<Lock> stripedLocks = Striped.lock(16);

    public void handleRequest(Long requestId) {
        // 根据RequestID哈希到对应的锁
        Lock lock = stripedLocks.get(requestId);
        
        lock.lock();
        try {
            // --------------------------
            // 处理RequestID的业务逻辑
            // --------------------------
            System.out.printf("Thread %s processing RequestID: %d%n", 
                              Thread.currentThread().getName(), requestId);
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            lock.unlock();
        }
    }
}

核心优势 #

• 内存固定：锁实例数量固定，不受RequestID基数影响，适合内存敏感场景
• 近似并行：不同RequestID哈希到同一锁的概率极低，大部分场景下仍能保持高效并行
• 实现简单：无需手动管理锁的创建与销毁，降低维护成本

方案选择建议 #

• 若活跃RequestID数量可控（比如几千到几万），优先选方案一，保证零冲突的最优性能
• 若RequestID基数极大或内存资源紧张，选方案二，以极小的冲突代价节省内存

注意事项 #

• 必须在finally块中释放锁，避免异常导致锁泄漏
• 方案一中的remove(requestId, lock)必须用双参数重载，防止并发下误删其他线程刚创建的锁
• 若使用Striped锁，锁数量建议设置为2的幂次（如16、32），哈希分布更均匀

内容的提问来源于stack exchange，提问作者Puneet Garg