Java中ConcurrentHashMap默认分段数、性能影响及自定义方法咨询

1. Java中的ConcurrentHashMap默认分段数是多少？ #

在JDK 7及更早版本中，ConcurrentHashMap默认的分段（Segment）数是16，对应构造方法里concurrencyLevel参数的默认值。
而JDK 8及之后的版本重构了实现逻辑，移除了Segment分段锁机制，改用CAS操作+synchronized锁定链表/红黑树节点的方式实现并发控制，因此不再有“分段数”这个概念。

2. 该分段数对该数据结构的并发性能有何影响？ #

这个问题仅针对JDK 7及之前的版本：

• 分段数直接决定了ConcurrentHashMap的最大并发度：每个Segment对应一把独立的锁，多个线程操作不同Segment的数据时不会互相阻塞。分段数越大，能同时并发操作的线程数上限越高，并发性能越好。
• 但分段数并非越大越好：每个Segment本身是一个小型HashMap，会占用独立内存空间。分段数过多会导致内存开销显著增加，同时哈希计算时的分段映射逻辑也会带来额外性能损耗。如果分段数远大于实际并发线程数，会造成内存资源浪费。

3. 是否支持自定义分段数？若支持，针对特定应用应如何选择合适的数值？ #

• JDK 7及之前：支持自定义分段数，通过构造方法的concurrencyLevel参数指定。注意：底层会将传入的数值调整为最接近的2的幂次方（比如传入10，实际会被调整为16）。
• JDK 8及之后：concurrencyLevel参数依然存在，但不再对应分段数，仅作为初始容量的参考值，底层会根据这个值计算初始数组大小，实际并发控制由节点锁实现，无需再关注分段数。

针对JDK 7的场景选择合适的分段数：

• 优先参考业务预期的最大并发写线程数：将分段数设置为不小于该数值的最小2的幂次方，比如预期最多有12个并发写线程，设置16作为分段数，避免多个线程竞争同一个Segment的锁。
• 平衡内存开销：如果业务并发量不大，不要盲目设置过大的分段数，比如仅需3-4个并发线程，设置8就足够，没必要用默认的16，减少不必要的内存占用。
• 结合数据量：如果存储的数据量很大，适当增大分段数可以减少每个Segment内部的哈希冲突，提升单Segment的操作效率。

内容的提问来源于stack exchange，提问作者Amar kumar Nayak