同ID信号并发场景如何避免Java多线程竞态条件且不影响性能？

你遇到的是典型的同键维度check-then-act竞态问题，不需要加全局synchronized锁——全局锁会让所有ID的信号处理全串行化，性能损耗极大。用细粒度的ID维度锁，就能做到不同ID的处理完全并行，仅同ID线程在初始化映射阶段短暂互斥，完全匹配你的需求。

方案1：ID维度细粒度锁（无需修改现有SOTable实现，改造成本最低） #

核心思路是给每个信号ID分配一个独立的锁对象，同ID的线程竞争同一把锁，不同ID的线程之间完全没有锁冲突。锁对象存在线程安全的ConcurrentHashMap里，全局单例维护。
实现代码如下：

import java.util.concurrent.ConcurrentHashMap;

// 全局单例维护ID和锁的映射，本身是线程安全的
private static final ConcurrentHashMap<Object, Object> ID_LOCK_REGISTRY = new ConcurrentHashMap<>();

public void handleSignal(Object ID, Object data) {
    SOTable testtable = SOTable.getInstance();
    // 同ID永远拿到同一个锁对象，不同ID拿到不同锁，互不干扰
    Object idLock = ID_LOCK_REGISTRY.computeIfAbsent(ID, key -> new Object());
    
    synchronized (idLock) {
        // 拿到锁后做二次校验：前一个拿到锁的同ID线程可能已经完成了映射创建
        if (testtable.findvalue(ID) == null) {
            testtable.create_map_and_insert(ID, data);
        } else {
            testtable.insert_to_exist_map(ID, data);
        }
    }

    // 可选优化：如果ID是一次性、后续不会再出现的，可以在确认映射创建完成后，把对应锁从注册表移除，避免内存持续增长
    // 注意：移除操作必须保证没有其他线程正在等待该ID的锁，否则会出现锁对象不一致的竞态
}

这个方案的优势：

• 改造成本极低，不需要动现有SOTable的内部逻辑
• 性能几乎和无锁场景持平，不同ID的信号处理完全并行，只有同ID线程会在同步块内短暂串行
• 没有额外依赖，JDK1.8及以上版本原生支持

注意不要踩两个常见坑：

• 不要每次进入处理逻辑都新建锁对象，否则同ID线程拿到的锁不同，完全起不到互斥作用
• 不要用String.intern()返回的字符串当锁，会存在元空间内存泄漏的风险

方案2：改造SOTable底层存储，用并发容器原生原子方法（性能最优） #

如果你可以修改SOTable的内部实现，直接把存储映射的容器换成ConcurrentHashMap，用它自带的computeIfAbsent原子方法完成创建逻辑，连单独维护锁注册表的开销都能省掉：

import java.util.concurrent.ConcurrentHashMap;

public class SOTable {
    // 替换原来非线程安全的存储结构
    private final ConcurrentHashMap<Object, SignalDataMap> storage = new ConcurrentHashMap<>();
    
    private static final SOTable INSTANCE = new SOTable();
    private SOTable() {}
    public static SOTable getInstance() {return INSTANCE;}

    public void processSignal(Object ID, Object data) {
        // 原子操作：如果ID对应映射不存在，第一个执行到这里的线程会原子完成映射创建
        // 其他同ID线程会阻塞等待创建完成，拿到已经初始化好的映射对象，不会重复创建
        SignalDataMap targetMap = storage.computeIfAbsent(ID, k -> createNewMapForId(k));
        // 走到这里targetMap一定已经存在，直接插入数据即可
        targetMap.insert(data);
    }

    private SignalDataMap createNewMapForId(Object ID) {
        // 原来create_map_and_insert里的映射创建逻辑放这里
        return new SignalDataMap();
    }
}

这个方案是性能最优的，ConcurrentHashMap内部对computeIfAbsent做了分段优化，锁粒度比自己维护ID锁更细，高并发下表现更好。

原代码问题根因 #

原来的逻辑是先判断findvalue(ID) == null再执行创建，这个判断和创建不是原子操作：两个同ID线程可以同时读到null，同时进入创建分支，就会触发“映射已存在”的异常，本质是多线程下非原子的check-then-act必然出现竞态。

内容的提问来源于stack exchange，提问作者Burak Topcu