405 Star 3.7K Fork 1.2K

GVP京东零售 / hotkey

 / 详情

在判断isHotKey(key) 为什么要有 synochronized块啊

已完成
任务
创建于  
2020-07-07 18:56
/**
     * 根据key返回对应的LocalCache。
     * 譬如Rules里有多个
     * {key1 , 500}
     * {key2 , 600}
     * {*    , 700}
     * 如果命中了key1,就直接返回。如果key1、key2都没命中,再去判断rule里是否有 * ,如果有 * 代表通配
     */
    public static LocalCache findByKey(String key) {
        if (StrUtil.isEmpty(key)) {
            return null;
        }
        synchronized (KEY_RULES) {
            LocalCache prefix = null;
            LocalCache common = null;

            //遍历该app的所有rule,找到与key匹配的rule。优先全匹配->prefix匹配-> * 通配
            //这一段虽然看起来比较奇怪,但是没毛病,不要乱改
            for (KeyRule keyRule : KEY_RULES) {
                if (key.equals(keyRule.getKey())) {
                    return RULE_CACHE_MAP.get(keyRule.getDuration());
                }
                if ((keyRule.isPrefix() && key.startsWith(keyRule.getKey()))) {
                    prefix = RULE_CACHE_MAP.get(keyRule.getDuration());
                }
                if ("*".equals(keyRule.getKey())) {
                    common = RULE_CACHE_MAP.get(keyRule.getDuration());
                }
            }

            if (prefix != null) {
                return prefix;
            }
            return common;
        }

    }

这里为什么要用synchronized呢, 这个方法是高并发调用的啊

评论 (1)

亚里士缺德 创建了任务
展开全部操作日志

这个去掉也可以,问题不大。现在的synchronized已经性能极好了,加个锁一秒被100个线程访问N万次没什么问题.在加锁已经足够满足我们场景的情况下,保证数据的正确性。
网上有很多synchronized的性能测试,譬如++操作之类的。

tianyaleixiaowu 任务状态待办的 修改为已完成

登录 后才可以发表评论

状态
负责人
项目
里程碑
Pull Requests
关联的 Pull Requests 被合并后可能会关闭此 issue
分支
开始日期   -   截止日期
-
置顶选项
优先级
预计工期 (小时)
参与者(2)
303698 tianyalei 1578919857
Java
1
https://gitee.com/jd-platform-opensource/hotkey.git
git@gitee.com:jd-platform-opensource/hotkey.git
jd-platform-opensource
hotkey
hotkey

搜索帮助