更新操作 到目前为止，我们值实现了插入和检索操作。让我看一下如何拓展系统，使其支持更新操作。 传统的更新 在单线程系统中，更新操作相当直观：TIcketStore提供一个get_mut方法，允许调用者获取一个可变的ticket引用，然后直接修改。 多线程更新 同样的操作方式在多线程版本中就不行。借用
2025-11-19
有界通道和无界通道 到目前为止,我们一直在使用无界通道。我们想发送多少消息就发送多少消息，通道也会相应增长以容纳这些消息。 在多生产者，单消费者的情况下这可能会产生问题：如果生产者以比消费者处理信息更快的速度发出信息，通道就会不断增长，可能会消耗掉所有可用内存。 建议是，生产系统中绝不要使用无界通道
2025-11-18
我现在总是觉得自己很多基础没有打牢固，虽然很多人觉得我表面上技术很强，但实际上是废物一坨。只会一些拼拼凑凑的小技巧，没有底子还是不行。虽然现在在学Rust和TS，但是真正上手开发，会发现困难重重，无从下手。想要认真做吧，难道又要只用AI？用AI谁不会，难不成到时候拿着AI去找工作？他妈的能被笑话死，
2025-11-18
在Archlinux愉快使用MAA 首先确保你的linux内核是linux-zen，我不清楚其他内核能否正常运行，大家可以在评论区留言其他内核的情况。 使用podman启动redroid，我们使用redroid运行安卓模拟器 podman的安装 sudo pacman -S podman 我将模拟
2025-11-17
![73、[练习]客户端进阶](https://bu.dusays.com/2025/11/15/6918233bf2a7e.png)
专有Client类型 客户端的所有交互都相当低级：我们必须手动建立一个响应通道，建立命令，将其发送到服务器，然后在响应通道上调用 recv 来获取响应。 这是大量可以抽象掉的模板代码，而这正是我们在本练习中要做的。 练习 use crate::data::{Ticket,
2025-11-15
![72、[练习]ACK模式](https://bu.dusays.com/2025/11/15/6917ddb54b6c2.png)
双向通信 在我们当前的客户端-服务器实现中，通信是单向的：从客户端到服务器。 客户端无法知道服务器是否收到了信息、执行成功还是失败。这并不理想。 为了解决这个问题，我们可以引入双向通信系统。 响应通道 我们需要一种方法让服务器向客户端发回响应。有多种方法可以做到这一点，但最简单的方法是
2025-11-15
Interior mutability（内部可变性） 分析一下Sender的send签名 impl<T> Sender<T> { pub fn send(&self, t: T) -> Result<(), SendError<T>&g
2025-11-15
Channels（通道） 到目前为止，我们生成的所有线程都相当短暂。获取输入、执行运算、返回结果、关闭。 对于我们的票据管理系统，我们希望采用不同的方式：客户端-服务器架构。 我们将有一个长期运行的服务器线程，负责管理我们的状态，即存储的票据。 然后，我们将有多个客户端线程。 每个客户
2025-11-13
作用域线程 到目前为止，我们讨论过的所有生命周期问题都有一个共同的根源：生成的线程的生命周期可能超过其父线程。我们可以通过使用作用域线程来避免这个问题。 let v = vec![1, 2, 3]; let midpoint = v.len() / 2; std::thread::scope(|s
2025-11-13
泄露数据 向生成的线程传递引用的主要问题是use-after-freebug：使用已经freed或de-allocated的指针访问数据。 如果我们使用的是堆分配的内存，我们可以通过告诉Rust永远不会回收该内存来避免这个问题：我们故意选择内存泄漏。 例如，可以使用 Rust 标准库中的 Box::
2025-11-13