记一次hashmap乱序的问题

首先交代一下背景,一个用户权限菜单按照数据库字段sort倒序排列,首先sql按照order by sort desc倒序传到前台中的数据没问题,但是将数据转为树节点(此代码是我维护),简单看了下,他是采用Hashmap。而 Hashmap是无序,所以在网上查了下有序的map,看到一个说Treemap是有序的,于是改用TreeMap,最后发现还是无序的,key是采用的String。

    于是查看源码

从源码中可以看到,是通过key的compareto方法进行比较的,于是查看String实现Comparable接口中compareTo方法的源码

从源码中可以看到,String首先将较小长度的字符串与较长字符串比较(如  "abc"和"abcd"),若较小字符串与较长字符串的前几位都相等则较长字符串大,否则就是通过asc码来比较大小。所以TreeMap是不能记录元素的放入顺序的。

结果采用LinkedHashMap解决问题。LinkedHashMap是采用双向链表的方式记录插入的顺序


2019-4-9  补充

HashMap 无序的原因就是 它在放入元素的时候,是通过key值产生一个哈希值,然后构造一个node节点放入数组中,每个key产生的哈希值是无法确定的,它在数组中的位置是无法确定的,所以 HashMap中的放入元素是无序的。

LinkedHashMap 是有序的,jdk是1.8 , 我们看下它的放入元素代码:

Node<K,V> newNode(int hash, K key, V value, Node<K,V> e) {
        LinkedHashMap.Entry<K,V> p =
            new LinkedHashMap.Entry<K,V>(hash, key, value, e);
        linkNodeLast(p);
        return p;
    }

 private void linkNodeLast(LinkedHashMap.Entry<K,V> p) {
        LinkedHashMap.Entry<K,V> last = tail;
        tail = p;
        if (last == null)
            head = p;
        else {
            p.before = last;
            last.after = p;
        }
    }


static class Entry<K,V> extends HashMap.Node<K,V> {
        Entry<K,V> before, after;
        Entry(int hash, K key, V value, Node<K,V> next) {
            super(hash, key, value, next);
        }
    }

LinkedHashMap  的 put 方法和 putVal 方法都是共用的 HashMap 里面的。但是它重写了 newNode 方法 ,我们知道 newNode 是 HashMap  在大多数情况下插入数据的方法。 

代码中可以看到 LinkedHashMap 底层维护了一个自己的 Entry 实现类 ,这个类 继承了 HashMap.Node ,里面的属性  before 和 after 分别指向前一个元素和后一个元素,你可能已经想到了一种数据结构,没错,它是一个双向链表。并且在 linkNodeLast 中,每个新插入的元素会被放入双向链表的尾部,所以 LinkedHashMap 就是通过自己实现的 Entry 双向链表来保证插入元素的顺序。

  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
这次的文章标题原本想叫《一次因错用HashMap造成的生产BUG》,但作者觉得这个标题可能会让人联想到某些Java公众号写的标题党文章,所以改成了现在这个标题。在文章中,作者承认在A接口中将所有产品都放到HashMap中并不太规范,但在实际实现中是可行的,所以并不算是“错用”。然而,作者在写代码时疏忽了缓存的问题,忽视了HashMap在多线程环境下不能使用的要求,结果写出了有BUG的代码。 作者从这次线上BUG中学到了几个教训:首先,在使用直接存放对象引用的内存缓存时,要注意不要修改从缓存中获取的内容;其次,在修改代码时,要全面考虑前后逻辑,思考修改的后果;再次,不要困于思维陷阱,在寻找问题时不一定问题出在前面的代码;最后,遇到解决不了的问题时,寻求帮助是很重要的,领导在几分钟内就发现了作者几个小时都没找到的BUG。 问题出现在addDisplayStyle()方法中。当有多个APP请求A接口时,业务线程执行到product.put("displayStyle", displayStyle)这行代码时,实际上是在往同一个Map中放入元素。由于key相同,就会发生哈希冲突。如果此时某个Map的元素个数达到了扩容条件,就会触发扩容,并有可能出现链表成环的情况。当有新的请求到来时,工作线程执行到recommends = deduplicateAndGetFirstN(recommends, 3)这行代码。 综上所述,这次的文章是关于作者经历的一次因错用HashMap而导致生产BUG的经历。作者从中学到了关于使用缓存、修改代码、寻找问题和寻求帮助等方面的教训。问题出现在addDisplayStyle()方法中,当多个APP请求A接口时,可能会触发HashMap的扩容并导致链表成环的情况。<span class="em">1</span><span class="em">2</span><span class="em">3</span><span class="em">4</span>
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值