mappingCount() 是为解决 int 类型容量上限而设计的 long 返回值方法，它复用相同计数逻辑但不截断，虽同为并发估计值，却避免了 size() 在超 21.47 亿时强制返回 Integer.MAX_VALUE 的失真问题。
ConcurrentHashMap 的 mappingCount() 方法不是“更准”的替代品，而是为应对容量超出 int 表达范围而设计的必要选择。它不解决精度问题，但解决了类型边界问题。
为什么 size() 会截断大映射数量
size() 返回 int 类型，最大值是 Integer.MAX_VALUE（2147483647）。当实际映射数超过这个值时，方法强制返回该上限：
- 源码中明确判断：
(n > (long)Integer.MAX_VALUE) ? Integer.MAX_VALUE : (int)n - 哪怕真实计数是 2147483648，
size()仍返回 2147483647 - 这不是 bug，而是类型契约限制——
int无法表示更大的正整数
mappingCount() 的核心价值是 long 类型承载力
mappingCount() 返回 long，支持高达 9223372036854775807 的数值，足够覆盖绝大多数现实场景：
- 它复用相同的底层计数逻辑（
sumCount()），和size()一样基于baseCount与counterCells数组累加 - 区别仅在于：不做强制截断，直接返回原始
long结果 - JDK 注释明确建议：“should be used instead of
sizebecause a ConcurrentHashMap may contain more mappings than can be represented as an int”
两者都不保证强一致性，但用途不同
无论 size() 还是 mappingCount()，在高并发增删过程中都可能返回瞬时快照值，不是事务性精确值：
- 计数本身是无锁累加（CAS 更新
baseCount，冲突时写入counterCells槽位） - 遍历
counterCells时，其他线程可能正在写入新槽位或调整数组大小 - 所以它们都是“估计值”，但
mappingCount()是更完整、不失真的估计
实际使用建议
除非你确定映射数量绝不会超过 21 亿，否则应默认使用 mappingCount()：
- API 兼容性更好：接收
long参数的方法（如流操作、阈值判断）可直接使用，无需类型转换或溢出检查 - 避免隐式截断风险：比如做
if (map.size() > threshold)判断时，若真实 size 超过MAX_VALUE，条件永远为 false - 符合 JDK 官方导向：Javadoc 和源码注释均将
mappingCount()列为首选
