Java ConcurrentHashMap：仅当大小小于X时添加元素的优化实现探讨

原方案的问题 #

你当前用synchronized包裹ConcurrentHashMap的判断与添加操作，虽然能保证逻辑正确性，但完全浪费了ConcurrentHashMap的并发优势——所有线程都要争抢同一个全局锁，并发场景下性能会大幅下降。

你的AtomicInteger方案的问题 #

你设计的基于AtomicInteger的方案存在数据一致性风险：

• count计数器和myMap的实际大小没有绑定，两者状态可能脱节。比如：
  1. 若有线程删除了myMap中的元素，count不会自动减少，导致明明myMap大小已小于5，却因count被固定为6而无法添加新元素；
  2. 若有其他线程直接向myMap中添加元素（未通过count控制），count不会同步增加，导致count显示可添加，但实际myMap已满，最终元素数量超过限制。
     除非所有对myMap的增删操作都严格同步更新count，否则这个方案无法保证逻辑正确性，反而增加了维护成本。

更优的并发实现方案 #

根据你的需求（仅当ConcurrentHashMap大小小于指定值时执行添加），分两种场景给出方案：

场景1：允许近似判断（接受并发下短暂超量） #

如果业务可以接受因并发竞争导致的短暂元素超量（比如多个线程同时判断size<5并执行添加），可以利用ConcurrentHashMap的原子方法computeIfAbsent，无需全局锁，并发性能更好：

myMap.computeIfAbsent("something", key -> {
    // size()返回近似值，若当前近似大小小于5则添加
    return myMap.size() < 5 ? true : null;
});

注：ConcurrentHashMap.size()返回的是并发下的近似值，因此可能出现多个线程同时进入添加逻辑的情况。

场景2：严格保证精确判断（不允许超量） #

如果必须严格保证“仅当myMap精确大小小于5时才添加”，那么独占锁是无法避免的，但可以用ReentrantLock替代synchronized，在高并发场景下性能略优（差异不大）：

private final ReentrantLock lock = new ReentrantLock();

// 添加逻辑
lock.lock();
try {
    if (myMap.size() < 5) {
        myMap.putIfAbsent("something", true);
    }
} finally {
    lock.unlock();
}

这种方式和原方案逻辑一致，但ReentrantLock支持更多高级特性（如公平锁、可中断锁），若后续有扩展需求更灵活。

额外思路：基于容量限制的封装 #

如果你的需求是长期限制myMap的最大元素数，可以封装一个自定义的并发容器，将大小判断与修改操作绑定为原子逻辑，避免重复编写锁逻辑：

public class BoundedConcurrentHashMap<K, V> {
    private final ConcurrentHashMap<K, V> map = new ConcurrentHashMap<>();
    private final int maxSize;
    private final ReentrantLock lock = new ReentrantLock();

    public BoundedConcurrentHashMap(int maxSize) {
        this.maxSize = maxSize;
    }

    public boolean putIfAbsent(K key, V value) {
        lock.lock();
        try {
            if (map.size() < maxSize) {
                return map.putIfAbsent(key, value) == null;
            }
            return false;
        } finally {
            lock.unlock();
        }
    }

    // 其他需要的方法，如get、remove等，按需实现并同步锁
}

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