哈希表杂谈

哈希表,对于很多开发人员来说简直亲切的不要不要的,但哈希表在严重的哈希冲突的时候其查询的时间复杂度就会严重退化(JDK1.8之前是拉链法 时间复杂度O(N),之后是红黑树 时间复杂度O(logn)),对于具有实时性要求的系统来说绝对是个大隐患,那么如何解决呢?
如果软件系统自主管理关键字(key)的生成和分发,则有一个很好的解决方案:任何查询算法都不如直接寻址,我们用1024作为横轴,用1024的倍数作为纵轴,构建一个所谓的查找坐标系,对于一个整数key,右移10位取得Y值,然后用Y值左移10位后与key的差值就是X值,如此存储位置确定了,也没有冲突,时间复杂度始终是O(1)。这个技术方案的关键是自主管理key的生成,其实也很简单:四字节整数 key从0开始++即可,如果看起来不舒服,则可以与一个常量整数略微计算一个以得到一个看起来比较professional的key。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值