小天管理 发表于 2024年7月11日 发表于 2024年7月11日 笔记在github,觉得有用的给个 Star 。 Rust 笔记 此笔记只是记录在使用 rust 遇到的一些坑或者一些比较好用的工具或者其他的东东。本人主要用 rust 开发网络相关的程序或者桌面程序,因此不涉及音视频和其他的领域。 好用的工具 工程相关 cross:跨平台编译,甚至在 github actions 也可以直接用cross。 tarpaulin:单元测试覆盖率。 min-sized-rust:减少编译后的二进制文件大小。 网络编程相关 常用的 tokio 异步运行时不多说了。http web 框架可能有争议,比如 warp,actix-web 可能性能会好一点,但是 axum 写起来更简单。sqlx 虽然直接写 sql ,相信我,其他的 ORM 框架更难用! tracing:tokio 的日志模块,非常强大,在 tokio 运行时中强烈建议使用 tracing 配合 tracing-appender 做日志。 hyper:开发底层 http1 、http2 必备的 crates 。 axum:http web 框架,CRUD boy 必备。 sqlx:sqlx 框架,CRUD boy 必备。 reqwest:http client 。 clap:开发终端工具/命令行程序必备。 openssl:openssl 相关,由于很多 crate 是基于 openssl 的,一般都是作为 vendor 引入编译的时候直接一起编译。 一些常见的问题和反直觉 一些常见的问题 我不会生命周期,看了'a,'static,&'static,T: 'a 头疼怎么办? 如果用 rust 做 web 程序,根本用不到生命周期。我至今还不懂生命周期,照样用 rust 开发 web ,技术栈就是 axum+tracing+sqlx+reqwest 。 hyper 做 server 会不会内存泄漏? 先说答案,默认的 allocator ,在并发数升高后会导致内存飙升,且并发数降低时,内存不会降低。当前的解决方案是使用 MiMalloc(本人已经验证过,效果良好)。具体的问题讨论在这里。 反直觉 多线程通信我直接用 Arc::Mutex 是不是太 Low 了,使用 RwLock 或者dashmap更好一点? 如果你肯定你的锁是读超多写很少的场景,那么直接用 RwLock 。 如果你不确定你的锁的使用场景,请使用互斥锁。 互斥锁并不慢,我使用互斥锁来存储 redis 的所有数据,最后多线程的压测结果,rcache 的吞吐量是 redis 的两倍。 异步运行时一定优于同步吗?异步运行时一定快吗? 先说结果,不一定,而且异步的程序相比同步的程序肯定要慢的。 什么时候使用异步运行时开发呢? 网络编程就是一个非常好的例子,网络程序中,程序大量的时间都在读取 IO ,因此可以用异步获取超高的吞吐量。 什么时候使用同步运行时开发程序呢? 算法大赛,需要你写一个 rust 算法比比谁的算法快。 1brc tokio::sync::Mutex 性能很低。 常用场景:我看 tokio 里面有 Mutex 我就直接用了,没想那么多。 这个 Mutex 的性能很低,相比 std::sync::Mutex 性能低一倍以上。如果对性能敏感的应用可以直接在异步运行时中使用 std::sync::Mutex 。感兴趣的可以看一下 tokio 的关于 Mutex 的文档。压测的程序在这里.但是在异步运行时中使用 std 的 Mutex 时需要注意的原则是“锁保护的代码段不跨越 await”。 收集到的释放锁的方式。 使用 drop 关键字释放锁 a.lock().clone 也可以释放锁 使用大括号将加锁的代码括起来,代码执行出大括号则自动释放锁 我看 future 提供了很多方法。这两种写法有性能差别吗? let a=b.await?; let c=a.read().await?; let c=b.and_then(|d|d.read()).await? 看上去第二种写法只 await 一次,其实如上两种写法性能上没有本质差别,第二种写法只是使用了 future 这个 crates 提供的内部的状态机。
已推荐帖子