LongObjectHashMap and IntObjectHashMap 无论是 netty 的实现还是像 JCtool, hppc 这样实现，据我所知，并不是为了快而诞生的，他们突出的一个特性是相比 HashMap 节约了内存的使用量，并且可能在解决 Hash 冲突方面做了一些优化，
> A hash map implementation of LongObjectMap > <https://netty.io/4.1/api/io/netty/util/collection/LongObjectMap.html> that > uses open addressing for keys. To minimize the memory footprint, this class > uses open addressing rather than chaining. Collisions are resolved using > linear probing. Deletions implement compaction, so cost of remove can > approach O(N) for full maps, which makes a small loadFactor recommended. 线性探测和链表的方式解决 Hash 冲突其实本质上是一种 trade off，在不同场景下可以说各有优势，但在实际使用场景下，比如 Dubbo，这两者的差距我觉得很难考量，或者请允许我猜测，他们的差距是微乎其微的。我个人建议是负责测试同学不能仅仅评测单机下的 micro-benchmark ，而是要在实际场景中测试两者的差距，包括 qps 和内存使用量，这工作我觉得是很大的。毕竟我们引入了第三方的依赖，需要有足够的数据佐证这样的改动是有意义的，否则，我在 benchmark 之前，会认为这样的 trade off 是我倾向于保持原样，使用原有的 HashMap。 1. Dubbo 场景中大量的 Map<Long,Object>，这里的 Long 主要是 requestId，在并发请求中，需要快速 put, get , remove ，应该还是需要 focus 在并发性能方面，而非内存占用，所以 synchronized LongObjectHashMap 意义不是很大。 2. 数据需要长期存在于内存中的场景，LongObjectHashMap 有其存在的意义，例如 dubbo 的一些服务元数据，方法信息等等，他们不需要频繁变更，却需要长期占据内存，这比较适合使用新增的 Map 数据结构。 我的观点是主要围绕上述两点去展开工作。 另外，如果想要替换 ConcurrentHashMap，可以测评下 JCtools 的并发 Map，据称是比 jdk 更强。 Last, 这样的 issue 非常有意义，我会持续跟进 ------------------------------------ English：pls copy the above Chinese issue to google translation ，forgive my laziness, hhh. > 在 2018年12月19日，上午11:04，yuhang xiu <[email protected]> 写道： > > Hi, jingfeng, > > I think we should have a benchmark about the sync long object map and > concurrent map. > Personally think the concurrent map is better, but we should have a > benchmark about this two cases. > > Another thing, maybe my description is problematic, we are going to replace > longobjectmap and other maps such as intobjectmap. Not just longobjectmap. > There also has some intobjectmap in dubbo. > After the performance, @stormyu will give us that which map can be replaced. > > And the longobjectmap and intobjectmap has many impls (not just in netty). > Could u give some ideas about this?
