文盘Rust -- 生命周期问题引发的 static hashmap 锁 | 京东云技术团队
2021年上半年,撸了个rust cli开发的框架,基本上把交互模式,子命令提示这些cli该有的常用功能做进去了。项目地址:https://github.com/jiashiwen/interactcli-rs。
春节以前看到axum已经0.4.x了,于是想看看能不能用rust做个服务端的框架。
春节后开始动手,在做的过程中会碰到各种有趣的问题。于是记下来想和社区的小伙伴一起分享。社区里的小伙伴大部分是DBA和运维同学,如果想进一步了解更底层的东西,代码入手是个好路数。
我个人认为想看懂代码先要写好代码,起码了解开发的基本路数和工程的一般组织模式。但好多同学的主要工作并不是专职开发,所以也就没有机会下探研发技术。代码这个事儿光看书是不管用的。了解一门语言最好的方式是使用它。
那么,问题来了非研发人员如何熟悉语言呢?咏春拳里有句拳谚:”无师无对手,桩与镜中求“。解释两句,就是在没有师兄弟练习的情况下,对着镜子和木人桩练习。在这里我觉得所谓桩有两层含义,一个是木人桩,就是练习的工具,一个是”站桩“,传统武术训练基本功的方法。其实在实际的工作中DBA和运维同学会有很多场景需要编程,比如做一些运维方面的统计工作;分析问题时需要拿到某些数据。如果追求简单用Python的话可能对于其他语言就没有涉猎了。如果结合你运维数据库的原生开发语言,假以时日慢慢就能看懂相关的底层逻辑了。我个人有个观点,产品研发的原生语言是了解产品底层最好的入口。
后面如果在Rust的开发过程中有其他问题,我本人会把问题结合实际也写到这个系列里,也希望社区里对Rust感兴趣的小伙伴一起来”盘Rust“。 言归正传,说说这次在玩儿Rust时遇到的问题吧。
在 Rust 开发过程中,我们经常需要全局变量作为公共数据的存放位置。通常做法是利用 lazy_static/onecell 和 mux/rwlock 生成一个静态的 collection。
代码长这样
use std::collections::HashMap; use std::sync::RwLock; lazy_static::lazy_static! { static ref GLOBAL_MAP: RwLock<HashMap<String,String>> = RwLock::new({ let map = HashMap::new(); map }); }
基本的数据存取这样实现
use std::collections::HashMap; use std::sync::RwLock; lazy_static::lazy_static! { static ref GLOBAL_MAP: RwLock<HashMap<String,String>> = RwLock::new({ let map = HashMap::new(); map }); } fn main() { for i in 0..3 { insert_global_map(i.to_string(), i.to_string()) } print_global_map(); println!("finished!"); } fn insert_global_map(k: String, v: String) { let mut gpw = GLOBAL_MAP.write().unwrap(); gpw.insert(k, v); } fn print_global_map() { let gpr = GLOBAL_MAP.read().unwrap(); for pair in gpr.iter() { println!("{:?}", pair); } }
insert_global_map函数用来向GLOBAL_MAP插入数据,print_global_map()用来读取数据,上面程序的运行结果如下
("0", "0") ("1", "1") ("2", "2")
下面我们来实现一个比较复杂一点儿的需求,从 GLOBAL_MAP 里取一个数,如果存在后面进行删除操作,直觉告诉我们代码似乎应该这样写
use std::collections::HashMap; use std::sync::RwLock; lazy_static::lazy_static! { static ref GLOBAL_MAP: RwLock<HashMap<String,String>> = RwLock::new({ let map = HashMap::new(); map }); } fn main() { for i in 0..3 { insert_global_map(i.to_string(), i.to_string()) } print_global_map(); get_and_remove(1.to_string()); println!("finished!"); } fn insert_global_map(k: String, v: String) { let mut gpw = GLOBAL_MAP.write().unwrap(); gpw.insert(k, v); } fn print_global_map() { let gpr = GLOBAL_MAP.read().unwrap(); for pair in gpr.iter() { println!("{:?}", pair); } } fn get_and_remove(k: String) { println!("execute get_and_remove"); let gpr = GLOBAL_MAP.read().unwrap(); let v = gpr.get(&*k.clone()); let mut gpw = GLOBAL_MAP.write().unwrap(); gpw.remove(&*k.clone()); }
上面这段代码输出长这样
("0", "0") ("1", "1") ("2", "2") execute get_and_remove
代码没有结束,而是hang在了get_and_remove函数。 为啥会出现这样的情况呢?这也许与生命周期有关。gpr和gpw 这两个返回值分别为 RwLockReadGuard 和 RwLockWriteGuard,查看这两个
struct 发现确实可能引起死锁
must_not_suspend = "holding a RwLockWriteGuard across suspend \ points can cause deadlocks, delays, \ and cause Future's to not implement `Send`"
问题找到了就可以着手解决办法了,既然是与rust的生命周期有关,那是不是可以把读和写分别放在两个不同的生命周期里呢,于是对代码进行改写
use std::collections::HashMap; use std::sync::RwLock; lazy_static::lazy_static! { static ref GLOBAL_MAP: RwLock<HashMap<String,String>> = RwLock::new({ let map = HashMap::new(); map }); } fn main() { for i in 0..3 { insert_global_map(i.to_string(), i.to_string()) } print_global_map(); get_and_remove(1); println!("finished!"); } fn insert_global_map(k: String, v: String) { let mut gpw = GLOBAL_MAP.write().unwrap(); gpw.insert(k, v); } fn print_global_map() { let gpr = GLOBAL_MAP.read().unwrap(); for pair in gpr.iter() { println!("{:?}", pair); } } fn get_and_remove_deadlock(k: String) { println!("execute get_and_remove"); let gpr = GLOBAL_MAP.read().unwrap(); let _v = gpr.get(&*k.clone()); let mut gpw = GLOBAL_MAP.write().unwrap(); gpw.remove(&*k.clone()); } fn get_and_remove(k: i32) { let v = { let gpr = GLOBAL_MAP.read().unwrap(); let v = gpr.get(&*k.to_string().clone()); match v { None => Err(anyhow!("")), Some(pair) => Ok(pair.to_string().clone()), } }; let vstr = v.unwrap(); println!("get value is {:?}", vstr.clone()); let mut gpw = GLOBAL_MAP.write().unwrap(); gpw.remove(&*vstr); }
正确输出
("1", "1") ("0", "0") ("2", "2") get value is "1" ("0", "0") ("2", "2") finished!
Rust的生命周期是个很有意思的概念,从认识到理解确实有个过程。
源码地址
作者:京东科技 贾世闻
来源:京东云开发者社区 转载请注明来源

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
jdk17下netty导致堆内存疯涨原因排查 | 京东云技术团队
背景: 介绍 天网风控灵玑系统是基于内存计算实现的高吞吐低延迟在线计算服务,提供滑动或滚动窗口内的count、distinctCout、max、min、avg、sum、std及区间分布类的在线统计计算服务。客户端和服务端底层通过netty直接进行tcp通信,且服务端也是基于netty将数据备份到对应的slave集群。 低延迟的瓶颈 灵玑第1个版本经过大量优化,系统能提供较大的吞吐量。如果对客户端设置10ms超时,服务端1wqps/core的流量下,可用率只能保证在98.9%左右,高并发情况下主要是gc导致可用率降低。如果基于cms 垃圾回收器。当一台8c16g的机器在经过第二个版本优化后吞吐量超过20wqps的时候,那么大概每4秒会产生一次gc。如果按照一次gc等于30ms。那么至少分钟颗粒度在gc时间的占比至少在(15*30/1000/60)=0.0075。也就意味着分钟级别的tp992至少在30ms。不满足相关业务的需求。 jdk17+ZGC 为了解决上述延迟过高的相关问题,JDK 11 开始推出了一种低延迟垃圾回收器 ZGC。ZGC 使用了一些新技术和优化算法,可以将 GC 暂停...
- 下一篇
从积木式到装配式云原生安全 | 京东云技术团队
云原生安全风险 随着云原生架构的快速发展,核心能力逐渐稳定,安全问题日趋紧急。在云原生安全领域不但有新技术带来的新风险,传统IT基础设施下的安全威胁也依然存在。要想做好云原生安全,就要从这两个方面分别进行分析和解决。 新技术带来新的安全风险 云原生的概念定义本身就比较抽象,从诞生到现在也经历了多次变化。2018年CNCF对云原生的概念进行了重定义:云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。虽然这是云原生概念最新的定义,但是不同的人对云原生的抽象概念理解相差很大,一直在不断地争论。狭义的理解直接套用定义,认为定义之外的技术不属于云原生。广义的理解则认为定义不够贴切,应该从字面含义进行理解,认为只要是能利用云的特性,在软件工程各阶段提高效率,降低成本的行为、技术,都可以认为是云原生。 从普遍认知来看,云原生主要包括kubernetes和容器、微服务、云基础设施,其中kubernetes和容器在某种程度上已经是云原生的代名词。其中kubernetes和容器作为云原生时代...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS8编译安装MySQL8.0.19
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Red5直播服务器,属于Java语言的直播服务器
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7