代码拉取完成,页面将自动刷新
/**
* 根据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
呢, 这个方法是高并发调用的啊
这个去掉也可以,问题不大。现在的synchronized已经性能极好了,加个锁一秒被100个线程访问N万次没什么问题.在加锁已经足够满足我们场景的情况下,保证数据的正确性。
网上有很多synchronized的性能测试,譬如++操作之类的。
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。
登录 后才可以发表评论