[Enhancement]Replace ConcurrentLongHashMap with ConcurrenHashMap

[berg223]

Search before reporting

• I searched in the issues and found nothing similar.

Motivation

I have write a benchmark for ConcurrentLongHashMap and ConcurrentHashMap. And the result shows ConcurrentHashMap has higher throughput than ConcurrentLongHashMap.

I have upload the benchmark result in attachment file benchmark-concurrent-hashmap.json. You can visialize the result in JMH Visualizer.

Pros of ConcurrentLongHashMap:

1. Avoid boxing and unboxing
2. Cache friendly due to linear probing and compact memory
3. Auto shrink is a great feature

Cons of ConcurrentLongHashMap:

1. Lower throughput
2. Concurrent level is static
3. We have met multiple concurrent issues about ConcurrentLongHashMap:
   ConcurrentLongHashMap may throw an ArrayIndexOutOfBoundsException bookkeeper#4684
   [fix][broker] fix bug caused by optimistic locking #18390
   [fix] Fix ConcurrentLongHashMap concurrency issue bookkeeper#4317
   [fix] Fix concurrent containers concurrency issue #22604
4. We have to sync ConcurrentLongHashMap between bookkeeper and pulsar repo. And there is other classes has the same cons like ConcurrentLongLongPairHashMap.

IMO, we should replace ConcurrentLongHashMap and ConcurrentLongLongPairHashMap with ConcurrentHashMap before we have a better performance.

Solution

Replace ConcurrentLongHashMap and ConcurrentLongLongPairHashMap with ConcurrenHashMap in both pulsar and bookeeper repo.

Alternatives

1. Further optimization on ConcurrentLongHashMap with adaptive concurrent level and simliar mechnism to help rehash.
2. Replace ConcurrentLongHashMap and ConcurrentLongLongPairHashMap with NonBlockingHashMapLong of jctools library.

Anything else?

Further optimization is error prone and may not have a better performance than ConcurrentHashMap.

Are you willing to submit a PR?

• I'm willing to submit a PR!