The Siolin Memo

秒杀解决方案

Sun, 28 Dec 2025 11:22:52 GMT

Write your content here.

基于分布式锁解决缓存击穿

Sun, 28 Dec 2025 11:12:34 GMT

核心思想：同一时间只允许一个线程去查询数据库

缓存过期了，大家一起去抢锁
抢到锁的线程去查询数据库
没抢到锁的线程等待，然后重试
抢到锁的线程写完缓存后，其他线程可以直接从缓存读

举例：

假如线程 1 先来访问，查询缓存没有命中，那么其会获取互斥锁，然后去执行查询数据库的逻辑
线程 2 查询缓存同样没有命中，由于互斥锁已经被占用，所以其无法获取，只能执行 sleep 进行休眠
等到线程 1 释放锁后，线程 2 会被唤醒并获取锁，但是其不是直接查询数据库，而是进行递归来查询缓存

执行流程：

1. 查询 Redis
   ├─ 存在且非空 → 刷新 TTL 后返回（热数据保活）
   ├─ 存在但为空 → 返回 null（空值缓存，不刷新 TTL）
   └─ 不存在 → 继续步骤 2

2. 循环尝试获取锁（最多 100 次）
   ├─ 获取成功
   │    ├─ Double Check：再查一次 Redis
   │    │    ├─ 缓存已存在 → 刷新 TTL 后返回
   │    │    └─ 缓存仍不存在 → 查数据库并写入缓存
   │    └─ 释放锁
   └─ 获取失败
        └─ 等待 50ms 后重试

3. 重试超限（100 次）→ 直接查数据库作为兜底

代码实现：

基于逻辑过期解决缓存击穿

Sat, 27 Dec 2025 23:41:27 GMT

核心思想：缓存永不过期，但存储一个"逻辑过期时间"

查询时判断是否已逻辑过期
如果未过期，直接返回缓存数据
如果已过期，尝试获取锁，只让一个线程去重建缓存
其他线程直接返回旧数据（不等待）

执行流程：

1. 查询 Redis
   └─ 不存在 → 返回 null（说明从来没有缓存过）
2. 存在，反序列化为 RedisData
3. 判断逻辑过期时间
   └─ 未过期 → 刷新逻辑过期时间后返回（热数据保活）
4. 已过期，尝试获取锁
   ├─ 获取锁失败 → 直接返回旧数据（不等待）
   └─ 获取锁成功 → Double Check 后异步重建

[!question] 为什么缓存不存在时不去查数据库，而是直接返回 null？

因为 queryWithLogicalExpire 这个方法是专为“热点 Key”设计的，它的前提假设是缓存已经“预热”过了。

[!question] 为什么要进行 Double Check（双重检查）？

可能有其他线程已经重建了缓存
避免重复查询数据库

[!question] 为什么返回旧数据？

用户体验：比返回错误强
数据一致性：热点数据变化不会太频繁
异步更新：后台线程很快会更新缓存

完整代码：

LeetCode：375. 猜数字大小 II

Wed, 24 Dec 2025 12:12:59 GMT

如何理解“确保获胜的最小现金”？

最坏情况：当猜数字 $k$ 时，如果猜错了，那么目标数字可能在左边，也可能在右边。为了确保能赢，需要准备应对更费钱的那一边
最优策略：虽然需要应对最坏情况，但是可以通过选择「第一次、第二次...猜哪个数字」，使得该「最坏情况下的开销」尽可能小

状态定义

设 $dp[i][j]$ 为：从 $i$ 到 $j$ 这个范围内，确保能赢所需要准备的最少钱数。

目标：求 $dp[1][n]$
初始化：当 $i \ge j$ 时，$dp[i][j] = 0$，因为只有一个数字（一下子就能猜对）或者没有数字了，不用付钱。

状态转移方程

假设在区间 $[i, j]$ 猜数字 $k$（其中 $i \le k \le j$）

如果猜 $k$ 猜错了，需要支付 $k$ 元
接下来，目标数字要么在左区间 $[i, k - 1]$，要么在右区间 $[k + 1, j]$
为了确保能赢，至少需要准备 $k + max(dp[i][k - 1], dp[k + 1][j])$
同时为求最优策略，我们需要枚举所有的 $k$，取其中的最小值

状态转移公式： $$dp[i][j] = \min_{i \le k \le j} { k + \max(dp[i][k-1], dp[k+1][j]) }$$

代码实现

public int getMoneyAmount(int n) {
	// dp[i][j] 表示从 i 到 j 确保获胜的最小金额
	// n + 2是为了防止 k + 1溢出
	int[][] dp = new int[n + 2][n + 2];

	// 枚举区间长度 len，从长度 2 开始（长度 1 的开销是 0）
	for (int len = 2; len <= n; len++) {
		// 枚举左端点 i
		for (int i = 1; i <= n - len + 1; i++) {
			int j = i + len - 1; // 右端点
			
			dp[i][j] = Integer.MAX_VALUE;

			// 枚举在该区间内第一次猜哪个数字 k
			for (int k = i; k <= j; k++) {
				int res = k + Math.max(dp[i][k - 1], dp[k + 1][j]);
				dp[i][j] = Math.min(dp[i][j], res);
			}
		}
	}
	return dp[1][n];
}

LeetCode：132. 分割回文串 II

Wed, 24 Dec 2025 12:10:04 GMT

状态定义

题目要求将字符串 $s[0 \dots i]$ 切成若干段，使得每一段都是回文。

无论怎么切，最后一段 $s[j+1 \dots i]$ 必须是一个回文串。

如果我们枚举所有可能的 $j$，使得 $s[j+1 \dots i]$ 是回文。
那么剩下的问题就变成了：如何用最少的次数切割前面的部分 $s[0 \dots j]$。
而“切割 $s[0 \dots j]$ 的最少次数”正是我们之前已经计算出来的子问题 $dp[j]$。

因此设 $dp[i]$ 为：字符串前缀 $s[0...i]$ 的最少切割次数。

目标：$dp[n - 1]$

状态转移方程

假设正在处理字符串 $s[0...i]$：

如果 $s[0...i]$ 本身就是回文，那么 $dp[i] = 0$，不需要切割
否则，尝试在中间某处 $j$ 切一刀。如果 $s[j+1...i]$ 是回文，那么： $$dp[i] = \min(dp[i], dp[j] + 1)$$
如果 $s[j + 1...i]$ 不是回文，那么无需搭理，其不是合法方案

代码实现

public int minCut(String str) {
	char[] s = str.toCharArray();
	int n = s.length;

	// 预处理回文数组
	boolean[][] isPal = new boolean[n][n];
	for (int j = 0; j < n; ++j) {
		for (int i = 0; i <= j; ++i) {
			// 两端相等，且内部也是回文（或者内部为空）
			if (s[i] == s[j] && (j - i <= 2 || isPal[i + 1][j - 1])) {
				isPal[i][j] = true;
			}
		}
	}

	int[] dp = new int[n];
	for (int i = 0; i < n; ++i) {
		// 如果 0...i 本身就是回文串，不需要处理
		if (isPal[0][i]) {
			continue;
		}

		// 最坏情况下，前 i + 1 个字符需要切割 i 次
		dp[i] = i;
		for (int j = 0; j < i; ++j) {
			// 如果 j+1...i 是回文串，尝试在 j 后面切一刀
			if (isPal[j + 1][i]) {
				dp[i] = Math.min(dp[i], dp[j] + 1);
			}
		}
	}

	return dp[n - 1];
}

短信登陆

Mon, 22 Dec 2025 22:55:58 GMT

1 技术选型

为什么使用 Redis 来代替 Session？

集群挑战

Session 数据存储在 JVM 的堆内存中，在单机环境下没问题。但是在生产环境的集群部署（多台服务器跑同一个项目）下，负载均衡器（比如 Nginx）会将请求分发到不同的服务器。
如果用户在服务器 A 登陆，Session 存在 A 的内存里。该用户的下一次请求被分发到了服务器 B，B 内存中没有其 Session，那么就会认证失败
Redis 是分布式缓存系统，所有的服务器可以去同一个 Redis 集群读写数据

数据可靠性

Session 的生命周期依赖于进程，一旦后端程序崩溃或重启，那么所有用户的登录状态都会消失，那么用户的体验感极差
Redis 虽然也是基于内存，但是其运行在独立的进程中

为什么使用 Hash 存储用户信息，而不是 String？

内存效率：Redis 的 Hash 结构在字段较少时使用 ziplist 存储，内存占用极其紧凑。
操作粒度：可以利用 HSET 或 HGET 针对单个属性（如更新昵称）进行操作，而 String 则需要进行全序列化和反序列化

2 系统设计与架构

2.1 Redis 数据模型设计

验证码:
- 结构: String
- Key: login:code:{phone}
- TTL: 2 分钟
用户信息:
- 结构: Hash
- Key: login:token:{token} (Token 采用随机 UUID)
- TTL: 30 分钟

2.2 核心业务流程

发送验证码：校验手机号 -> 生成验证码 -> 存入 Redis -> 发送短信。
登录/注册：校验验证码 -> 数据库查/增用户 -> 生成随机 Token -> 脱敏处理 (UserDTO) -> 存入 Redis 并返回 Token。

3 核心代码实现

实现时要注意 StringRedisTemplate对值类型的要求。

// 核心逻辑：用户信息序列化与存储
public String login(LoginFormDTO loginForm) {
    // ... 校验逻辑 ...
    
    // 1. 生成唯一凭证（Token）
    String token = UUID.randomUUID().toString(true);
    
    // 2. 对象脱敏与类型转换
    UserDTO userDTO = BeanUtil.copyProperties(user, UserDTO.class);
    
    // 3. 将 Bean 转为 Map，并强制将所有字段转为 String
    Map<String, Object> userMap = BeanUtil.beanToMap(userDTO, new HashMap<>(),
        CopyOptions.create()
            .setIgnoreNullValue(true)
            .setFieldValueEditor((fieldName, fieldValue) -> {
                if (fieldValue == null) return null;
                return fieldValue.toString();
            }));
            
    // 4. 写入 Redis 并设置有效期
    String tokenKey = LOGIN_USER_KEY + token;
    stringRedisTemplate.opsForHash().putAll(tokenKey, userMap);
    stringRedisTemplate.expire(tokenKey, LOGIN_USER_TTL, TimeUnit.MINUTES);
    
    return token;
}

4 滚动过期

为了提升用户体验，需要实现 “滚动过期” 机制：用户在活跃期间，Token 有效期应自动续期，只有长时间无操作才会过期。

4.1 单拦截器方案的缺陷

如果仅在 LoginInterceptor（登录拦截器）中重置有效期，会存在一个严重漏洞：

拦截器通常配置为排除公开路径（如首页、商铺详情页）。
若用户登录后，长时间只浏览公开页面，拦截器不会执行，Token 将在 30 分钟后过期，导致用户在进行需要登录的操作时被意外踢出。

4.2 解决方案：双拦截器架构

引入两个拦截器，职责分离，解决上述问题：

| 拦截器 | 拦截范围 | 核心职责 | 执行顺序 | | :-------------------------- | :------------------- | :----------------------------------------------------------- | :----------- | | RefreshTokenInterceptor | 所有请求 (/**) | 1. 尝试获取请求头中的 Token。 2. 若 Token 有效，则刷新其在 Redis 中的有效期。 3. 将用户信息存入 ThreadLocal，供后续流程使用。 4. 无论是否成功，均放行。 | 第一 | | LoginInterceptor | 需要登录的路径 | 1. 检查 ThreadLocal 中是否存在用户信息。 2. 若存在，说明已登录，放行。 3. 若不存在，则拦截并返回“未登录”状态码（401）。 | 第二 |

拦截器流程：

RefreshTokenInterceptor 核心逻辑：

public boolean preHandle(HttpServletRequest request, ...) {
    // 1. 获取请求头中的 token
    String token = request.getHeader("authorization");
    if (StrUtil.isBlank(token)) {
        // 无 token，直接放行，由 LoginInterceptor 决定是否拦截
        return true;
    }
    
    // 2. 基于 token 从 Redis 获取用户信息
    String tokenKey = getTokenCacheKey(token);
    Map<Object, Object> userMap = redisTemplate.opsForHash().entries(tokenKey);
    if (userMap.isEmpty()) {
        // token 无效，直接放行
        return true;
    }
    
    // 3. 将 Hash 数据转换回 UserDTO 对象
    UserDTO userDTO = BeanUtil.fillBeanWithMap(userMap, new UserDTO(), false);
    // 4. 保存用户信息到 ThreadLocal
    UserHolder.saveUser(userDTO);
    // 5. 刷新 token 有效期（实现滚动过期）
    redisTemplate.expire(tokenKey, LOGIN_USER_TTL, TimeUnit.MINUTES);
    return true;
}

[!CAUTION]

在拦截器的 afterCompletion方法中，必须调用 UserHolder.removeUser()。这是因为 Tomcat 线程池会复用线程，如果不手动清理，会导致 ThreadLocal 中的数据被错误带入下一个请求，并造成内存泄漏。

LeetCode：1039.多边形三角剖分的最低得分

Mon, 22 Dec 2025 12:30:37 GMT

题目：1039.多边形三角剖分的最低得分

核心逻辑：从一条边开始“切分”

假设有一个凸 $n$ 边形，顶点数值存在数组 $A$ 中。我们的目标是将它剖分成 $n-2$ 个三角形，使得所有三角形顶点的乘积之和最小。

可以想象手中拿着一个凸多边形，每次切去一个角（一个三角形），直到最后只剩一个三角形。因此与其纠结「第一次切去哪个三角形」，不如考虑「最后保留哪个三角形」。

对于任何一个由顶点 $i$ 到顶点 $j$ 构成的多边形（记为区间 $[i, j]$），我们可以固定底边（连接顶点 $i$ 和 $j$ 的边）。在最终的剖分方案中，这条底边一定属于某一个三角形。

假设这个三角形的第三个顶点是 $k$（其中 $k$ 在 $i$ 和 $j$ 之间），那么这个三角形 $(i, k, j)$ 就把原来的多边形切成了三部分：

左边： 由顶点 $i$ 到 $k$ 构成的多边形。
中间： 三角形 $(i, k, j)$ 本身。
右边： 由顶点 $k$ 到 $j$ 构成的多边形。

定义状态与转移方程

状态定义：$dp[i][j]$ 表示从顶点 $i$ 到顶点 $j$ 连成的子多边形进行三角剖分后的最低得分。
转移方程：我们需要枚举 $i$ 和 $j$ 之间所有的可能顶点 $k$： $$dp[i][j] = \min_{i < k < j} { dp[i][k] + dp[k][j] + A[i] \times A[k] \times A[j] }$$
边界条件：
- 如果 $i$ 和 $j$ 之间没有顶点（即 $j - i < 2$），无法形成三角形，$dp[i][j] = 0$。
- 当 $j - i = 2$ 时，$dp[i][j]$ 就是唯一的那个三角形 $A[i] \times A[i+1] \times A[j]$。

遍历顺序

观察方程，$dp[i][j]$ 依赖于 $dp[i][k]$ 和 $dp[k][j]$：

$dp[i][k]$：在 $dp[i][j]$ 的左侧（同一行）。
$dp[k][j]$：在 $dp[i][j]$ 的下方（不同行，$k > i$）。

因此，遍历顺序与516.最长回文子序列一致：$i$ 从大到小（从下往上），$j$ 从小到大（从左往右）。

代码实现

public int minScoreTriangulation(int[] values) {
    int n = values.length;
    int[][] dp = new int[n][n];

    // i 从下往上遍历
    for (int i = n - 3; i >= 0; i--) {
        // j 从左往右遍历，且 j 与 i 之间至少要隔一个点
        for (int j = i + 2; j < n; j++) {
            // 初始化为一个较大值
            int minRes = Integer.MAX_VALUE;
            // 枚举中间顶点 k
            for (int k = i + 1; k < j; k++) {
                int score = dp[i][k] + dp[k][j] + values[i] * values[k] * values[j];
                minRes = Math.min(minRes, score);
            }
            dp[i][j] = minRes;
        }
    }
    return dp[0][n - 1];
}

LeetCode：516.最长回文子序列

Mon, 22 Dec 2025 12:28:05 GMT

题目：516. 最长回文子序列

1 核心逻辑

回文序列的定义是正读反读都一样。对于一个子串 $s[i \dots j]$，我们要找它的最长回文子序列，关键看它的两个端点字符 $s[i]$ 和 $s[j]$：

情况 A：$s[i] == s[j]$，如果首尾字符相等，那么这两个字符一定可以作为回文序列的最外层。

转移：我们只需要知道中间部分 $s[i+1 \dots j-1]$ 的最长回文长度，然后加上这两个字符。
方程：$dp[i][j] = dp[i+1][j-1] + 2$

情况 B：$s[i] \ne s[j]$，如果首尾不相等，说明它们两个不可能同时出现在同一个回文子序列的最外层。

转移：我们要么放弃 $s[i]$，看 $s[i+1 \dots j]$ 的结果；要么放弃 $s[j]$，看 $s[i \dots j-1]$ 的结果。
方程：$dp[i][j] = \max(dp[i+1][j], dp[i][j-1])$

2 状态定义与边界

$dp[i][j]$ 表示字符串 $s$ 从下标 $i$ 到下标 $j$ 范围内的最长回文子序列的长度。

基础边界：

当 $i == j$ 时，单个字符本身就是回文，长度为 $1$。即 $dp[i][i] = 1$。
当 $i > j$ 时，区间不存在，长度为 $0$。

3 遍历顺序

遍历顺序：观察状态转移方程，可以看到 $dp[i][j]$ 依赖于

左下方： $dp[i + 1][j - 1]$
下方：$dp[i + 1][j]$
左方：$dp[i][j + 1]$

因此遍历顺序：

$i$ 从大到小（从 $n - 1$ 倒退到 $0$）
$j$ 从小到大（从 $i + 1$ 前进到 $n - 1$）

4 代码实现

public int longestPalindromeSubseq(String s) {
	char[] str = s.toCharArray();
	int n = str.length;
	int[][] dp = new int[n][n];
	
	// 初始化：单个字符都是回文串
	for (int i = 0; i < n; ++i) {
		dp[i][i] = 1;
	}
	
	// 从下往上遍历i
	for (int i = n - 1; i >= 0; --i) {
		// 从左往右遍历j
		for (int j = i + 1; j < n; ++j) {
			if (str[i] == str[j]) {
				// 首尾相同
				dp[i][j] = dp[i + 1][j - 1] + 2;
			} else {
				// 首尾不同
				dp[i][j] = Math.max(dp[i + 1][j], dp[i][j - 1]);
			}
		}
	}

	return dp[0][n - 1];
}

5 空间优化

可以看到，$dp[i][j]$ 只依赖于「本行左侧」和「下一行」的值，因此二维矩阵可以压缩成一维数组。

public int longestPalindromeSubseq(String s) {
	char[] str = s.toCharArray();
	int n = str.length;
	int[] dp = new int[n];
	Arrays.fill(dp, 1);

	for (int i = n - 1; i >= 0; --i) {
		int pre = 0; // 相当于dp[i + 1][j - 1]
		for (int j = i + 1; j < n; ++j) {
			int tmp = dp[j];
			if (str[i] == str[j]) {
				dp[j] = pre + 2;
			} else {
				dp[j] = Math.max(dp[j - 1], dp[j]);
			}
			pre = tmp;
		}
	}

	return dp[n - 1];
}

LeetCode：3573.买卖股票的最佳时机 V

Sun, 21 Dec 2025 17:51:57 GMT

状态机建模

在 188.买卖股票的最佳时机 IV 的 $k$ 次交易中，我们每一轮交易只有“持有”和“不持有”两种状态。但在这一题里，当我们正处于一笔交易中时，身份有两种可能：

正向持有：先买了，手里拿着股票等卖。
反向持有：先卖了，手里攥着钱等跌了买回来。
空仓：手里既没股票也没欠钱，准备开始第 $j$ 次交易。

所以，对于第 $j$ 次交易（$1 \le j \le k$），我们定义三个变量：

buy[j]：第 $j$ 次交易中，处于买入后的状态（正向持股）。
shorting[j]：第 $j$ 次交易中，处于卖出后的状态（反向做空）。
sell[j]：第 $j$ 次交易已完成的状态（无论是普通还是做空）。

状态转移方程

当处于第 $j$ 次交易中，当天的股票价格为 $P$：

正向持有（buy[j]）
- 来源 A：昨天就正向持有
- 来源 B：昨天结束时处于空仓状态，今天买入
- $buy[j] = max(buy[j], sell[j = 1] - p)$
反向持有（shorting[j]）
- 来源 A：昨天就反向持有
- 来源 B：昨天 结束时处于空仓状态，今天卖出
- $shorting[j] = max(shorting[j], sell[j - 1] + p)$
空仓（sell[j]）
- 来源 A：昨天 结束时处于空仓
- 来源 B：昨天正向持有，今天卖出
- 来源 C：昨天反向持有，今天买入
- $sell[j] = max(sell[j], buy[j] + p, shorting[j] - p)$

代码实现

因为题目中规定“你不能在已经进行买入或卖出操作的同一天再次进行买入或卖出操作”，所以这里使用倒序遍历会更方便。

public long maximumProfit(int[] prices, int k) {
	long[] buy = new long[k + 1];
	long[] shorting = new long[k + 1];
	long[] sell = new long[k + 1];

	Arrays.fill(buy, Long.MIN_VALUE / 2);
	Arrays.fill(shorting, Long.MIN_VALUE / 2);

	for (int p : prices) {
		for (int j = k; j >= 1; j--) {
			// 此时的 buy[j] 和 shorting[j] 还是昨天的状态
			sell[j] = Math.max(sell[j], Math.max(buy[j] + p, shorting[j] - p));

			// 因为是倒序，此时的 sell[j-1] 还没有被今天的新价格更新过
			buy[j] = Math.max(buy[j], sell[j - 1] - p);
			shorting[j] = Math.max(shorting[j], sell[j - 1] + p);
		}
	}
	return sell[k];
}

LeetCode：309.买卖股票的最佳时机含冷冻期

Sun, 21 Dec 2025 15:41:16 GMT

题目：309. 买卖股票的最佳时机含冷冻期

状态机建模

在 188.买卖股票的最佳时机 IV中，我们只有两个大类：买（持有）和卖（不持有）。

但在这一题中，由于冷冻期的存在，“不持有”被分成了两种完全不同的情况：

状态 0：持有股票
状态 1：刚刚卖出，处于冷冻期
- 特点：这个状态是卖出动作激发的，下一天强制不能买。
状态 2：不持有股票，且不在冷冻期
- 特点：这个状态意味着你已经休息够了，随时可以买入。

状态转移方程

设 $f[i][s]$ 为第 $i$ 天结束时，处于状态 $s$ 的最大利润。

状态 0：今天结束后我“手里有货”

昨天就有货，今天歇着：$f[i-1][0]$
昨天没货且不在冷冻期（状态 2），今天刚买入：$f[i-1][2] - price$
方程： $f[i][0] = \max(f[i-1][0], f[i-1][2] - price)$

状态 1：今天结束后我“刚刚卖出”

唯一来源：昨天我手里有货（状态 0），今天我把它卖了：$f[i-1][0] + price$
方程： $f[i][1] = f[i-1][0] + price$

状态 2：今天结束后我“两手空空且能买”

昨天就是这个状态，今天继续歇着：$f[i-1][2]$
昨天我是刚卖完的冷冻期（状态 1），今天冷冻期解除了：$f[i-1][1]$
方程： $f[i][2] = \max(f[i-1][2], f[i-1][1])$

Question：「刚刚卖出」和「处于冷冻期」不应该是两种状态吗？即昨天刚刚卖出，今天处于冷冻期

这里对状态的定义为：第 $i$ 天结束后所处的状态，而不是所谓的“第 $i$ 天所处的状态”。

代码实现

我们可以发现，第 $i$ 天的状态只取决于第 $i - 1$ 天，因此可以直接用三个变量来维护。

public int maxProfit(int[] prices) {	
	int hold = -prices[0];  // 状态0
	int sold = 0;           // 状态1
	int rest = 0;           // 状态2

	for (int i = 1; i < prices.length; ++i) {
		int nextHold = Math.max(hold, rest - prices[i]);
		int nextSold = hold + prices[i];
		int nextRest = Math.max(rest, sold);

		hold = nextHold;
		sold = nextSold;
		rest = nextRest;
	}

	// 最大利润一定处于“手里没货”的状态
	return Math.max(sold, rest);
}

LeetCode：188.买卖股票的最佳时机 IV

Sun, 21 Dec 2025 14:47:02 GMT

题目：188.买卖股票的最佳时机 IV

状态机建模

在 2786.访问数组中的位置使分数最大中，只有奇/偶两种状态；而在这一题中，我们最多允许 $k$ 次交易，那么在任意一天，我们可能处于的状态有：

第 1 次持有（Buy 1）
第 1 次卖出（Sell 1）
第 2 次持有（Buy 2）
第 2 次卖出（Sell 2）
...
第 $k$ 次持有（Buy $k$）
第 $k$ 次卖出（Sell $k$）

总共有 $2k$ 个状态。

状态转移方程

设 $buy[j]$ 表示第 $j$ 次持有股票时的最大利润，$sell[j]$ 表示第 $j$ 次卖出股票后的最大利润。

对于当天的股价 $P$：

第 $j$ 次持有（$buy[i]$）我可能今天继续持有昨天的股票，或者今天刚刚买入（前提是第 $j - 1$ 次交易已经卖出）： $$buy[j] = \max(buy[j], sell[j-1] - P)$$
第 $j$ 次卖（$sell[j]$）我可能今天继续空仓，或者今天刚刚卖出（前提是第 $j$ 次买入的股票还在手里）： $$sell[j] = \max(sell[j], buy[j] + P)$$

代码实现

初始化：

$buy$ 数组应该初始化最小值，因为都没开盘就持有股票，这是非法的，需要过滤掉
$sell$ 数组应该初始化为 0，因为还没开始交易时利润为 0

public int maxProfit(int k, int[] prices) {
	if (prices.length == 0) return 0;

	// buy[j] 表示第 j + 1 次买入后的最大利润
	int[] buy = new int[k];
	// sell[j] 表示第 j + 1 次售出后的最大利润
	int[] sell = new int[k];

	Arrays.fill(buy, Integer.MIN_VALUE);

	for (int p : prices) {
		for (int j = 0; j < k; ++j) {
			int preSell = j == 0 ? 0 : sell[j - 1];
			buy[j] = Math.max(buy[j], preSell - p);
			sell[j] = Math.max(sell[j], buy[j] + p);
		}
	}

	return sell[k - 1];
}

Leetcode：2786.访问数组中的位置使分数最大

Sun, 21 Dec 2025 12:52:00 GMT

题目：2786.访问数组中的位置使分数最大

记忆化搜索

$dfs(i, j)$表示：当前考虑到下标 $i$，且上一个选中的数奇偶性为 $j$ 时，从 $i$ 到 $n - 1$ 能获得的最大额外分数。

此时，对于 $v = nums[i]$，它的奇偶性为 $curr = v \bmod 2$：

$curr == j$（奇偶性相同）
- 选：既然奇偶性相同，不需要减 $x$。那么选了肯定比不选好，因为 $v > 0$ 且没有改变后续的奇偶性
- 决策：$v + dfs(i + 1, j)$
$curr \ne j$（奇偶性不同）
- 不选：维持现状，继续往后看。结果为 $dfs(i + 1, j)$
- 选：获得了 $v$ 的分数，但是要扣除 $x$，且状态改变了，从此往后"上一个数"的奇偶性变成了 $curr$（即 $j \oplus 1$）
- 决策：$v - x + dfs(i + 1, j \oplus 1)$

所以整体的递归思路应该是：

$$dfs(i, j) = \begin{cases} v + dfs(i+1, j) & \text{if } (v \bmod 2 == j) \ \max(dfs(i+1, j), v - x + dfs(i+1, j \oplus 1)) & \text{if } (v \bmod 2 \ne j) \end{cases}$$

int[] nums;
long[][] memo;
int x;
public long maxScore(int[] nums, int x) {
	this.nums = nums;
	this.x = x;
	int n = nums.length;
	memo = new long[n][2];
	for (long[] row : memo) {
		Arrays.fill(row, -1);
	}
	return dfs(0, nums[0] % 2);
}

private long dfs(int i, int j) {
	if (i == nums.length) {
		return 0;
	}
	if (memo[i][j] != -1) {
		return memo[i][j];
	}

	int curr = nums[i] & 1;
	if (curr == j) {
		// 奇偶性相同必选
		return memo[i][j] = dfs(i + 1, j) + nums[i];
	} else {
		// 奇偶性不同，选或不选
		return memo[i][j] = Math.max(dfs(i + 1, j),  nums[i] - x + dfs(i + 1, j ^ 1));
	}
}

递推

理解了上面的状态转移后，递推就非常简单了：

$f[i][0]$ 代表在 $[i, n - 1]$ 中以偶数开头的子序列的最大得分；
$f[i][1]$ 代表在 $[i, n - 1]$ 中以奇数开头的子序列的最大得分。

public long maxScore(int[] nums, int x) {
	int n = nums.length;
	long[][] f = new long[n + 1][2];

	for (int i = n - 1; i >= 0; --i) {
		int v = nums[i];
		int r = v & 1;
		// 相同必选
		f[i][r] = v + f[i + 1][r];
		// 不同，选或不选
		f[i][r ^ 1] = Math.max(f[i + 1][r ^ 1], f[i + 1][r] + v - x);
    }

	return f[0][nums[0] % 2];
}

迭代 DP

倒推

在递推中，我们只会访问 $f[i + 1]$ 的值，所以没有必要全部维护。

public long maxScore(int[] nums, int x) {
	long[] f = new long[2];
	for (int i = nums.length - 1; i >= 0; --i) {
		int v = nums[i];
		int r = v & 1;
		// 不同，选或不选
		f[r ^ 1] = Math.max(f[r ^ 1], f[r] + v - x);
		// 相同必选
		f[r] = v + f[r];
	}
	return f[nums[0] % 2];
}

注意：这里的更新顺序不能改变，即必须先更新 $f[r \oplus 1]$ 后更新 $f[r]$（也可以用一个临时变量 $tmp$ 先占位 $f[r]$）。

正推

由于第一个数必须选，因此正推的逻辑可能会更清晰。

正推逻辑：当前数 $v$ 的奇偶性为 $r$

$f[0]$ 代表以偶数结尾的子序列最大得分，$f[1]$ 代表以奇数结尾的子序列最大得分
只能更新 $f[r]$，因为选了数 $v$ 后，结尾奇偶性一定为 $r$
$f[r \oplus 1]$ 保持不变，因为当前数 $v$ 无法改变以异号结尾的子序列的最大分数

状态转移方程： $$f[r] = Math.max(f[r] + v, f[r \oplus 1] + v - x)$$

public long maxScore(int[] nums, int x) {
	long[] f = new long[2];
	Arrays.fill(f, Long.MIN_VALUE / 2); // 防止减x溢出
	f[nums[0] & 1] = nums[0];
	for (int i = 1; i < nums.length; ++i) {
		int v = nums[i];
		int r = v & 1;
		f[r] = Math.max(f[r] + v, f[r ^ 1] - x + v);
	}
	return Math.max(f[0], f[1]);
}

参考

灵茶山艾府：教你一步步思考 DP：从记忆化搜索到递推到空间优化！（Python/Java/C++/Go）

英语学习：Anki+查拉查词+HypperTTS

Fri, 19 Dec 2025 23:37:44 GMT

传统App痛点

因为存在学习英语的需求，于是去体验了一些市面上传统的背单词APP。不可否认，诸如百词斩、墨墨背单词等App都存在各自的优点，但是长期使用后，发现存在一些实在难以忍受的痛点：

脱离语境：App里的例句往往是预设好的，但是在阅读技术文档或看美剧时遇到的词，那种“当下”的语境感是App无法提供的。
被动输入：这种学习更像是完成任务，而不是为了解决问题。
算法的“黑盒”：对于那些没有记忆而知识简单重复的复习策略，无法掌控真正的复习节奏。有些简单或偏僻的词反复出现浪费时间，而真正优美和常用的词却无法通过自定义权重来加练。

新方案

沙拉查词

经过一段时间的探索后，总结出了一套Anki+沙拉查词+HyperTTS的学习流。

沙拉查词是一个浏览器插件，当阅读网页或PDF时，用来查询指定的单词。

沙拉查词集成了Anki Connect自动制卡，它可以直接抓取当前的上下文（Context）。这个单词在什么文章里、哪一句话出现的，会被原封不动地带入卡片。这种“强关联”是记忆的捷径。

Anki

将卡片导入Anki后，我们可以在其中高度自定义自己的卡片模版和样式。

以下是卡片展示效果：

卡片正面：红色的为我们要记忆的生词，可以播放该单词的读音

卡片背面：

以下是卡片模版（天高任鸟飞，可以高度定制）：

正面：

<div class="card-container">
    <div class="context-sentence">{{Context}}</div>
    
    {{#Audio}}{{Audio}}{{/Audio}}
</div>

<script>
    // 获取上下文和单词
    var contextDiv = document.querySelector('.context-sentence');
    var targetWord = "{{Text}}".trim();

    if (contextDiv && targetWord) {
        var text = contextDiv.innerHTML;
        // 创建正则，忽略大小写 (gi)
        var regex = new RegExp("(" + targetWord + ")", "gi");
        // 替换为带高亮的 span
        var newText = text.replace(regex, '<span class="highlight-word">$1</span>');
        contextDiv.innerHTML = newText;
    }
</script>

背面：

{{FrontSide}}

<hr id="answer">

<div class="back-container">
    
    {{#Translation}}
    <div class="sentence-translation">{{Translation}}</div>
    {{/Translation}}

    <div class="target-word-header">{{Text}}</div>

    {{#Note}}
    <div class="note-section">
        {{Note}}
    </div>
    {{/Note}}

    {{#Title}}
    <div class="source-section">
        {{#Favicon}}<img src="{{Favicon}}" class="favicon"/>{{/Favicon}}
        <a href="{{Url}}">{{Title}}</a>
    </div>
    {{/Title}}

</div>

样式：

.card {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
  font-size: 20px;
  line-height: 1.6;
  color: #333;
  background-color: #f7f7f7;
  text-align: left;
  padding: 20px;
}

/* 正面：上下文英文句子 */
.context-sentence {
  font-size: 1.2em;
  color: #2c3e50;
  font-weight: 500;
  margin-bottom: 5px;
}

/* 分割线 */
hr {
  border: 0;
  height: 1px;
  background: #ddd;
  margin: 15px 0;
}

/* 背面：句子的中文翻译 */
.sentence-translation {
  font-size: 1em;
  color: #666;
  font-style: italic; /* 用斜体区分翻译 */
  margin-bottom: 25px;
  padding-bottom: 15px;
  border-bottom: 1px dashed #e0e0e0;
}

/* 背面：目标单词标题 */
.target-word-header {
  font-size: 1.5em;
  font-weight: bold;
  color: #e67e22; /* 醒目的橙色 */
  margin-bottom: 10px;
}

/* 背面：笔记区域 (释义与用法) */
.note-section {
  font-size: 1em;
  color: #333;
  background-color: #fff;
  padding: 15px;
  border-radius: 8px;
  box-shadow: 0 2px 5px rgba(0,0,0,0.05); /* 轻微阴影，像一张卡片 */
  border-left: 5px solid #5caf9e; /* 左侧绿色装饰条 */
}

/* 底部来源信息 */
.source-section {
  margin-top: 30px;
  font-size: 0.75em;
  text-align: right;
  opacity: 0.6;
}

.source-section a {
  color: #7f8c8d;
  text-decoration: none;
}

.favicon {
  height: 16px;
  width: 16px;
  vertical-align: middle;
  margin-right: 5px;
}

/* 移动端适配 */
@media (max-width: 600px) {
    .card { padding: 15px; font-size: 18px; }
    .target-word-header { font-size: 1.3em; }
}

.highlight-word {
    color: #c0392b; /* 红色 */
    font-weight: bold;
}

HyperTTS

没有声音的单词是没有灵魂的，而在Anki的广袤插件市场中，HyperTTS可以弥补这一点。

HyperTTS可以调用Azure和Google等神经网络自动生成语音，但是免费的一些官方语音如剑桥也够用了。

以下是一些配置：

Source/Source Field：Text （要生成语音的字段）
Target/Target Field：Audio（语音文件的目标字段）
Voice Selection/Voice：Cambridge（可以自由更换）

阿里云OSS

Fri, 19 Dec 2025 22:57:55 GMT

WebSocket

Fri, 19 Dec 2025 22:50:10 GMT

HTTP 缺陷

在 WebSocket 出现之前，Web 世界主要靠 HTTP 协议。HTTP 有一个致命的性格缺陷：“被动”。

HTTP 的规则：请求 -> 响应。
- 前端：如果不问，后端就不说。
- 后端：我有新数据（新订单），但我联系不上前端，我只能干着急。

假如没有 WebSocket，怎么实现“新订单提醒”？

只能使用笨办法——轮询 (Polling)：

短轮询 (Short Polling)：
- 商家后台每隔 2 秒发一个 HTTP 请求问后端：“有新订单吗？”
- 后端：“没有。”
- 2秒后：“有新订单吗？”
- 后端：“没有。”
- 缺点：99% 的请求都是废话，浪费流量，浪费服务器资源，而且有延迟（运气不好要等2秒）。
长轮询 (Long Polling)：
- 商家后台问：“有新订单吗？”
- 后端不立即回复，而是把请求“挂起”（hold住）。哪怕等 20 秒，一旦有新订单，立刻返回；或者超时了再返回“没有”。
- 缺点：虽然比短轮询好，但依然建立在 HTTP 之上，连接频繁断开重连，Header 头部信息冗余大。

而 WebSocket 实现了 全双工通信 ——服务端可以主动给客户端发消息。

WebSocket 工作机制

WebSocket 并不是完全脱离 HTTP 的，它更像是 HTTP 的一种“升级”。

握手

WebSocket 的连接建立，必须依靠 HTTP 来开路。

客户端发起请求：看起来像普通的 HTTP GET 请求，但 Header 里带了特殊的暗号：

GET /ws/clientId HTTP/1.1
Connection: Upgrade
Upgrade: websocket

翻译：“大哥（服务器），我想把协议升级一下，咱们别用 HTTP 了，改用 WebSocket 吧？”

服务器响应：如果服务器支持，会返回状态码 101：

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket

翻译：“准了！以后这条连接就是 WebSocket 的天下了。”

全双工通信

一旦握手成功，HTTP 协议就退场了。这条 TCP 连接不会断开，双方可以通过这条“专线”自由地互相发送数据帧。

后端有新订单 -> 直接推给前端。
前端有操作 -> 直接推给后端。
低开销：不需要像 HTTP 那样每次都带一大堆 Header（Cookie, User-Agent等），数据包很轻量。

心跳保活

网络环境是很复杂的（中间有 Nginx、防火墙、路由器）。如果一条连接很久没数据传输，这些中间设备可能会以为连接“死”了，强行切断它。

Ping/Pong：客户端或服务端会定时发一个很小的数据包（Ping），另一方回复（Pong），以此证明“我还活着，别断我网”。

MD5加密

Fri, 19 Dec 2025 22:47:40 GMT

核心特性

MD5 核心特性：

压缩性：无论明文长度是多少，输出的 MD5 值长度永远固定（32 位十六进制字符串）
不可逆性：可以通过明文算出 MD5，但是无法从 MD5 反向推导出明文
抗碰撞性：不同的明文生成的 MD5 绝不相同。只要是原始数据改动了一个字节，生成的 MD5 就会天差地别（雪崩效应）

应用场景

在「苍穹外卖」中，MD5 主要用于保护密码安全：

用户注册/新增员工：
- 将前端传过来的明文密码，经过 MD5 加密后再存储到数据库
用户登陆
- 将前端传过来的明文密码进行 MD5 加密
- 将加密后的结果与数据库对比

缺陷

单纯的MD5 已经不再安全，虽然其不可逆，但是黑客可以使用 彩虹表进行暴力碰撞。

彩虹表：预先计算好常见密码的 MD5 值并存成一张大表
拿到数据库里的 MD5 后，通过查表就可以反推出明文（利用「抗碰撞性」）

优化

为了破解彩虹表，可以给密码“加盐”：

用户密码是 123456。
系统随机生成一个字符串（盐值，比如 &*%#_!22）。
对 123456 + &*%#_!22 的组合进行 MD5 加密。
即使两个用户的密码都是 123456，因为盐值不同，数据库里的乱码也完全不同。这让彩虹表彻底失效

Nginx

Fri, 19 Dec 2025 22:28:27 GMT

基础命令

# 启动nginx（使用默认的配置文件）
nginx

# 使用指定项目的配置文件和目录
# 都是相对于当前项目根目录的
nginx -p $(pwd) -c conf/nginx.conf
# -p 静态文件目录
# -c 配置文件

# 查看当前的nginx进程
ps -ef|grep nginx

# 查看80端口的占用情况
lsof -i:80

# 停止或重启
nginx -s [signal]
# quit: 优雅停止
# stop：立即停止
# reload: 重载配置文件
# reopen: 重新打开日志文件

配置文件

nginx的进程模型：

master 进程只有一个，负责读取和验证配置文件，以及管理 worker 进程
worker 进程就是工作进程，负责处理具体的请求

课程资料中给的是以 nginx.exe的形式给出的，其配置目录为conf，里面有默认的静态站点页面：

在Mac上可以通过Window Stable来运行.exe文件，也可以使用 nginx -p $(pwd) -c conf/nginx.conf命令，用自己的nginx来运行该配置：

可以看到，此时nginx的master进程，加载的就是资料中给的配置文件。

反向代理

场景：
- 前端网页运行在浏览器里，访问的是 http://localhost/api/employee/login（默认80端口）。
- 后端代码运行在 IDEA 中，监听的是 8080 端口
问题：前端发送的请求，后端是如何接收到的？
Nginx：将对请求地址的访问转发给指定地址（后端服务器）

server {
	listen       80;
	server_name  localhost;

	# 反向代理,处理管理端发送的请求
	location /api/ {
		proxy_pass   http://localhost:8080/admin/;
	}
}

配置详解（nginx.conf）：

监听（listen 80）：nginx 监听访问地址为 localhost 的 80 端口（浏览器的请求）
反向代理（prxy_pass）：将监听到以 /api/ 开头的请求路径后，转发给指定的地址 http://localhost:8080/admin/

反向代理的好处：

提高访问速度：nginx 本身可以缓存数据，如果访问同一接口，nginx 可以直接返回已缓存的数据，不需要再去访问服务端
负载均衡：把大量的请求按照指定的方式分配给集群中的每台服务器
保证后端服务安全：服务端地址一般不会泄漏，所以不能使用浏览器直接访问

负载均衡

如果服务器以集群的方式进行部署，那么 nginx 在转发请求到服务器时需要进行负载均衡。

通过 upstream 来配置后端服务器组：

upstream webservers{
    server 192.168.100.128:8080;
    server 192.168.100.129:8080;
}
server{
    listen 80;
    server_name localhost;
    
    location /api/{
        proxy_pass http://webservers/admin;#负载均衡
    }
}

负载均衡有很多策略，但是对于只有一个服务器的该项目，默认的「轮询」已经足够。

参考

Nginx学习：【GeekHour】30分钟Nginx入门教程

JWT

Fri, 19 Dec 2025 22:21:15 GMT

应用场景

互联网服务中最常见的功能便是用户认证，比如登陆了某个网站后下次就可以自动登录。

由于 HTTP 是无状态协议，因此使用 cookie 来进行用户认证。

1、用户向服务器发送用户名和密码。

2、服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。

3、服务器向用户返回一个 session_id，写入用户的 Cookie。

4、用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。

5、服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

但是问题在于，这里的 session 信息保存在哪里？

保存在持久层（数据库），服务收到请求后，向持久层请求数据。
- 缺点：工程量大
保存在客户端，每次请求时发给 session

JWT，即 Json Web Token 就是第二种方案。

现实应用

传统的导入和配置不再赘述，主要讲一些扩展。

缺陷

如果黑客截获了 JWT，那么其就可以在令牌过期前冒充用户，进行一切合法的操作。

这也是所有基于 Token 机制所面临的共同安全挑战。

为什么 JWT 泄漏后可以被冒充？

无状态性
- JWT 被生成后，后端服务器不会在内存或 Redis 中存储其状态
- 后端只通过 Token 的签名来验证其是否有效、过期，而无法知道其是否泄漏或被调用
自包含性
- JWT 内部包含了用户信息（比如苍穹外卖中的 user_id）
- 黑客只需要将 JWT 包含在 HTTP 请求头中，拦截器看到 Token 是合法的，就会认为这个请求是用户 user_id 发出的

对于基于 Session 的认证，服务器会在内存或 Redis 中存储 Session ID。如果用户密码泄漏或检测到异地登录，服务器就可以直接删除这个 Session ID，用户就会立即掉线。

但 JWT 是无状态的，即：

无法注销：JWT 的注销只是前端删除了本地存储的 Token。Token 本身依然有效，直到过期
无法吊销：在 Token 有效期内，即使服务器发现该 Token 被盗，也无法立刻使其实效

3.2 补救

对于 Web 应用，可以采取以下几种措施来降低 JWT 泄漏的风险：

设置极短的有效期：如果用户体验要求高，可以引入 Refresh Token 机制
- Access Token 设置 1 小时有效
- 额外签发一个 Refresh Token，设置 7 天有效，用于在 Access Token 过期后安静的换取新的 Access Token，减少用户登录的次数
实现 Token 黑名单机制
- 做法：将指定用户的 JWT ID 存入 Redis 黑名单中，并设置黑名单过期时间与 JWT 有效期一致
- 校验流程：拦截器在校验 JWT 签名和有效期时，会额外查询其 ID 是否包含在 Redis 黑名单中
- 如果 Token 被加入黑名单，其就无法在请求服务
增强传输安全性（HTTPS）
- 使用更安全的 HTTPS 进行加密传输，降低了 JWT 被截获的风险

微信小程序登陆

Fri, 19 Dec 2025 22:11:13 GMT

code（临时登陆凭证）

为什么需要 code？

因为前端是不可信的，其可能伪造大量的假用户来占用服务端资源。

code 是如何生成的？

当用户进入小程序后并点击登陆后，小程序会调用 wx.login()，向微信客户端内核发起请求，表示“我要登陆”
微信客户端内核收到请求后，会进行一次加密网络通信，将用户信息发送到微信服务端
微信服务端生成一个 code（包含了加密信息和时效性）
微信客户端将 code 返回给小程序，小程序才能去请求服务端

登陆凭证校验

后端收到 login 请求并拿到 code 后，其会调用 auth.code2Session 接口去请求微信接口服务，返回 session_key 和 openid。

session_key：会话密钥。如果后续需要用户的其他信息（比如电话号码），微信会加密传输，后端需要用该密钥解密
openid：用户的唯一身份证。只要是同一个微信号，那么后端从微信接口服务获得的 openid 都会是同一个，因此后续登陆时可以直接依靠 openid 来匹配数据

自定义登陆态

自定义登录态是指开发者根据业务需求，自行设计并管理的一套身份凭证机制。

在用户登录后，服务器端生成一个标识用户身份的凭证，并将其发送到客户端进行存储，客户端在后续每次请求时携带此凭证，服务器端据此识别用户身份并维持会话。

在苍穹外卖中，这里的「自定义登录态」就是指JWT。

为什么不直接把 openid 返回给前端？

因为 openid 和 session_key 代表了用户的登录态数据，其一旦泄漏，黑客就可以直接冒充用户为所欲为。

「苍穹外卖」缓存优化

Fri, 19 Dec 2025 21:23:05 GMT

在原版教程中，存在两处缓存的应用：

套餐分类：使用Spring Cache进行缓存，底层实现为Redis
店铺状态：使用Redis的String类型缓存

该项目还有一些优化点。

| 数据类型 | 缓存策略 | 理由 | | -------- | -------- | ------------------ | | 购物车 | Hash | 高频读写 | | 菜品分类 | Hash | 高频查询 | | 套餐分类 | Hash | 高频查询 | | 店铺状态 | String | 高频查询 | | 分类列表 | Hash | 极少变更，高频查询 | | 套餐详情 | Hash | 包含关联数据 | | 地址薄 | Hash | 用户独立数据 |

购物车

购物车属于典型的**“高频读写、临时性强“**的数据，其临时性很强，非常适合迁移到Redis中而不是数据库表里。

结构设计：

数据结构: Hash
Key格式: shoppingCart_{userId}
Field格式: dish_{dishId}_{flavor} 或 setmeal_{setmealId}
Value: ShoppingCart对象
过期时间: 1小时

为什么使用Redis而不是Spring Cache？

与Spring Cache相比，Redis的显著优势在于其对粒度的精细控制，这也是购物车缓存不使用Spring Cache的核心原因：

Spring Cahce的工作模式是全量/粗粒度的，如果我仅仅在购物车中增加一份米饭，那么整个购物车的缓存都会失效。也就是说，为了修改一个小数据，浪费了其他未改动数据的序列化和传输开销
Redis的工作模式是增量/细粒度的，同样是在购物车汇总增加一份米饭，在使用Redis Hash结构的情况下，我只需要清除该米饭的缓存（在查询时懒加载），而其他商品的缓存依然继续使用

后面的缓存基本上都是使用Redis Hash，主要是因为其可以对单一字段进行操作。

既然已经在数据改动时清除了缓存，为什么还要再设置缓存过期时间？

主要有两方面考虑：

容错机制
- 极端情况：如果在执行删除操作时，数据库（MySQL）执行成功了，但是 Redis 在执行删除代码时，突然因为某个原因导致服务器宕机或 Redis 挂了
- 后果：如果没有过期时间，那么这份脏数据将永久驻留在 Redis 中，那么用户将看到错误的数据
- 设置过期时间则保证了，即使在极端环境下，也能实现数据的最终一致性
内存管理
- Redis是内存数据库，其所有数据都是存储在内存的；而我们又都知道，内存是及其昂贵的资源
- 缓存的目标是热数据，即经常被访问的数据；如果没有设置过期时间，那么Redis可能会被冷数据填满（比如10年前用户的购物车）

菜品分类查询

缓存策略：

数据结构: Hash
Key格式: dish_category_{categoryId}  
Field格式: dish_{dishId}  
Value: Dish 对象
过期时间: 1小时

当更新菜品时，其分类是否更新是不确定的。如果更新了分类，那么需要把旧分类和新分类的缓存全都清除。

另外一点需要注意的是，DishServiceImpl 中存在两个菜品分类查询的接口：

getByCategoryId：返回 Dish，被管理端调用
getWithFlavorByCategoryId：返回 DishVO，被用户端调用

如果全都实现缓存，那么需要使用两个不同的 Key；但是由于管理端访问频率较低，所以这里只实现用户端的接口。

为什么不能使用同一个 HashKey？

因为二者返回的数据结构不同，会导致类型转换异常和相互覆盖。

套餐分类查询

与「菜品分类查询」类似。

缓存策略：

数据结构: Hash  
Key格式: setmeal_category_{categoryId}  
Field格式: setmeal_{setmealId}  
Value: Setmeal 对象
过期时间: 1小时

当更新套餐时，其分类是否更新是不确定的。如果更新了分类，那么需要把旧分类和新分类的缓存全都清除。

套餐详情查询

用户查看套餐详情时，服务端涉及 setmeal + setmeal_dish 的联表查询，且套餐的修改频率较低，因此同样可以用缓存来提高效率。

缓存策略：

数据结构: Hash
Key: setmeal_detail_{setmealId}
Field: dish_{index}_{name}
Value: DishItemVO 对象
过期时间: 2小时

由于 DishItemVO 中没有 DishId，为了确保唯一性，所以使用「索引+名称」作为 field

分类列表

用户打开小程序首页时必查分类，而且分类是基础数据，变更极少，因此非常推荐缓存。

缓存策略：

数据结构: Hash
Key: category_type_{type}
Field: category_{categoryId}
Value: Category 对象
过期时间：24小时

这里采用分类型缓存，type：1-菜品分类，2-套餐分类
分类的变更频率极低，因此过期时间可以适当延长

对于新增的分类，其状态默认为 0（禁用），因此可以不必立即清理缓存，可以等到启用的时候再清理。

店铺营业状态

店铺营业状态应该是读取频率最高的了，而且其实现也很简单。

缓存策略：

数据结构: String
Key: SHOP_STATUS
Value: Integer (0-停业, 1-营业)
过期时间: 永久（手动更新）

用户地址簿

用户地址簿可能变更相对频繁，之所以将其缓存是因为其查询次数较多，且数据是按用户隔离的。

缓存策略：

数据结构: Hash
Key: address_book_{userId}
Field: address_{addressId}
Value: addressBook对象
过期时间: 30分钟（会话期间）

TCP拥塞控制：快速恢复算法

Sun, 26 Oct 2025 21:18:39 GMT

当网络出现拥塞，TCP会进行数据段重传。存在两种重场景：超时重传和快速重传。

不同的重传机制使用不同的拥塞发送算法。当发生快速重传时，TCP使用快速恢复算法。

当发生快速重传时，这种情况并不及超时重传严重（只丢失了一部分数据段），因此并不需要重新进入慢启动状态。 ssthresh 和 cwnd 变化如下：

cwnd = cwnd / 2 ，即设置为原来的一半
ssthresh = cwnd
进入快速恢复算法

快速恢复算法操作如下：

拥塞窗口 cwnd = ssthresh + 3 （说明至少有 3 个分组离开了网络）
重传丢失的数据包
每收到一个新的重复 ACK：
- cwnd + 1（有一个分组离开了网络）
收到新数据的 ACK 时：
- 说明丢失的数据已经被成功收到
- 把 cwnd 直接减为 ssthresh
- 退出快速恢复，进入**拥塞避免算法

下图展示了 TCP Reno 的拥塞控制算法（来源于小林coding），包括慢启动、拥塞避免、快速重传和快速恢复：

存在两点疑问：

1. 为什么收到重复 ACK 时，cwnd 增加 1？

该机制被称为窗口膨胀。

重复 ACK 的含义： 接收方能够发出重复 ACK，就证明它已经接收并缓存了一个新的乱序报文段，这意味着网络中有一个报文段（可能是乱序到达的那个，也可能是更早发送的）已经安全到达了接收端，并离开了传输中的“拥塞管道”。

窗口补偿：由于丢失的报文段未被确认，snd_una（最早未被确认的报文段）无法推进，发送窗口（rwnd 和 cwnd 的最小值）因此不能滑动。为了继续向网络注入数据流，避免“管道”变空，TCP 人为地将 cwnd 增加 $1 \times MSS$，以补偿已离开网络、但尚未被最终确认的报文段。

2. 为什么收到新的 ACK 后还要恢复到 sstresh？

新的 ACK 的含义：收到确认新数据的 ACK，表明接收方已经收到并正确组装了之前丢失的所有报文段，因此发送窗口可以大幅向前滑动。

撤销膨胀：既然发生了快速重传，说明此时的网络或多或少还是有些拥塞的，而之前增加 cwnd 只是一种补偿机制，即补偿窗口不能滑动使得无法发送新的包。既然收到了新的 ACK 后窗口可以滑动了，那也就不需要继续补偿了，反而因为当下的拥塞状态缩小窗口。

恢复到拥塞避免：将 cwnd 设为 ssthresh 的目的，就是退出快速恢复阶段，进入拥塞避免阶段，即开始“小心”地增长，避免发生拥塞。

Obsidian：RSS阅读与管理

Sun, 26 Oct 2025 20:34:54 GMT

尝试了很多RSS阅读器后，发现Obsidian存在插件——RSS Dashboard，可以实现RSS的集中管理和阅读，上手后觉得效果还不错，作此分享。

插件安装

项目地址：[https://github.com/amatya-aditya/obsidian-rss-dashboard]。

里面的安装说明写得很详细，照着做就行。

插件使用

完成插件安装并启用后，左侧边栏会多出一个RSS Dashboard的图标，点击它即可打开RSS阅读界面。

下面是我的使用界面。

在Dashboard界面，可以看到已订阅的RSS源列表，以及各个源的最新文章预览。

在Discover界面，可以搜索一些已有的RSS源，方便添加订阅。

RSS获取

插件本身并不提供RSS源，需要用户自行添加RSS源地址。推荐在RSShub获取各种网站的RSS源地址，RSShub支持生成大量网站的RSS源，非常实用。

参考链接

CS144 Checkpoint2

Tue, 16 Sep 2025 11:23:11 GMT

整个 cs144 的实验结构层次图如下：

应用层程序
   │
[ TCPSocket ]   ← 提供 connect/read/write 接口
   │
[ TCPConnection ] ← 整体状态机，协调发送方和接收方
   ├─ [ TCPSender ]   ← 分片、发送、重传
   └─ [ TCPReceiver ] ← 重排、确认、窗口
        │
   [ Reassembler ]   ← 拼接乱序片段
        │
   [ ByteStream ]    ← 有限容量的字节缓冲

在 Checkpoint2 中，我们需要实现一个 TCP 接收器（TCPReceiver）。该模块主要任务如下：

接收发送方的报文（Message），并且使用之前实现的 Reassembler 将其中的数据段组装成 ByteStream
向发送方回复报文，其中包含 ACK number（ackno）以及当前接收窗口的空闲空间大小（用于流量控制）

wrap/unwrap

在 Reassembler 中每个字节的序号由 64 位表示，并且序号从 0 开始，称为绝对序号（absolute seqno）。但是在 TCP 首部中要尽可能的压缩空间，于是使用 32 位来表示，称为序号（seqno）。这新增了以下机制：

循环（wrap）：相比 64 位，32 位能表示的范围非常小，如果超过最大值则进行循环处理
随机初始序号（ISN）：为了防止旧报文干扰新连接，采取随机初始序号的方式
标志位：TCP 首部的 SYN 标志位表示“请求建立连接”，而 FIN 标志位表示“请求断开连接”

![[Pasted image 20250915163109.png]]

zero_point = 2^32 - 2 ，代表逻辑零点，对应 TCP 的 SYN（因为 seqno 使用随机 ISN）
stream index 才是传入重组器的参数，因为我们之前的实现没有考虑标志位

已经提前声明了 Wrap32（wrapping_integers.hh）来表示报文中的序号，其中使用 uint32_t 来存储数据。

这里需要实现绝对序号和序号之间的转换，以便后面将其发送给 Reassembler 进行拼接。

wrap()：Absolute seqno -> seqno

// Absolute seqno -> seqno
Wrap32 Wrap32::wrap(uint64_t n, Wrap32 zero_point)
{
  constexpr uint64_t MOD = 1ull << 32;
  // (isn + absolute_seqno) % 2^32
  const uint64_t sum = n + static_cast<uint64_t>(zero_point.raw_value_);
  return Wrap32(static_cast<uint32_t>(sum % MOD));
}

unwrap()：序号 -> 绝对序号

// seqno -> Absolute seqno
uint64_t Wrap32::unwrap(Wrap32 zero_point, uint64_t checkpoint) const
{
  constexpr uint64_t MOD = 1ull << 32;

  // 计算 32 位偏移量
  const uint32_t off = this->raw_value_ - zero_point.raw_value_;
  // 对齐高 32 位
  uint64_t candidate = (checkpoint & ~(MOD - 1)) + static_cast<uint64_t>(off);

  // 判断与中点的相对位置
  if (candidate + (MOD >> 1) <= checkpoint) {
    candidate += MOD; // 靠左 -> 下一圈
  } else if (candidate > checkpoint + (MOD >> 1)) {
    if (candidate >= MOD) candidate -= MOD; // 靠右 -> 上一圈（前提是不会下溢）
    // 否则就保持当前不变
  }

  return candidate;
}

由于是从大范围映射到小范围（64 位 -> 32 位），因此会存在映射冲突
checkpoint 为已知的最后一个绝对序号（相当于 bytes_pushed_），因此最接近 checkpoint 才是正确的绝对序号
如果直接减去 MOD 有可能会发生下溢，反而距离更远；加一圈并不会造成上溢

![[unwrap.excalidraw 1.png]]

![[unwrap.excalidraw]]

TCPreceiver

报文数据结构已经提前声明，分别是 TCPSenderMessage 和 TCPReceiverMessage。

recive

首先如果收到 RST 报文，那么直接设置出错：

if (message.RST) {
    reassembler_.output_.set_error();
    return;
  }

如果还未收到 SYN 报文，那么应该忽略所有报文，因为此时连接还未建立，无法接收数据：

if (!has_syn_) {
    // 还未收到 SYN 报文
    if (!message.SYN) return; // 忽略所有非 SYN 报文
    has_syn_ = true;
    zero_point_ = message.seqno;
  }

接下来就是要计算 checkpoint，这样才能算出段首的绝对序号：

  // checkpoint = 1(SYN) + bytes_pushed + (如果已经结束，再+1(FIN))
  const uint64_t bytes_pushed = reassembler_.output_.writer().bytes_pushed();
  const bool ended = reassembler_.output_.reader.is_finished();
  const uint64_t checkpoint = 1 + bytes_pushed + (ended ? 1 : 0);
  
  // payload 的 absolute seqno
  const uint64_t abs_seqno = message.seqno.unwrap(zero_point_, checkpoint);

知道了绝对序号后，我们要将其转换为子字符串也就是 payload 的字节流序号：

  // payload 的 stream index
  const uint64_t stream_index = abs_seqno - 1 + (message.SYN ? 1 : 0);

![[seqno2index.excalidraw.png]]

最后便是将数据推给 Reassembler，即重组器：

  // 推给 BReassembler
  const std::string data = message.payload;
  reassembler_.insert(stream_index, data, message.FIN);

send

首先是设置 RST 标志位：

  TCPReceiverMessage out;

  // 如果收到RST报文或底层字节流出错，要将其反映在发送消息中
  const bool stream_error = reader().has_error();
  out.RST = stream_error || rst_;

其次是计算确认号，与先前计算 checkpoint 逻辑一致：

  // ackno
  if (syn_) {
    const uint64_t bytes_pushed = writer().bytes_pushed();
    const bool ended = writer().is_closed();
    uint64_t ack_abs_seqno = 1 + bytes_pushed + (ended ? 1 : 0);
    out.ackno = Wrap32::wrap(ack_abs_seqno, zero_point_);
  } else {
    out.ackno = nullopt;
  }

最后是计算窗口大小：

  // window_size
  const size_t win = static_cast<uint64_t>(writer().available_capacity());
  out.window_size = static_cast<uint16_t>(min<size_t>(win, std::numeric_limits<uint16_t>::max()));

CS144 Checkpoint1

Sun, 07 Sep 2025 00:06:45 GMT

整个 cs144 的实验结构层次图如下：

应用层程序
   │
[ TCPSocket ]   ← 提供 connect/read/write 接口
   │
[ TCPConnection ] ← 整体状态机，协调发送方和接收方
   ├─ [ TCPSender ]   ← 分片、发送、重传
   └─ [ TCPReceiver ] ← 重排、确认、窗口
        │
   [ Reassembler ]   ← 拼接乱序片段
        │
   [ ByteStream ]    ← 有限容量的字节缓冲

在 Checkpoint1 中，我们需要实现一个 TCP 重组器（Reassembler）。这个模块的主要任务，就是把可能乱序到达的分段（segment）拼接成一个连续的字节流，最终交给 ByteStream。

简单来说，TCP 的世界里：

数据传输是 字节流 的概念；
但是底层传输的时候会切割成一个个分段；
由于网络的特性，分段可能会乱序到达、丢失、甚至重传；
所以接收方必须 缓存未到位的分段，并在合适的时候写入字节流。

类的设计

Reassembler 内部的几个重要成员：

ByteStream output_;                     // 真正的字节流 
std::map<uint64_t, std::string> segs_;  // 缓存未组装的分段 
uint64_t unassembled_;                  // segs_ 里累计的字节数 
std::optional<uint64_t> eof_index_;     // FIN 报文对应的 EOF 位置

这里的核心就是一个 map：

key 是分段的起始索引（first_index），
value 是分段的字符串内容。

利用 map 的有序性，可以方便地处理乱序和重叠。

insert 的主逻辑

insert 方法接收三个参数：

first_index：子串的起始位置；
data：子串内容；
is_last_substring：是否是 TCP FIN 报文。

代码整体分为几个阶段：

1. 确定接收窗口

TCP 缓冲区是有限的，所以要限制接收窗口范围内的数据：

const uint64_t next_index = output_.writer().bytes_pushed();
const uint64_t win_left = next_index;
const uint64_t win_right = next_index + output_.writer().available_capacity();

然后根据窗口对 data 作裁剪：

窗口左边的丢掉（已经被写过的字节）；
窗口右边的丢掉（超过缓存能力的部分）。

2. 记录 EOF

TCP 里的 FIN 报文表示“数据结束”，这里用 eof 模拟。由于可能重传，eof_index_ 只需要记录一次。

if (is_last_substring) {
    const uint64_t logical_eof = first_index + data.size();
    if (!eof_index_.has_value()) {
        eof_index_ = logical_eof;
    }
}

3. 处理分段重叠

这是实现的核心难点。

首先找到第一个可能与新区间重叠的旧分段：

auto it = segs_.lower_bound(start);
if (it != segs_.begin()) {
    auto prev_it = std::prev(it);
    if (prev_it->first + prev_it->second.size() > start) {
        it = prev_it;
    }
}

然后从左到右遍历，处理和已有分段的覆盖、缺口情况：
- 如果旧分段完全在左边，跳过；
- 如果有 gap，把缺口部分切出来放进缓存；
- 如果被覆盖了，就移动到下一个。

uint64_t pos = start;
while (pos < end && it != segs_.end()) {
    uint64_t L = it->first;
    uint64_t R = it->first + static_cast<uint64_t>(it->second.size());
  
    // 判断每个分段与当前分段的重叠情况
    // 1. R <= pos ：直接跳过，不用考虑
    if (R <= pos) {
      it++;
      continue;
    }

    // 2. L > pos：考虑 clipped 的右端是否被覆盖
    if (L > pos) {
      const uint64_t gap_end = std::min<uint64_t>(end, L);
      // 从 clipped 中裁剪出 gap
      const size_t off = static_cast<size_t>(pos - start);
      const size_t len = static_cast<size_t>(gap_end - pos);
      std::string gap = clipped.substr(off, len);
  
      // 入库
      if (!gap.empty()) {
        segs_.emplace(pos, std::move(gap));
        unassembled_ += len;
      }
      pos = gap_end;
      if (pos == end) // 整个分段被处理完成
        break;
    }

    // 3. L <= pos < R，左端被覆盖
    pos = R;
    ++it;
  }

这样可以避免重复存储字节。

4. 处理尾部缺口

可能存在新分段超出已有缓存范围的情况，需要补上尾部的 gap。

if (pos < end) {
    std::string last_gap = clipped.substr(pos - start, end - pos);
    segs_.emplace(pos, std::move(last_gap));
    unassembled_ += end - pos;
}

5. push 到 ByteStream

最后一步，就是把已经连续的部分从缓存里推送到字节流：

while (true) {
    const uint64_t next = output_.writer().bytes_pushed();
    auto hit = segs_.find(next);
    if (hit == segs_.end()) break;

    output_.writer().push(hit->second);
    unassembled_ -= hit->second.size();
    segs_.erase(hit);
}

这样，ByteStream 就始终保持尽可能完整的前缀字节流。

6. 收尾关闭

当所有字节都被写入，且 bytes_pushed == eof_index_，就可以关闭流：

if (eof_index_.has_value() && output_.writer().bytes_pushed() == *eof_index_) {
    output_.writer().close();
}

整体代码

reassembler.hh：

class Reassembler
{
public:
  // Construct Reassembler to write into given ByteStream.
  // 维护一个字节流
  explicit Reassembler(ByteStream&& output)
    : output_(std::move(output)), segs_(), unassembled_(0), eof_index_(std::nullopt)
  {}
  
  // ...

private:
  ByteStream output_;
  std::map<uint64_t, std::string> segs_; // 未进入字节流（已接收但不连续）
  uint64_t unassembled_;                 // segs中的字节数
  std::optional<uint64_t> eof_index_;    // eof字符串索引
};

reassembler.cc：

// 接受一个子字符串，其 first_index 代表该子串头部字节在整个字节流中的序号（这里规定序号从 0 开始）
// data 单纯代表数据，不包含头部
// is_last_substring 模拟的是 TCP FIN 报文
void Reassembler::insert(uint64_t first_index, string data, bool is_last_substring)
{
  const uint64_t next_index = output_.writer().bytes_pushed(); // 下一个要写入的索引
  // 划定接收窗口，即缓存中未被占用的部分 [win_left, win_right)
  const uint64_t win_left = next_index;
  const uint64_t win_right = next_index + output_.writer().available_capacity();
  
  // 记录eof指针位置
  // FIN报文只有一个，但是由于网络重传，其可能会被多次发送，因此这里只需记录一次
  if (is_last_substring) {
    const uint64_t logical_eof = first_index + static_cast<uint64_t>(data.size());
    if (!eof_index_.has_value()) {
      eof_index_ = logical_eof; // 只记录一次
    }
  }

  // 确定data在窗口中的位置，溢出窗口的部分直接丢弃
  // [start, end)
  uint64_t start = max<uint64_t>(first_index, win_left);
  const uint64_t end = min<uint64_t>(first_index + static_cast<uint64_t>(data.size()), win_right);
  if (start >= end) {
    /*
     * 三种情况：
     * 1. 子串在窗口左边（冗余序列）
     * 2. 子串在窗口右边（溢出序列）
     * 3. 子串为空
     * 这些情况没有字节可以接收，之所以要单独讨论是因为其可能为is_last_substring，触发收尾
     */
    if (eof_index_.has_value() && output_.writer().bytes_pushed() == *eof_index_) {
      output_.writer().close();
    }
    return;
  }

  // 裁剪字符串 [start - first_index, end - start)
  std::string clipped = data.substr(static_cast<uint64_t>(start - first_index), static_cast<uint64_t>(end - start));

  // 若存在重叠，则获取第一个与clipped重叠的分段
  // 若不存在，则默认获取后面一个分段
  auto it = segs_.lower_bound(start); // key>=start
  // 有可能被前面分段覆盖
  if (it != segs_.begin()) {
    auto prev_it = std::prev(it);
    if (prev_it->first + static_cast<uint64_t>(prev_it->second.size()) > start) {
      it = prev_it;
    }
  }

  // 可能与多个分段存在重叠，因此需要从最早的那个开始遍历
  uint64_t pos = start;
  while (pos < end && it != segs_.end()) {
    uint64_t L = it->first;
    uint64_t R = it->first + static_cast<uint64_t>(it->second.size());

    // 判断每个分段与当前分段的重叠情况
    // 1. R <= pos ：直接跳过，不用考虑
    if (R <= pos) {
      it++;
      continue;
    }

    // 2. L > pos：考虑 clipped 的右端是否被覆盖
    if (L > pos) {
      const uint64_t gap_end = std::min<uint64_t>(end, L);
      // 从 clipped 中裁剪出 gap
      const size_t off = static_cast<size_t>(pos - start);
      const size_t len = static_cast<size_t>(gap_end - pos);
      std::string gap = clipped.substr(off, len);

      // 入库
      if (!gap.empty()) {
        segs_.emplace(pos, std::move(gap));
        unassembled_ += len;
      }
      pos = gap_end;
      if (pos == end) // 整个分段被处理完成
        break;
    }

    // 3. L <= pos < R，左端被覆盖
    pos = R;
    ++it;
  }

  // 有可能clipped超出了segs现在的范围，导致其还剩余一个后置gap
  // 比如 clipped: [6, 10), segs最后一段: [7, 9), 导致 [9, 10)需要添加在最后
  if (pos < end) {
    const size_t off = static_cast<size_t>(pos - start);
    const size_t len = static_cast<size_t>(end - pos);
    std::string last_gap = clipped.substr(off, len);
    if (!last_gap.empty()) {
      segs_.emplace(pos, std::move(last_gap));
      unassembled_ += len;
    }
  }

  // 开始push连续的分段
  while (true) {
    // bytes_pushed_会一直更新，因此每次都要重新获取
    const uint64_t next = output_.writer().bytes_pushed();
    auto hit = segs_.find(next);
    if (hit == segs_.end())
      break;

    output_.writer().push(hit->second);
    unassembled_ -= hit->second.size();
    segs_.erase(hit);
  }

  // 最后只差eof时(bytes_pushed_ == *eof_index_)，可以开始关闭接收端口
  if (eof_index_.has_value() && output_.writer().bytes_pushed() == *eof_index_) {
    output_.writer().close();
  }
}

CS144 Checkpoint0

Fri, 05 Sep 2025 17:51:12 GMT

整个 cs144 的实验结构层次图如下：

应用层程序
   │
[ TCPSocket ]   ← 提供 connect/read/write 接口
   │
[ TCPConnection ] ← 整体状态机，协调发送方和接收方
   ├─ [ TCPSender ]   ← 分片、发送、重传
   └─ [ TCPReceiver ] ← 重排、确认、窗口
        │
   [ Reassembler ]   ← 拼接乱序片段
        │
   [ ByteStream ]    ← 有限容量的字节缓冲

实验的顺序为层次图从低到高，本实验中需要实现 ByteStream。

这里其实有个小疑问：既然 Socket 继承于 FileDescritpion，其中已经实现了文件的读写，为什么还要在底层实验 ByteStream，而不是直接在 Socket 中封装对应 API 和状态？其实是因为 CS144 为了教学目的，将这些功能拎出来进行封装，使得层次更加清晰；而在真实的操作系统中，以上功能是封装在一起的，也不需要增加一个 ByteStream

在 Linux 内核中的层次结构如下：

┌───────────────────────────────┐
│        应用层程序 (用户态)      │
│  read/write, send/recv, etc.  │
└───────────────┬───────────────┘
                │
        系统调用接口 (syscall)
                │
┌───────────────▼────────────────┐
│     Socket 内核对象 (黑盒)       │  ← Linux 内核实现
│  struct socket / tcp_sock       │
│                                 │
│  - API 封装 (send/recv)         │
│  - TCP 状态机 (ESTABLISHED...)  │
│  - 序号空间 (SND.NXT/RCV.NXT)   │
│  - 定时器、RTT 估算             │
│  - 发送缓冲区 sndbuf            │
│  - 接收缓冲区 rcvbuf            │
│  - 乱序重组、ACK、重传          │
└───────────────┬────────────────┘
                │
                ▼
        TCP/IP 协议栈 (内核实现)
                │
                ▼
         网络接口/驱动/硬件

webget

首先来看文件 file_descriptor.hh，其中使用 FDWrapper 来保存fd及其状态信息，而 FileDescriptor 提供了对外的操作接口并通过 shared_ptr 来管理 FDWrapper，多个 FileDescriptor 可共享同一个fd(FDWrapper)，内部增加其引用计数。

在 socket.hh 中，Socket 继承了 FileDescriptor，证明 Socket 本身就是一个文件描述符 fd，使用 FileDescriptor 管理fd声明周期，并在 Socket 中封装了 socket 相关的操作。该文件中声明了许多类：

DatagramSocket：一个抽象层，封装了面向数据报（与之相反的是面向连接的 TCP）的 socket 操作，因为最后几个 class 都是面向数据报的，所以在这里添加一个抽象层用于继承
UDPSocket：UPD socket，直接继承的 DatagramSocket
TCPSocket：TCP socket，继承于 Socket，并提供一些面向连接的 API，如 listen() 和 accept()
一些继承于 DatagramSocket 的 socket

webget.cc 中 get_URL() 实现：

// 该文件的目的是使用TCP套接字连接到Web服务器并获取一个URL。

void get_URL(const string& host, const string& path)

{
  // cerr << "Function called: get_URL(" << host << ", " << path << ")\n";
  // cerr << "Warning: get_URL() has not been implemented yet.\n";

  // 1. 与web建立连接
  // 这里并没有调用bind()来绑定本地地址，因为客户端的内核会自动进行隐式绑定
  TCPSocket client;
  client.connect(Address(host, "http"));

  // 2. 组装请求报文
  string msg;
  msg += "GET " + path + " HTTP/1.1\r\n";
  msg += "Host: " + host + "\r\n";
  msg += "Connection: close\r\n"; // 非持续连接
  msg += "\r\n";                  // 报文要以\r\n结尾

  // 3. 发送请求报文
  client.write(msg);

  // 4. 循环获取响应报文，直到找到EOF
  string resp;
  while (!client.eof()) {
    resp.clear();
    client.read(resp);
    cout << resp;
  }
}

ByteStream

这个实现也很简单，就是设立缓冲区，实现 ByteStream。

在 byte_stream.hh 中添加维护字段：

protected:
  // Please add any additional state to the ByteStream here, and not to the Writer and Reader interfaces.
  uint64_t capacity_;
  bool error_ {};
  std::string buffer_;
  int bytes_pushed_;
  int bytes_popped_;
  bool closed_;

byte_stream.cc 中实现：

#include "byte_stream.hh"
#include <cstdint>
#include <string_view>

using namespace std;

ByteStream::ByteStream(uint64_t capacity)
  : capacity_(capacity), buffer_(), bytes_pushed_(0), bytes_popped_(0), closed_(false)
{}

void Writer::push(string data)
{
  if (closed_) {
    return;
  }
  
  uint64_t available = available_capacity();
  if (data.size() > available) {
    data.resize(available);
  }

  buffer_.append(data);
  bytes_pushed_ += data.size(); // 这里不能加available，因为data长度可能没有溢出
}

void Writer::close()
{
  closed_ = true;
}

bool Writer::is_closed() const
{
  return closed_;
}

  

uint64_t Writer::available_capacity() const
{
  return capacity_ - buffer_.size();
}

uint64_t Writer::bytes_pushed() const
{
  return bytes_pushed_;
}

string_view Reader::peek() const
{
  return string_view(buffer_);
}

void Reader::pop(uint64_t len)
{
  if (len > buffer_.size()) {
    set_error();
  }
  
  buffer_.erase(0, len);
  bytes_popped_ += len;
}

bool Reader::is_finished() const
{
  return closed_ && buffer_.size() == 0;
}
  
uint64_t Reader::bytes_buffered() const
{
  return buffer_.size();
}

uint64_t Reader::bytes_popped() const
{
  return bytes_popped_;
}

2025-08-31

Sun, 31 Aug 2025 10:56:32 GMT

暑假学习了操作系统的课程—mit6.s081，但是似乎仅限于此。对比放假前立下的目标——力扣竞赛分数、编程语言的深度学习，多多少少还有一段距离。

暑假的颓废然我想起了很早之间刷到的一个油管视频，里面讲解了极度专注+短暂放松的学习方法，并建议在特定的场所学习，在自己的房间或宿舍的话就会不由自主的做一些无关紧要的事情（行动成本更低）。

眼看与同龄人的差距越来越大，我必须加快自己的学习进度，这学期的时间应该大部分都要在图书馆度过。对于塞满日程的专业（水）课，能逃就逃，逃不掉就看专业书。

MIT6.S081 Lab mmap

Mon, 18 Aug 2025 22:18:13 GMT

参考博客：Xiao Fan（樊潇）

实验目的：

实现一个功能稍微简略的 mmap()，addr 始终为零，即由内核决定映射文件的虚拟地址
实现 munmap()，移除指定地址范围内的内存映射。如果进程已修改该内存且将其映射 MAP_SHARED，则应现将修改内容写入文件

首先是将 $U/_mmaptest\ 添加到 Makefile，然后添加 mmap() 和 munmap() 系统调用，这里不再赘述。

在 proc.h 中添加对 struct vma 的定义：

struct vma {
  int valid;
  uint64 addr;
  int length;
  int prot;
  int flags;
  struct file *mapfile;
};

// Per-process state
struct proc {
  // ...
  struct vma vmas[NVMA];       // Process vmas
};

由于默认 offset 为零，因此这里不需要声明该字段

在 param.h 中添加 NVMA ：

#define NVMA 16 // number of process vmas

在 sysfile.c 中添加 sys_mmap()：

uint64 sys_mmap(void) {
  int length, prot, flags, fd;
  struct proc *p = myproc();
  struct file *mapfile;

  // get argument
  if (argint(1, &length) < 0 || argint(2, &prot) < 0 ||
      argint(3, &flags) < 0 || argfd(4, &fd, &mapfile) < 0)
    return -1;

  // check
  length = PGROUNDDOWN(length);
  if(MAXVA - length < p->sz)
    return -1;
  if (!mapfile->readable && (prot & PROT_READ))
    return -1;
  if (!mapfile->writable && (prot & PROT_WRITE) && (flags & MAP_SHARED))
    return -1;

  // find a free vma and contain it
  for (int i = 0; i < NVMA; ++i) {
    struct vma *curvma = &p->vmas[i];
    if (!curvma->valid) {
      curvma->valid = 1;
      curvma->addr = p->sz;
      p->sz += length;
      curvma->length = length;
      curvma->flags = flags;
      curvma->prot = prot;
      curvma->mapfile = mapfile;
      filedup(mapfile);
      return curvma->addr;
    }
  }

  // no free vma
  return -1;
}

这里固定 addr 为 0，因此不需要获取
pvma[i].addr = p->sz：将新映射的内存区域放在堆的栈顶，紧接在现有地址空间之后
pvma[i].valid_len = pvma[i].len：延迟加载，初始时未分配任何物理页，但是要将其表示为已占用

接下来在 usertrap() 中添加对页错误的处理，实现延迟加载：

} else if (r_scause() == 13 || r_scause() == 15) { // Page Fault
    uint64 va = r_stval();
    struct proc *p = myproc();
    struct vma *vmas = p->vmas;

    // check va safe
    if (va > MAXVA || va >= p->sz)
      goto exception;

    // lazy allocation
    for (int i = 0; i < NVMA; ++i) {
      struct vma *curvma = &vmas[i];
      if (curvma->valid && va >= curvma->addr &&
          va < curvma->addr + curvma->length) {
        va = PGROUNDDOWN(va);
        uint64 pa = (uint64)kalloc();
        if (pa == 0)
          goto exception;
        memset((void *)pa, 0, PGSIZE);
        ilock(curvma->mapfile->ip);
        if (readi(curvma->mapfile->ip, 0, pa, va - curvma->addr, PGSIZE) < 0) {
          iunlock(curvma->mapfile->ip);
          break;
        }
        iunlock(curvma->mapfile->ip);
        int flag = (curvma->prot << 1) | PTE_V | PTE_U;
        if (mappages(p->pagetable, va, PGSIZE, pa, flag) < 0) {
          kfree((void*)pa);
          break;
        }
        break;
      }
    } 
  } else {
      exception:
      printf("usertrap(): unexpected scause %p pid=%d\n", r_scause(), p->pid);
      printf("            sepc=%p stval=%p\n", r_sepc(), r_stval());
      p->killed = 1;
    }

    if (p->killed)
      exit(-1);

    // give up the CPU if this is a timer interrupt.
    if (which_dev == 2)
      yield();

    usertrapret();
  }

int flag = (pvma[i].prot << 1) | PTE_U | PTE_V：这里需要将 prot 转换为 PTE 的权限位
- 在 PTE 中 PTE_R (1L << 1)、PTE_W (1L << 2)、PTE_X (1L << 3)
- 在 prot 中 PROT_READ 0x1、PROT_WRITE 0x2、PROT_EXEC 0x4
- 也就是说 prot 向左移动一位正好匹配 PTE 的标志位

接下来实现 munmap()：

uint64 sys_munmap(void) {
  uint64 addr;
  int length;
  struct proc *p = myproc();
  
  // get argument
  if (argaddr(0, &addr) < 0 || argint(1, &length) < 0)
    return -1;

  // look for vma
  struct vma *vma = 0;
  int found = 0;
  for (int i = 0; i < NVMA; ++i) {
    vma = &p->vmas[i];
    if (vma->valid && addr >= vma->addr && addr < vma->addr + vma->length) {
      found = 1;
      break;
    }
  }
  
  // not found
  if (!found)
    return -1;

  addr = PGROUNDDOWN(addr);
  length = PGROUNDDOWN(length);
  if (vma->flags & MAP_SHARED) {
    // if MAP_SHARED then write back first
    if (filewrite(vma->mapfile, addr, length) < 0)
      printf("munmap: filewrite < 0\n");
  }

  // unmapped
  uvmunmap(p->pagetable, addr, length / PGSIZE, 1);

  if (addr == vma->addr) {
    if (length == vma->length) {
      // unmapped whole vma
      fileclose(vma->mapfile);
      vma->valid = 0;
      p->sz -= length;
    } else {
      // unmapped from start to middle
      vma->addr += length;
      vma->length -= length;
    } 
  } else if (addr + length == vma->addr + vma->length) {
    // unmapped from middle to end
    vma->length -= length;
  } else {
    return -1;
  }

  return 0;
}

如果进程已修改该内存且将其映射 MAP_SHARED ，则应先将修改内容写入文件
分情况讨论取消映射的范围，要么从起始处开始，要么一直到末尾，而不会在中间打洞
uvmunmap() 取消映射并释放先前分配的物理内存，最后一个参数为 1（为 0 则不释放物理内存）
p->sz -= length：既然是取消映射了整个 vma，这里应当更新 p->sz

更新 fork() 和 exit()：

// Create a new process, copying the parent.
// Sets up child kernel stack to return as if from fork() system call.
int fork(void)
{
  int i, pid;
  struct proc *np;
  struct proc *p = myproc();

  // Allocate process.
  if((np = allocproc()) == 0){
    return -1;
  }

	// Copy vma from parent to child
  for (int i = 0; i < NVMA; i++) {
    if (p->vmas[i].valid) {
      memmove(&np->vmas[i], &p->vmas[i], sizeof(struct vma));
      filedup(np->vmas[i].mapfile);
    }
  }

  // ...
}

// Exit the current process.  Does not return.
// An exited process remains in the zombie state
// until its parent calls wait().
void exit(int status)
{
  struct proc *p = myproc();

  if(p == initproc)
    panic("init exiting");

  // Close all open files.
  for(int fd = 0; fd < NOFILE; fd++){
    if(p->ofile[fd]){
      struct file *f = p->ofile[fd];
      fileclose(f);
      p->ofile[fd] = 0;
    }
  }

  // unmap all vma
  for (int i = 0; i < NVMA; ++i) {
    if (p->vmas[i].valid) {
      if (p->vmas[i].flags & MAP_SHARED) {
        filewrite(p->vmas[i].mapfile, p->vmas[i].addr, p->vmas[i].length);
      }
      fileclose(p->vmas[i].mapfile);
      uvmunmap(p->pagetable, p->vmas[i].addr, p->vmas[i].length / PGSIZE, 1);
      p->vmas[i].valid = 0;
    }
  }

  // ...
}

这里如果是 MAP_SHARED 则同样需要先写入
使用 fileclose() 减少引用
依旧使用 uvmunmap() 取消映射并释放物理内存

到这一步依然存在许多 bug，导致无法通过测试。

在 munmap() 中存在 unmap from start to middle 和 unmap from middle to end 的情况，这就导致在 p->sz 以内的内存并不一定都有映射，因此可能会造成 uvmunmap() 和 uvmcopy() 的 panic，需要作以下修改：

// uvmcopy
if((*pte & PTE_V) == 0)
     // panic("uvmcopy: page not present");
     continue;
  
// uvmunmap  
// if((*pte & PTE_V) == 0)
//   panic("uvmunmap: not mapped");

另外 kfree 会试图解放 0 这个物理内存，参考博客的作者没有给出原因，我在上一个 bug 耗费了太多时间和精力，因此也没有弄明白，直接作修改吧：

void
kfree(void *pa)
{
  struct run *r;
  if (pa == 0)
    return;

总结：

这个 lab 的逻辑并不是非常难（默认 addr 和 offset 为 0，简化了逻辑）
后边所说的这些 bug 实属可恶，只能使用 printf 慢慢找错误点
查看了许多博客的实现，但是好多都没有涉及上述 bug 的解决，不知道是哪里有差异或是我使用的 21 年版本新出现的bug

XV6 Trap机制（1）：硬件支持

Mon, 18 Aug 2025 22:18:13 GMT

每个 RISC-V CPU 都有一组特权寄存器，内核写入这些控制寄存器来告诉 CPU 如何处理 trap，并且内核可以读取这些寄存器来找出已发生的 trap（在 kernel/riscv.h 中定义）。

重要特权寄存器概述：

stevc：trap handler 的地址，由内核写入，告诉
sepc：保存 trap 发生时的程序寄存器（因为 pc 随后会被 stvec 中的值覆盖）。sret（从 trap 返回）指令将 sepc 复制到 pc，可以通过编写 sepc 来控制 sret 的去向
scause：放置一个数字来描述 trap 的原因
sscratch：放在 trap handler 的最开始处，防止在保存用户寄存器之前覆盖它们
sstatus：其中的 SIE 位控制是否启用设备中断。如果内核清除 SIE，RISC-V 将推迟设备中断，直到内核设置 SIE。SPP 位指示 trap 是来自用户模式还是管理模式，并控制 sret 返回的模式
satp：当前页表的根地址 上述寄存器与内核模式下处理的 trap 相关，并且不能在用户模式下读取或写入。

RISC-V 硬件会对所有 trap 类型（定时器中断除外）执行以下操作：

中断屏蔽检查
- 如果 trap 是由设备中断引发的，且 sstatus.SIE=0，则处理器会暂存该中断，暂缓执行
- 如果是异常或系统调用，会跳过该步骤
禁用中断
- 设置 sstatus.SIE=0：防止 trap 处理期间被其他中断嵌套
保存上下文
- sepc：保存当前 pc，以便 trap 返回时恢复执行
- sstatus.SPP：保存当前特权模式（0=user, 1=kernel）
设置 trap 原因
- scause：记录 trap 类型（中断或异常）和具体原因（如中断号或异常码）。
切换管理模式
- 将当前模式设置为 Supervisor Mode，以便执行内核中的 trap handler。
跳转到 trap handler
- 将 stvec 的地址加载到 pc 。以上步骤为硬件操作，在发生 trap 后自动执行，并没有显式代码。

中断屏蔽检查中为什么区别对待？

设备中断的异步性
- 设备中断是异步的，可以在任何时候发生。因此操作系统需要暂时屏蔽中断，以确保某些关键代码不被中断干扰。
- 屏蔽中断时，新的中断可以被暂存，等到中断重启时再处理。
异常和系统调用的同步性
- 异常和系统调用是由当前指令直接触发的，是同步事件。
- 异常通常表示必须立即处理的错误或特殊情况，如果不处理，程序无法正确执行。
- 系统调用是程序主动请求内核服务，如果不处理，程序会一直等待。

未完成的步骤（需软件处理）：

切换页表：CPU 不会自动切换页表
切换栈指针：CPU 不会自动切换栈
保存寄存器：通用寄存器需由软件保存 CPU 保留上述步骤交给软件处理是为软件提供灵活性，比如某些操作系统在某些情况下会省略页表切换，硬件仅提供最小必要的支持。而这些步骤都将在 trapline 页（uservec）中执行。

MIT6.S081 Lab fs

Fri, 15 Aug 2025 17:58:31 GMT

Large files

实验目的：

扩充 inode 的 addrs 数组，为其减少一个直接块，增加一个二级间接块，其存储一级间接块的地址
修改 bmap()，使得其能定位二级间接块里的数据块
修改 itrunc()，使其能释放二级间接块及其中的所有块

addrs 数组的结构：

首先修改全局变量以及 struct inode/dinode：

#define NDIRECT 11
#define NINDIRECT (BSIZE / sizeof(uint))
#define MAXFILE (NDIRECT + NINDIRECT + NINDIRECT * NINDIRECT)

// On-disk inode structure
struct dinode {
	short type; // File type
	short major; // Major device number (T_DEVICE only)
	short minor; // Minor device number (T_DEVICE only)
	short nlink; // Number of links to inode in file system
	uint size; // Size of file (bytes)
	uint addrs[NDIRECT+2]; // Data block addresses
};

// in-memory copy of an inode
struct inode {
	uint dev; // Device number
	uint inum; // Inode number
	int ref; // Reference count
	struct sleeplock lock; // protects everything below here
	int valid; // inode has been read from disk?
	  
	short type; // file or directory
	short major;
	short minor;
	short nlink;
	uint size;
	uint addrs[NDIRECT+2];
};

接着为 bmap() 增加索引二级间接块的逻辑：

static uint
bmap(struct inode *ip, uint bn)
{
	uint addr, *a;
	struct buf *bp;
	  
	if(bn < NDIRECT){
		if((addr = ip->addrs[bn]) == 0)
			ip->addrs[bn] = addr = balloc(ip->dev);
		return addr;
	}
	bn -= NDIRECT;
	
	if(bn < NINDIRECT){
		// Load indirect block, allocating if necessary.
		if((addr = ip->addrs[NDIRECT]) == 0)
			ip->addrs[NDIRECT] = addr = balloc(ip->dev);
		bp = bread(ip->dev, addr);
		a = (uint*)bp->data;
		if((addr = a[bn]) == 0){
			a[bn] = addr = balloc(ip->dev);
			log_write(bp);
		}
		brelse(bp);
		return addr;
	}
	bn -= NINDIRECT;
	  
	if (bn < NINDIRECT * NINDIRECT) {
		int id = bn / NINDIRECT;
		int off = bn % NINDIRECT;
		if ((addr = ip->addrs[NDIRECT + 1]) == 0) // 先检查二级间接块是否存在
			ip->addrs[NDIRECT + 1] = addr = balloc(ip->dev);
		bp = bread(ip->dev, addr);
		a = (uint *)bp->data;
		if ((addr = a[id]) == 0) { // 检查其中的一级间接块是否存在
			a[id] = addr = balloc(ip->dev);
			log_write(bp); // 记录修改
		}
		brelse(bp); // 释放二级间接块
	  
		bp = bread(ip->dev, addr); // 读取一级间接块
		a = (uint *)bp->data;
		if ((addr = a[off]) == 0) {
			a[off] = addr = balloc(ip->dev);
			log_write(bp);
		}
		brelse(bp);
		return addr;
	}
	
	panic("bmap: out of range");
}

修改 itrunc() 的逻辑，使其能够释放二级间接块：

void
itrunc(struct inode *ip)
{
	int i, j;
	struct buf *bp;
	uint *a;
	
	for(i = 0; i < NDIRECT; i++){
		if(ip->addrs[i]){
			bfree(ip->dev, ip->addrs[i]);
			ip->addrs[i] = 0;
		}
	}
	  
	if(ip->addrs[NDIRECT]){
		bp = bread(ip->dev, ip->addrs[NDIRECT]);
		a = (uint*)bp->data;
		for(j = 0; j < NINDIRECT; j++){
			if(a[j])
				bfree(ip->dev, a[j]);
		}
		brelse(bp);
		bfree(ip->dev, ip->addrs[NDIRECT]);
		ip->addrs[NDIRECT] = 0;
	}
	
	// 释放二级间接块
	if (ip->addrs[NDIRECT + 1]) {
		bp = bread(ip->dev, ip->addrs[NDIRECT + 1]);
		a = (uint *)bp->data;
		
		struct buf *bps;
		uint *b;
		for (j = 0; j < NDIRECT; ++j) {
			if (a[j]) { // 一级间接块存在，则需要先释放其中的数据块
				bps = bread(ip->dev, a[j]);
				b = (uint *)bps->data;
				for (int i = 0; i < NDIRECT; ++i) {
					if (b[i])
						bfree(ip->dev, b[i]);
				}
				brelse(bps);
				bfree(ip->dev, a[j]); // 释放一级间接块
			}
		}
		brelse(bp);
		bfree(ip->dev, ip->addrs[NDIRECT + 1]);
		ip->addrs[NDIRECT + 1] = 0;
	}
	
	ip->size = 0;
	iupdate(ip);
}

Symbolic links

硬链接是同一个文件的多个目录入口，指向相同的 inode；而软链接则是一个独立的文件，存储的是目标文件的路径。

实验目的：

添加并实现 symlink(char *target, char *path) 系统调用，使得为 target 创建 path 软链接
修改 open()，添加对软链接的处理

对于 symlink() 系统调用的添加不再赘述。

在 fcntl. h 中添加 O_NOFOLLOW，由于不能与已有标志重叠，所以设置为 0x800

#define O_RDONLY 0x000
#define O_WRONLY 0x001
#define O_RDWR 0x002
#define O_CREATE 0x200
#define O_TRUNC 0x400
#define O_NOFOLLOW 0x800

symlink() 的实现：创建一个 inode，设置类型为 T_SYMLINK，然后向 inode 中写入 path 即可

uint64
sys_symlink(void)
{
  char target[MAXPATH];
  memset(target, 0, sizeof(target));
  char path[MAXPATH];
  if(argstr(0, target, MAXPATH) < 0 || argstr(1, path, MAXPATH) < 0){
    return -1;
  }
  
  struct inode *ip;

  begin_op();
  if((ip = create(path, T_SYMLINK, 0, 0)) == 0){
    end_op();
    return -1;
  }

  if(writei(ip, 0, (uint64)target, 0, MAXPATH) != MAXPATH){
    // panic("symlink write failed");
    return -1;
  }

  iunlockput(ip);
  end_op();
  return 0;
}

在 sys_open 中添加对符号链接的处理：

uint64
sys_open(void)
{
  ...
	if(ip->type == T_DEVICE && (ip->major < 0 || ip->major >= NDEV)){
		...
	}

  if(ip->type == T_SYMLINK){
    if(!(omode & O_NOFOLLOW)){ // 检查是否要求不解析链接
      int cycle = 0;
      char target[MAXPATH];
      while(ip->type == T_SYMLINK){
        if(cycle == 10){ // 最大递归深度10
          iunlockput(ip);
          end_op();
          return -1; // max cycle
        }
        cycle++;
        // 读取目标路径
        memset(target, 0, sizeof(target));
        readi(ip, 0, (uint64)target, 0, MAXPATH);
        iunlockput(ip);
        // 根据目标路径获取新的inode
        if((ip = namei(target)) == 0){
          end_op();
          return -1; // target not exist
        }
        ilock(ip);
      }
    }
  }

  if((f = filealloc()) == 0 || (fd = fdalloc(f)) < 0){
		...
	}
	...
}

文件路径指向一个软链接时，系统需要递归地解析链接目标，直到找到最终的非链接文件或达到最大递归深度

MIT6.S081 Lab lock

Fri, 15 Aug 2025 04:19:20 GMT

Memory allocator

实验要求：

为每个 CPU 维护一个空闲链表，每个链表配备自己的锁
如果某个 CPU 的空闲链表为空，另一个 CPU 的链表仍有空闲内存，则该 CPU “窃取”其他 CPU 的空闲页

首先是为每个 CPU 维护一个空闲链表，并配备锁：

struct {
	struct spinlock lock;
	struct run *freelist;
} kmem[NCPU];

void kinit() {
	for (int i = 0; i < NCPU; ++i) {
		initlock(&kmem[i].lock, "kmem");
	}
	freerange(end, (void *)PHYSTOP);
}

这里将每个锁都命名为 keme 也是没问题的

修改 kfree()，使其将空闲内存分配给当前 CPU 的空闲链表：

void kfree(void *pa) {
	struct run *r;
	
	if (((uint64)pa % PGSIZE) != 0 || (char *)pa < end || (uint64)pa >= PHYSTOP)
		panic("kfree");
	
	// Fill with junk to catch dangling refs.
	memset(pa, 1, PGSIZE);
	
	r = (struct run *)pa;
	
	push_off();
	int icpu = cpuid();
	pop_off();
	
	acquire(&kmem[icpu].lock);
	r->next = kmem[icpu].freelist;
	kmem[icpu].freelist = r;
	release(&kmem[icpu].lock);
}

调用 cpuid() 时需要禁用中断，这样才能保证其结果准确

修改 kalloc()，使其能够在链表为空时“窃取”别的 CPU 的内存：

void *kalloc(void) {
	struct run *r;
	
	push_off();
	int icpu = cpuid();
	pop_off();  
	
	acquire(&kmem[icpu].lock);
	r = kmem[icpu].freelist;
	if (r)
		kmem[icpu].freelist = r->next;
	if (!r) {
		for (int i = 0; i < NCPU; ++i) {
			if (i == icpu) // 当前cpu
				continue;
			acquire(&kmem[i].lock);
			r = kmem[i].freelist;
			if (r) {
				kmem[i].freelist = r->next;
				release(&kmem[i].lock);
				break;
			}
			release(&kmem[i].lock);
		}
	}
	release(&kmem[icpu].lock);
	  
	if (r)
		memset((char *)r, 5, PGSIZE); // fill with junk
	return (void *)r;
}

!r 代表当前 CPU 链表已空，需要窃取内存
遍历其他 CPU 获取空闲内存

Buffer cache

实验要求：

用哈希表代替 LRU 双向链表，为每个桶分配锁，从而减少对整体锁的争用
使用 ticks 来寻找 LRU buf

首先修改 struct buf：

struct buf {
	int valid; // has data been read from disk?
	int disk; // does disk "own" buf?
	uint dev;
	uint blockno;
	struct sleeplock lock;
	uint refcnt;
	// struct buf *prev; // LRU cache list
	struct buf *next;
	uchar data[BSIZE];
	  
	uint timestamp;
};

不需要使用 prev
增加 timestamp 来表示其最近被使用的时间

声明变量和数据结构：

extern uint ticks;
  
#define NBUCKET 13
#define NBUF (NBUCKET * 3)
  
struct {
	struct spinlock lock;
	struct buf buf[NBUF];
} bcache;
 
struct bucket {
	struct spinlock lock;
	struct buf head;
} hashtable[NBUCKET];

uint hash(uint blockno) { return blockno % NBUCKET; }

这里放弃了原来声明的 NBUF，这样改可以平均桶的分配
全局锁依然有存在的必要，比如保护 buf

接着在 binit() 中所有的锁以及初始化哈希表：

void binit(void) {
	struct buf *b;
	  
	initlock(&bcache.lock, "bcache");
	
	for (b = bcache.buf; b < bcache.buf + NBUF; b++) {
		initsleeplock(&b->lock, "buffer");
	}
	
	b = bcache.buf;
	for (int i = 0; i < NBUCKET; i++) {
		initlock(&hashtable[i].lock, "bcache_bucket");
		for (int j = 0; j < NBUF / NBUCKET; j++) {
			b->blockno = i; // hash(b) should equal to i
			b->next = hashtable[i].head.next;
			hashtable[i].head.next = b;
			b++;
		}
	}
}

这里将所有 buf 平均分配到每个桶

然后是核心函数 bget()，需要在哈希表中找到目标 buf，如果没有缓存的话需要分配 LRU buf：

static struct buf *bget(uint dev, uint blockno) {
	// printf("dev: %d blockno: %d Status: ", dev, blockno);
	struct buf *b;
	
	int idx = hash(blockno);
	struct bucket *bucket = hashtable + idx;
	acquire(&bucket->lock);
	
	// Is the block already cached?
	for (b = bucket->head.next; b != 0; b = b->next) {
		if (b->dev == dev && b->blockno == blockno) {
			b->refcnt++;
			b->timestamp = ticks;
			release(&bucket->lock);
			acquiresleep(&b->lock);
			return b;
		}
	}
	  
	// Not cached.
	// Look for LRU buf in current bucket
	uint min_time = __UINT32_MAX__;
	struct buf *replace_buf = 0;
	for (b = bucket->head.next; b != 0; b = b->next) {
		if (b->refcnt == 0 && b->timestamp < min_time) {
			replace_buf = b;
			min_time = b->timestamp;
		}
	}
	if (replace_buf) {
		goto find;
	}
	
	// Try to find in other bucket.
	acquire(&bcache.lock);
	refind:
	for (b = bcache.buf; b < bcache.buf + NBUF; b++) {
		if (b->refcnt == 0 && b->timestamp < min_time) {
			replace_buf = b;
			min_time = b->timestamp;
		}
	}
	if (replace_buf) {
		// remove from old bucket
		int ridx = hash(replace_buf->blockno);
		acquire(&hashtable[ridx].lock);
		if (replace_buf->refcnt != 1) // be used in another bucket's local find between finded and acquire
		{
			release(&hashtable[ridx].lock);
			goto refind;
		}
		struct buf *pre = &hashtable[ridx].head;
		struct buf *p = hashtable[ridx].head.next;
		while (p != replace_buf) {
			pre = pre->next;
			p = p->next;
		}
		pre->next = p->next;
		release(&hashtable[ridx].lock);
		// add to current bucket
		replace_buf->next = hashtable[idx].head.next;
		hashtable[idx].head.next = replace_buf;
		release(&bcache.lock);
		goto find;
	} else {
		panic("bget: no buffers");
	}
	
	find:
	replace_buf->dev = dev;
	replace_buf->blockno = blockno;
	replace_buf->valid = 0;
	replace_buf->refcnt = 1;
	release(&bucket->lock);
	acquiresleep(&replace_buf->lock);
	return replace_buf;
}

这里便可以看出对哈希表和 buf 链表分别上锁的好处：可以直接遍历 buf 链表，只需要维护一个锁。如果遍历哈希表，那我会出现同时持有两个桶的锁的情况，存在两个导致死锁的风险：

如果进程又遍历到当前桶，会重复获取该桶的锁
如果两个进程互相获取对方所持有的锁，那么也会造成死锁。这样的话就需要固定获取锁的顺序，如先获取桶号小的锁，再获取大的

接下来是 brelse()，减少计数，如果引用为零的话表示空闲，更新其时间戳：

void brelse(struct buf *b) {
	if (!holdingsleep(&b->lock))
		panic("brelse");
	
	releasesleep(&b->lock);
	  
	int idx = hash(b->blockno);
	
	acquire(&hashtable[idx].lock);
	b->refcnt--;
	if (b->refcnt == 0) {
		// no one is waiting for it.
		b->timestamp = ticks;
	}
	
	release(&hashtable[idx].lock);
}

剩余的 bpin() / bunpin() 只需更新锁的获取就行：

void bpin(struct buf *b) {
	int idx = hash(b->blockno);
	acquire(&hashtable[idx].lock);
	b->refcnt++;
	release(&hashtable[idx].lock);
}

void bunpin(struct buf *b) {
	int idx = hash( b->blockno);
	acquire(&hashtable[idx].lock);
	b->refcnt--;
	release(&hashtable[idx].lock);
}

测试结果：

$ bcachetest
start test0
test0 results:
--- lock kmem/bcache stats
lock: kmem: #test-and-set 0 #acquire() 32928
lock: kmem: #test-and-set 0 #acquire() 129
lock: kmem: #test-and-set 0 #acquire() 22
lock: bcache_bucket: #test-and-set 0 #acquire() 6176
lock: bcache_bucket: #test-and-set 0 #acquire() 6186
lock: bcache_bucket: #test-and-set 0 #acquire() 6324
lock: bcache_bucket: #test-and-set 0 #acquire() 6320
lock: bcache_bucket: #test-and-set 0 #acquire() 6320
lock: bcache_bucket: #test-and-set 0 #acquire() 6310
lock: bcache_bucket: #test-and-set 0 #acquire() 4532
lock: bcache_bucket: #test-and-set 0 #acquire() 5300
lock: bcache_bucket: #test-and-set 0 #acquire() 2112
lock: bcache_bucket: #test-and-set 0 #acquire() 4118
lock: bcache_bucket: #test-and-set 0 #acquire() 2120
lock: bcache_bucket: #test-and-set 0 #acquire() 4122
lock: bcache_bucket: #test-and-set 0 #acquire() 4170
--- top 5 contended locks:
lock: virtio_disk: #test-and-set 1007951 #acquire() 1068
lock: proc: #test-and-set 56089 #acquire() 404689
lock: proc: #test-and-set 43046 #acquire() 384260
lock: proc: #test-and-set 33896 #acquire() 384248
lock: proc: #test-and-set 32820 #acquire() 384266
tot= 0
test0: OK
start test1
test1 OK

参考

刚开始做 Buffer cache 时，思路就是将哈希表集成在 bcache 中，并在 bget() 中遍历哈希表来获取 LRU buf。这样做不仅复杂度提高，还经常出现让人摸不得头脑的死锁和 bug，从中午写到半夜也没有通过全部测试。看了博主星见遥的实现后感觉非常巧妙，邃借鉴并在此说明。

MIT6.S081 Lab thread

Sat, 09 Aug 2025 14:25:15 GMT

Uthread: switching between threads

目的是实现线程的创建和切换。

在 uthread_switch.S中保存和恢复上下文（仿照 swtch.S）：

thread_switch:

/* YOUR CODE HERE */
	sd ra, 0(a0)
	sd sp, 8(a0)
	sd s0, 16(a0)
	sd s1, 24(a0)
	sd s2, 32(a0)
	sd s3, 40(a0)
	sd s4, 48(a0)
	sd s5, 56(a0)	
	sd s6, 64(a0)	
	sd s7, 72(a0)
	sd s8, 80(a0)
	sd s9, 88(a0)
	sd s10, 96(a0)
	sd s11, 104(a0)
	
	ld ra, 0(a1)
	ld sp, 8(a1)
	ld s0, 16(a1)
	ld s1, 24(a1)
	ld s2, 32(a1)
	ld s3, 40(a1)
	ld s4, 48(a1)
	ld s5, 56(a1)
	ld s6, 64(a1)
	ld s7, 72(a1)
	ld s8, 80(a1)
	ld s9, 88(a1)
	ld s10, 96(a1)
	ld s11, 104(a1)
	
	ret /* return to ra */

在 uthread.c 的 struct thread 中添加 struct context：

struct thread {
	char stack[STACK_SIZE]; /* the thread's stack */
	int state; /* FREE, RUNNING, RUNNABLE */
	
	struct context context;
};

在 thread_create() 中初始化线程的栈和返回地址：

void thread_create(void (*func)()) {
	struct thread *t;
	
	for (t = all_thread; t < all_thread + MAX_THREAD; t++) {
		if (t->state == FREE)
			break;
	}
	
	t->state = RUNNABLE;
	// YOUR CODE HERE
	t->context.ra = (uint64) func;
	t->context.sp = (uint64) t->stack + STACK_SIZE;
}

这里实际上是在该进程的内存空间（xv6 中一个进程中运行一个线程）中显式声明了一块内存区域作为该线程的栈。在 thread_create() 中进行初始化后，之后运行 thread_switch() 会恢复上下文，从而达到在指定栈运行线程函数的效果。

在 thread_schedule 中调用 thread_switch()：

thread_switch((uint64) &t->context, (uint64) &next_thread->context);

Using threads

目的是使用锁来解决 put 中存在的竞争条件。

如果两个线程同时 put() 同一个桶，那么可能会出现：

线程 A 检查 table[i]，发现 key 不存在，准备插入
线程 B 检查 table[i]，发现 key 不存在，也准备插入
线程 A 执行 insert() ，新节点被插入到桶链表头部
线程 B 执行 insert()，如果此时线程 A 还未更新链表头，那么线程 A 的节点将被线程 B 覆盖这导致对应的 key 并没有被插入，被 get() 归为 missing

那么为什么不可能是 put() 和 get() 发生竞争条件？因为在 main() 中 put() 和 get() 的执行是严格分离的两个阶段，只有在执行完 put() 后才会执行 get()，因此这两个函数不会发生竞争条件。

通过对 put() 加锁来实现其原子性：

pthread_mutex_t locks[NBUCKET]; // 为每个桶增加锁

// 在 main() 中初始化锁
for (int i = 0; i < NBUCKET; ++i) {
	pthread_mutex_init(&locks[i], NULL);
}

// 在 put() 中使用锁
static void put(int key, int value) {
	int i = key % NBUCKET;
	
	// is the key already present?
	struct entry* e = 0;
	pthread_mutex_lock(&locks[i]);
	for (e = table[i]; e != 0; e = e->next) {
		if (e->key == key)
			break;
	}
	if (e) {
		// update the existing key.
		e->value = value;
	} else {
		// the new is new.
		insert(key, value, &table[i], table[i]);
	}
	pthread_mutex_unlock(&locks[i]);
}

检查和插入之间同样存在竞争，因此临界区必须将其全部覆盖

由于 main() 中的顺序执行，因此不需要为 get() 加锁。

Barrier

目的是实现 barrier()，用于同步所有线程。

感觉目的很明确，逻辑也比前两题简单：

static void barrier() {
	// YOUR CODE HERE
	//
	// Block until all threads have called barrier() and
	// then increment bstate.round.
	//
	pthread_mutex_lock(&bstate.barrier_mutex);
	bstate.nthread++;
	if (bstate.nthread == nthread) {
		bstate.round++;
		bstate.nthread = 0;
		pthread_cond_broadcast(&bstate.barrier_cond);
	} else {
		pthread_cond_wait(&bstate.barrier_cond, &bstate.barrier_mutex);
	}
	pthread_mutex_unlock(&bstate.barrier_mutex);
}

MIT6.S081 Lab cow

Thu, 31 Jul 2025 14:18:43 GMT

参考博客：Xiao Fan
RISC-V手册

Copy-on-Write Fork 介绍

基本流程

初始状态（fork() 刚完成）
- 父进程与子进程共享所有的物理页，但它们的 PTE 标记为只读（PTE_W=0）
- 任何写入尝试都会触发存储页错误
写入触发存储页错误（trap handler 介入）
- 检查该页的引用计数：
  - 如果仅当前进程引用该页（无其他共享者），则直接恢复 PTE_W 标志，允许写入，无需复制
  - 如果多个进程共享该页，则：
    - 分配一个新物理页
    - 复制原页内容到新页
    - 修改当前进程的 PTE，使其指向新页，并设置 PTE_W=1
- 恢复执行：重新执行触发页错误的执行，此时写入会成功

关键机制

页引用计数
- 每个物理页维护一个引用计数，记录有多少进程的 PTE 指向它
- fork() 时，所有共享页的引用计数+1
- COW 复制后：
  - 原页的引用计数-1
  - 新页的引用计数=1（仅当前进程使用）
- 释放内存时：只有当引用计数 =0 时，才真正释放物理页
存储页错误的优化
- 如果仅当前进程引用该页（引用计数=1），则无需复制，直接恢复 PTE_W=1 即可
  - 例如：父进程 fork() 后，子进程 exec() 丢弃了大部分内存，此时父进程写入自己的内存时可能无需复制

uvmcopy()

在 kernel/vm.c 的 uvmcopy()函数中，需要进行以下修改：

将父进程的物理页映射到子进程，而不是分配新页面；
清除父进程和子进程的 PTE_W 位
设置新添加的 PTE_COW位

其中，在 PTE 的 RSW 处可以设置为我们的 PTE_COW 位，以表明该物理页是COW Fork机制。

在 riscv.h 中添加 PTE_COW 位：

#define PTE_COW   (1L << 8)

修改 uvmcopy()函数：

int
uvmcopy(pagetable_t old, pagetable_t new, uint64 sz)
{
  pte_t *pte;
  uint64 pa, i;

  for(i = 0; i < sz; i += PGSIZE){
    if((pte = walk(old, i, 0)) == 0)
      panic("uvmcopy: pte should exist");
    if((*pte & PTE_V) == 0)
      panic("uvmcopy: page not present");

    pa = PTE2PA(*pte);
    *pte = (*pte & ~PTE_W) | PTE_COW; // 设置父页flags
    if(mappages(new, i, PGSIZE, (uint64)pa, PTE_FLAGS(*pte)) != 0){ // 设置映射和子页flags
      goto err;
    }
    refcnt_add(pa); // 增加引用计数
  }
  return 0;

 err:
  uvmunmap(new, 0, i / PGSIZE, 1);
  return -1;
}

usertrap()

接下来在 kernel/trap.c 的 usertrap() 函数中添加对存储页错误的处理：

} else if (r_scause() == 15) { // 存储页错误
    uint64 va = r_stval();
    
    if (va >= MAXVA || (va <= PGROUNDDOWN(p->trapframe->sp) && va >= PGROUNDDOWN(p->trapframe->sp) - PGSIZE))
      p->killed = 1;
    else if (refcnt_new(va, p->pagetable) == -1) // 空闲内存不足，终止进程
      p->killed = 1;
  }

注意这里需要检查虚拟地址是否越界，或者处于 guard page 当中，否则 usertests 无法通过。

kalloc.c

按照 COW 的逻辑，我们需要维护每一个物理页的引用计数 refcnt。

在 kalloc.c 中声明数据结构和辅助函数：

struct {
  struct spinlock lock;
  uint cnt[(PHYSTOP - KERNBASE) / PGSIZE]; // 引用计数数组
} refcnt;

#define PA2IDX(pa) (((uint64)pa - KERNBASE) / PGSIZE) // 索引计算逻辑

// add cnt
void refcnt_add(uint64 pa) {
  acquire(&refcnt.lock);
  refcnt.cnt[PA2IDX(pa)]++;
  release(&refcnt.lock);
}

// set cnt
void refcnt_setter(uint64 pa, uint n) {
  refcnt.cnt[PA2IDX(pa)] = n;
}

// get cnt
uint refcnt_getter(uint64 pa) {
  return refcnt.cnt[PA2IDX(pa)];
}

// kalloc() without lock
void *
kalloc_nolock(void)
{
  struct run *r;

  acquire(&kmem.lock);
  r = kmem.freelist;
  if(r)
    kmem.freelist = r->next;
  release(&kmem.lock);

  if(r)
    memset((char*)r, 5, PGSIZE); // fill with junk
  
  if (r)
    refcnt.cnt[PA2IDX((uint64)r)]++;
  return (void*)r;
}

// create new physical page
int refcnt_new(uint64 va, pagetable_t pagetable) {
  pte_t *pte;
  uint64 pa;
  uint flags, cnt;

  va = PGROUNDDOWN(va);
  pte = walk(pagetable, va, 0);
  pa = PTE2PA(*pte);
  flags = PTE_FLAGS(*pte);

  if (!(flags & PTE_COW)) // 非COW页，不予处理
    return -2;

  acquire(&refcnt.lock);
  cnt = refcnt_getter(pa);
  if (cnt > 1) { // 多页则需要创建新页
    char *mem = kalloc_nolock();
    if (mem == 0) // 空闲内存不足
      goto bad;
    memmove(mem, (char *)pa, PGSIZE); // 复制旧页到新页
    uvmunmap(pagetable, va, 1, 0); // 需要旧页原有的映射
    if (mappages(pagetable, va, PGSIZE, (uint64)mem, (flags & ~PTE_COW) | PTE_W) != 0) { // 设置新映射
      kfree(mem);
      goto bad;
    }
    refcnt_setter(pa, cnt - 1); // 旧页引用计数-1
  } else { // 单页直接写入
    *pte = (*pte & ~PTE_COW) | PTE_W;
  }
  release(&refcnt.lock);
  return 0;

  bad:
    release(&refcnt.lock);
    return -1;
}

refcnt_new() 中只能使用 kalloc_nolock()，因为其已经声明 acquire(&refcnt.lock)，如果直接使用 kalloc()，里面会再一次声明，便会触发 panic("acquire")

kinit() 中初始化 refcnt：

void
kinit()
{
  initlock(&kmem.lock, "kmem");
  initlock(&refcnt.lock, "refcnt");
  memset(refcnt.cnt, 0, sizeof(refcnt.cnt)); // 数组初始化为0
  freerange(end, (void*)PHYSTOP);
}

在 kalloc() 初始化引用计数：

void *kalloc(void)
{
  struct run *r;

  acquire(&kmem.lock);
  r = kmem.freelist;
  if(r) {
    kmem.freelist = r->next;
    acquire(&refcount.lock);
    refcount.count[PA2IDX((uint64) r)] = 1; // 初始设置为1
    release(&refcount.lock);
  }
  release(&kmem.lock);

  if(r)
    memset((char*)r, 5, PGSIZE); // fill with junk
  return (void*)r;
}

修改 kfree() 的逻辑，只有引用计数为 0 时才释放物理内存：

void
kfree(void *pa)
{
  struct run *r;

  if(((uint64)pa % PGSIZE) != 0 || (char*)pa < end || (uint64)pa >= PHYSTOP)
    panic("kfree");

  acquire(&refcnt.lock);
  int cnt = refcnt_getter((uint64)pa);
  if (cnt > 1) { // 存在多个引用，不释放内存
    refcnt_setter((uint64)pa, cnt - 1);
    release(&refcnt.lock);
    return;
  }

  // 清零计数
  refcnt_setter((uint64)pa, 0);
  release(&refcnt.lock);

  // Fill with junk to catch dangling refs.
  memset(pa, 1, PGSIZE);

  r = (struct run*)pa;

  acquire(&kmem.lock);
  r->next = kmem.freelist;
  kmem.freelist = r;
  release(&kmem.lock);
}

更新 kalloc() 函数，使其分配内存时初始化计数：

void *kalloc(void)
{
  struct run *r;

  acquire(&kmem.lock);
  r = kmem.freelist;
  if(r)
    kmem.freelist = r->next;
  release(&kmem.lock);

  if(r)
    memset((char*)r, 5, PGSIZE); // fill with junk
  
  if (r)
    refcnt_add((uint64)r);
  return (void*)r;
}

copyout ()

最后需要修改 copyout()，使其当目标页为 COW 页时，分配一个新的物理页：

int copyout(pagetable_t pagetable, uint64 dstva, char *src, uint64 len)
{
  uint64 n, va0, pa0;
  pte_t *pte;

  while(len > 0){
    va0 = PGROUNDDOWN(dstva);
    pa0 = walkaddr(pagetable, va0);
    if(pa0 == 0)
      return -1;

    pte = walk(pagetable, va0, 0);
    if (*pte & PTE_COW) {
      refcnt_new(va0, pagetable);
      pa0 = PTE2PA(*pte); // 需要更新pa0，否则还是写入原页
    }

    n = PGSIZE - (dstva - va0);
    if(n > len)
      n = len;
    memmove((void *)(pa0 + (dstva - va0)), src, n);

    len -= n;
    src += n;
    dstva = va0 + PGSIZE;
  }
  return 0;
}

MIT6.S081 Lab traps

Fri, 25 Jul 2025 18:52:32 GMT

Backtrace

题目要求：编译器会在每个栈帧中放置一个帧指针，该指针保存着调用者帧指针的地址。您的 backtrace 应利用这些帧指针遍历堆栈，并打印每个栈帧中保存的返回地址。

将 backtrace() 原型添加到 defs.h 中。在 kernel/riscv.h 中添加函数，以获取帧指针：

static inline uint64
r_fp()
{
  uint64 x;
  asm volatile("mv %0, s0" : "=r" (x) );
  return x;
}

在 kernel/printf.c 中添加 backtrace 函数：

void
backtrace(void) {
  printf("backtrace:\n");
  uint64 fp = r_fp();
  uint64 top = PGROUNDUP(fp);

  while (fp < top) {
    uint64 ra = *(uint64*)(fp - 8);
    printf("%p\n", &ra);
    fp = *(uint64*)(fp - 16);
  }
}

由于是从低地址向高地址遍历栈帧，因此只需检查 PGROUNDUP(fp) 边界即可；
需要注意返回地址位于 *(fp-8) 处，帧指针位于 *(fp-16) 处。

在 printf.c 的 panic() 中添加 backtrace()：

void
panic(char *s)
{
  pr.locking = 0;
  printf("panic: ");
  printf(s);
  printf("\n");
  backtrace();
  panicked = 1; // freeze uart output from other CPUs
  for(;;)
    ;
}

Alarm

功能概述：

sigalarm(n, fn) ：
- 设置每隔 n 个 CPU 时间 ticks 调用一次 fn 函数
- 当 fn 返回后，程序从被中断的地方继续执行
- 如果调用 sigalarm(0, 0)，则停止警报调用
sigreturn() ：
- 由警报处理函数调用，用于恢复被中断的上下文

首先需要理解整个系统的调用流程：

在 alarmtest 中初始化对 sigalarm(2, periodic) 的调用，内核会在 proc 中记录这些参数；
每个时钟中断(tick)发生时：
- 硬件触发中断-> 执行 usertrap
- 根据条件 which_dev == 2 判断时钟中断
- 只有 ticks 计数器等于初始化设置的 interval 时才调用 periodic 处理函数
由于我们将 usertrap 的下一步变成了执行 periodic 处理函数而不是 usertrapret，因此需要在 periodic 中调用 sigreturn() 函数，从而进入恢复阶段
在 sigreturn() 中我们需要将保存的上下文恢复和重置一些状态

一般方案

初始设置：

在 MAKEFILE 的添加 alarmtest.c；
在 user/user.h 中添加函数声明：

int sigalarm(int ticks, void (*handler)());
int sigreturn(void);

更新 user/usys.pl、kernel/syscall.h 和 kernel/syscall.c。

proc 添加变量：

 int interval;             // 警报间隔
 void (*handler)();        // 处理函数指针，无返回值和参数传入
 int ticks;                // 距离上次警报的ticks数
 int in_handler;           // 是否在处理函数中
 struct trapframe *alarm_trapframe; // 保存原始的trapframe

in_handler 防止处理程序被重复调用
这里使用 alarm_trapframe 来避免了冗长的手动保存寄存器，保持代码整洁且符合原有的 xv6 风格，但是缺点是增加了内存占用以及性能开销。

在 proc.c 中添加对 alarm_trapframe 的分配和释放：

static struct proc*
allocproc(void)
{
	... // 其它代码
	
	// Allocate a trapframe page.
	if(((p->trapframe = (struct trapframe *)kalloc()) == 0) 
  || (p->alarm_trapframe = (struct trapframe *)kalloc()) == 0) {
    freeproc(p);
    release(&p->lock);
    return 0;
  }
  
  ...
}

在 usertrap 中添加对时钟中断的处理：

} else if ((which_dev = devintr()) != 0) {
    // ok
    if (which_dev == 2 && p->in_handler == 0) {
      p->ticks++;
      if ((p->ticks == p->interval) && (p->interval != 0)) {
        p->in_handler = 1; // 设置为在处理函数中
        p->ticks = 0;      // 重置ticks计数
        p->alarm_trapframe = memmove(p->alarm_trapframe, p->trapframe, sizeof(*(p->trapframe)));
        p->trapframe->epc = (uint64)p->handler;
      }
    }
  }

将 handler 写入 p->trapframe->epc ，使得从 usertrap 返回时开始执行 handler
将整个 trapframe 保存至 alarm_trapframe

在 kernel/sysproc.c 中添加 sigalarm 和 sigreturn 的实现：

uint64 sys_sigalarm(void) {
  int ticks;
  uint64 handler;
  if (argint(0, &ticks) < 0 || argaddr(1, &handler) < 0)
    return -1;
  struct proc *p = myproc();
  if (ticks < 0)
    return -1;
  p->interval = ticks;              // 设置警报间隔
  p->handler = (void (*)())handler; // 设置警报处理函数
  return 0;
}

uint64 sys_sigretrun(void) {
  struct proc *p = myproc();
  memmove(p->trapframe, p->alarm_trapframe, sizeof(*p->alarm_trapframe));
  p->in_handler = 0; // 重置为不在处理函数中
  return 0;
}

优化

由于处理函数 periodic 的逻辑非常简答，不会修改其它的用户寄存器，因此不需要保存全部的用户寄存器，而是仅保存几个重要的寄存器。

proc：

int interval;             // 警报间隔
void (*handler)();        // 处理函数指针，无返回值和参数传入
int ticks;                // 距离上次警报的ticks数
int in_handler;           // 是否在处理函数中
uint64 alarm_epc;         // 保存用户程序的epc
uint64 alarm_sp;          // 保存sp
uint64 alarm_ra;          // 返回地址
uint64 alarm_a0;          // 参数

usertrap：

} else if ((which_dev = devintr()) != 0) {
    // ok
    if (which_dev == 2 && p->in_handler == 0) {
      p->ticks++;
      if ((p->ticks == p->interval) && (p->interval != 0)) {
        p->in_handler = 1; // 设置为在处理函数中
        p->ticks = 0;      // 重置ticks计数
        p->alarm_epc = p->trapframe->epc;
        p->alarm_sp = p->trapframe->sp;
        p->alarm_a0 = p->trapframe->a0;
        p->alarm_ra = p->trapframe->ra;
        p->trapframe->epc = (uint64)p->handler;
      }
    }
  }

sysproc：

uint64 sys_sigalarm(void) {
  int ticks;
  uint64 handler;
  if (argint(0, &ticks) < 0 || argaddr(1, &handler) < 0)
    return -1;
  struct proc *p = myproc();
  if (ticks < 0)
    return -1;
  p->interval = ticks;              // 设置警报间隔
  p->handler = (void (*)())handler; // 设置警报处理函数
  return 0;
}

uint64 sys_sigretrun(void) {
  struct proc *p = myproc();
  p->trapframe->epc = p->alarm_epc;
  p->trapframe->sp = p->alarm_sp;
  p->trapframe->ra = p->alarm_ra;
  p->trapframe->a0 = p->alarm_a0;
  p->in_handler = 0; // 重置为不在处理函数中
  return 0;
}

参考

Xiao Fan

MIT6.S081 Lab pgtbl

Fri, 25 Jul 2025 18:48:14 GMT

Speed up system calls

需要在创建进程是在 USYSCALL 处映射一个只读页面，在改位置存储一个 struct usyscall，并初始化为当前进程的 PID。

#define USYSCALL (TRAPFRAME - PGSIZE)

struct usyscall {
  int pid;  // Process ID
};

首先是需要在 proc.c 的 struct proc 中添加 usyscall 变量：

struct usyscall *usyscall;   // Usyscall

在 allocproc() 中为其分配物理内存，并初始化数据：

// Allocate a usyscall page.
  if ((p->usyscall = (struct usyscall *)kalloc()) == 0) {
    freeproc(p);
    release(&p->lock);
    return 0;
  }
  p->usyscall->pid = p->pid;

在 proc_pagetable() 中调用 mappages() 插入映射：

// map the usyscall at USYSCALL
  if (mappages(pagetable, USYSCALL, PGSIZE, 
              (uint64)(p->usyscall), PTE_R | PTE_U) < 0) {
    uvmunmap(pagetable, USYSCALL, 1, 0);
    uvmfree(pagetable, 0);
    return 0;
  }

注意这里需要添加 PTE_U，使得用户能够访问

在 freeproc 中释放物理页：

if (p->usyscall)
    kfree((void*)p->usyscall);
  p->usyscall = 0;

在 proc_freepagetable 中解除页表映射：

void proc_freepagetable(pagetable_t pagetable, uint64 sz)
{
  uvmunmap(pagetable, TRAMPOLINE, 1, 0);
  uvmunmap(pagetable, TRAPFRAME, 1, 0);
  uvmunmap(pagetable, USYSCALL, 1, 0);
  uvmfree(pagetable, sz);
}

Print a page table

定义一个 vmprint() 的函数，接受一个 pagetable_t 参数，并以指定格式打印该页表。

在 exec.c 添加

if (p->pid == 1)
   vmprint(p->pagetable);

在 kernel/def.h 中添加 vmprint() 的原型：

void            vmprint(pagetable_t);

这里使用递归来实现，但是需要根据是否是最底层页表来判断是否继续向下递归，这里就需要一层判断：如果 PTE 没有 R/W/X 权限，说明它是一个中间页表项（指向下一层页表）；反之则是最底层页表（指向实际的物理页）。

在 vm.c 中实现 vmprint() 函数：

void vmprint_helper(pagetable_t pagetable, int level) {
  for (int i = 0; i < 512; ++i) {
    pte_t pte = pagetable[i];
    if ((pte & PTE_V) && (pte & (PTE_R | PTE_W | PTE_X)) == 0) { // 中间页表项
      uint64 child = PTE2PA(pte); // 下一级页表的物理地址
      for (int j = 0; j <= level; ++j) { // 根据当前level打印缩进
        printf("..");
        if (j + 1 <= level)
          printf(" ");
      }
      printf("%d: pte %p pa %p\n", i, pte, child);
      vmprint_helper((pagetable_t)child, level + 1); // 递归处理下一级页表
    } else if (pte & PTE_V) { // 指向实际的物理页（最底层页表）
      uint64 child = PTE2PA(pte);
      printf(".. .. ..%d: pte %p pa %p\n", i, pte, child);
    }
  }
}

void vmprint(pagetable_t pagetable) {
  printf("page table %p\n", pagetable);
  vmprint_helper(pagetable, 0);
}

PTE2PA 在 riscv.h 中定义，用于物理地址（PA）和页表项（PTE）之间的转换。

// shift a physical address to the right place for a PTE.
#define PA2PTE(pa) ((((uint64)pa) >> 12) << 10)
#define PTE2PA(pte) (((pte) >> 10) << 12)

Detecting which pages have been accessed

首先需要在 kernel/riscv. h 中定义 PTE_A。根据 RISC-V 手册，PTE_A 是第 6 位： ![[Pasted image 20250722062258.png]]

因此代码为

#define PTE_A (1L << 6) // 访问位

其次是在 kernel/sysproc. c 中实现 sys_pgaccess()：

uint64 sys_pageccess(void) {
  uint64 start; // 起始虚拟地址
  int len;   // 页面数量
  uint64 mask;// 位掩码缓冲区地址

  // 获取参数
  if (argaddr(0, &start) < 0 || argint(1, &len) < 0 
    || argaddr(2, &mask) < 0)
    return -1;
  
  // 对应掩码缓冲区长度
  if (len < 1 || len > 64)
    return -1;

  struct proc *p = myproc();
  pagetable_t pagetable = p->pagetable;

  // 在内核中创建临时缓冲区存储结果
  uint64 abits = 0;

  for (int i = 0; i < len; ++i) {
    uint64 va = start + i * PGSIZE;
    pte_t *pte = walk(pagetable, va, 0); // 获取对应的PTE
    
    if (pte == 0) continue; // PTE不存在

    if (*pte & PTE_A) {
      abits |= (1 << i);
      *pte &= ~PTE_A; // 清除
    }
  }
  
  // 复制到用户空间
  if (copyout(pagetable, mask, (char *)&abits, sizeof(abits)) < 0)
    return -1;
}

MIT6.S081 Lab syscall

Mon, 21 Jul 2025 17:26:24 GMT

系统调用流程概述

用户程序调用用户空间包装函数（位于 user.h）
包装函数通过汇编指令触发软中断
内核终端处理程序根据系统调用号（位于 syscall.h）分派到正确的系统调用实现（位于 syscall.c）
结果返回给用户程序

其中，usys.pl 为每个系统调用生成统一的汇编代码模板，处理系统调用号和参数传递，触发软中断进入内核态。

Sysetm call tracing

要求：

新增 trace 系统调用
- 接受一个整数参数 mask，二进制位用于指定要追踪的系统调用。
- 例如：trace(1 << SYS_fork) 表示追踪 fork 系统调用
修改内核以输出追踪信息
- 当被追踪的系统调用即将返回时，内核需打印一行信息，包括：
  - 进程 ID
  - 系统调用名称
  - 返回值
- 仅当系统调用编号在 mask 中对应的位被设置时，才输出信息。
追踪的继承性
- trace 调用后，当前进程及后续通过 fork 创建的子进程均启用追踪，但不得影响其它无关进程

首先是添加系统调用的声明：

// user.h
int trace(int);

// usys.S
entry("trace");

// syscall.h
#define SYS_trace  22

其次是实现内核调用 sys_trace：

// 需要在proc.h为struct proc添加新变量
struct proc {
	...
	int trace_mask; // 进程要追踪的掩码
}

// 在sysproc.c中添加sys_trace()函数
// trace the system call from user space
uint64
sys_trace(void) {
  int mask;

  if (argint(0, &mask) < 0) // 获取mask
    return -1;
  myproc()->trace_mask = mask;
  return 0;
}

在 kernel/proc.c 中修改 fork()，使得子进程能够继承父进程的跟踪掩码：

int fork(void) {
	...
	np->trace_mask = p->trace_mask;
}

最后在 kernel/syscall.c 中修改 syscall() 函数，在系统调用执行完成后检查 trace_mask，若当前系统调用编号被设置，则打印追踪信息：

void syscall(void)
{
  int num;
  struct proc *p = myproc();
  // 系统调用名称数组，用于索引
  char* syscall_name[22] = {"fork", "exit", "wait", "pipe", "read", 
  "kill", "exec", "fstat", "chdir", "dup", "getpid", "sbrk", "sleep", 
  "uptime", "open", "write", "mknod", "unlink", "link", "mkdir", "close", 
  "trace"};

  num = p->trapframe->a7;
  if(num > 0 && num < NELEM(syscalls) && syscalls[num]) {
    p->trapframe->a0 = syscalls[num]();
    if ((1 << num) & (p->trace_mask)) // 检查当前调用是否被追踪
      printf("%d: syscall %s -> %d\n", p->pid, syscall_name[num - 1], p->trapframe->a0);
  } else {
    printf("%d %s: unknown sys call %d\n",
            p->pid, p->name, num);
    p->trapframe->a0 = -1;
  }
}

Sysinfo

系统调用声明

要求：新增 sysinfo 的系统调用，其参数为 struct sysinfo*（声明在 kernel/sysinfo.h），要求填充该结构体。

按照之前的步骤添加声明，唯一不同的是在 user/user.h 中需要声明 struct sysinfo 的存在：

struct sysinfo;
...
int sysinfo(struct sysinfo*);

收集空闲内存量

在 kernel/kalloc.c 中存在以下声明：

struct run {
  struct run *next;
};

struct {
  struct spinlock lock;
  struct run *freelist;
} kmem;

由于物理内存中被分成了页进行管理，这里实际上是用链表来存储空闲的内存页。其中 freelist 为头节点，而 struct run 定义了一个链表节点结构，这里实现为单链表。于是我们可以据此计算出空闲空间的大小：

// get the free memory size of user space
uint64 freememSize(void) {
  struct run *r = kmem.freelist;
  uint64 i = 0; // 空闲页的数量
  while (r) {
    i++;
    r = r->next;
  }
  return i * PGSIZE;
}

收集进程数量

struct sysinfo 中的 nproc 设置为 state 不为 UNUSED 的进程数量。

在 kernel/proc.c 的头部声明了 struct proc proc[NPROC]，这相当于是进程数组，因此我们只需要遍历数组即可：`

// get the num of procs that aren't UNUSED.
uint64 nproc_active(void) {
  int i = 0;
  uint64 n = 0;
  while (i < NPROC) {
    if (proc[i].state != UNUSED) 
      n++;
    i++;
  }
  return n;
}

实现 sysinfo

在 kernel/sysproc.c 中添加 sys_sysinfo 函数：

// collects information about the running system.
uint64
sys_sysinfo(void) {
  uint64 st; // 指向 struct sysinfo 的指针
  struct sysinfo sf;

  if (argaddr(0, &st) < 0) // 获取用户空间的目标虚拟地址
    return -1;
  sf.freemem = freememSize();
  sf.nproc = nproc_active();
  if (copyout(myproc()->pagetable, st, (char *)&sf, sizeof(sf)) < 0)
    return -1;
  return 0;
}

之所以需要用到 copyout ，是因为我们传递给 sysinfo 函数的参数是一个用户空间的指针，而我们的 sys_sysinfo 函数是内核函数，其运行在内核空间，在其内填充的 struct sysinfo 也位于内核空间，用户空间的指针无法直接访问。而 copyout 函数的作用就是将内核空间的数据复制到用户空间。

copyout 函数的用法（可以参考 kernel/sysfile.c 的 sys_fstat() 和 kernel/file.c 的 filestat()）：

int copyout(pagetable_t pagetable, uint64 dstva, char *src, uint64 len);

pagetable：目标进程的页表
dstva：用户空间的目标虚拟地址
src：内核空间的元数据地址
len：要复制的字节数成功返回 0，失败返回 -1（如用户地址非法或不可写）。

MIT6.S081 Lab util

Thu, 17 Jul 2025 17:52:52 GMT

sleep

暂停用户指定的时钟周期数。

首先是获取命令行参数（可以参考 rm.c），将其转化成 int 类型后再进行系统调用。

#include "kernel/types.h"
#include "user/user.h"

int main(int argc, char *argv[]) {
  // 参数少于两个，需要报错
  if (argc < 2) {
    fprintf(2, "Usage: sleep seconds\n");
    exit(1);
  }
  
  // 系统调用，但是需要将char *转化成int
  sleep(atoi(argv[1]));
  exit(0);
}

pingpong

在两个进程之间传递一个字节。

关于管道的两个端口：

p[0]：0为标准输出（把0想象成Output），因此此端为输出端口
p[1]：1为标准输入（把1想象成Input），因此此端为输入端口

目的是通过管道实现进程之间的通信。创建两个管道，分别实现父对子通信和子对父通信，注意需要将用不到的管道关闭。

#include "kernel/types.h"
#include "user/user.h"

#define READEND 0
#define WRITEEDN 1

int main() {
  int p1[2]; // 父对子
  int p2[2]; // 子对父
  char buf[1]; // 用于临时存放进程间通信的一个字节

  pipe(p1);
  pipe(p2);
  
  if (fork() == 0) {
    // child progress
    close(p1[WRITEEDN]);
    close(p2[READEND]);
    read(p1[READEND], buf, 1);
    printf("%d: received ping\n", getpid());
    write(p2[WRITEEDN], " ", 1);
    close(p1[READEND]);
    close(p2[WRITEEDN]);
  } else {
    // parent progress
    close(p1[READEND]);
    close(p2[WRITEEDN]);
    write(p1[WRITEEDN], " ", 1);
    read(p2[READEND], buf, 1);
    printf("%d: received pong\n", getpid());
    close(p1[WRITEEDN]);
    close(p2[READEND]);
  }
  exit(0);
}

子进程需要从p1[0]端读取数据，并从p2[1]端发送数据
父进程需要从p1[1]端输入数据，并从p2[0]端读取数据

其中需要注意的是两个进程中 read 和 write 的顺序：必须存在一个进程的 write 在 read 之前，否则会导致进程阻塞或死锁。原因如下：

如果两个进程都是 read 在前，那么由于谁都没有发送数据，双方都会卡在 read 这一步；
在其它情况下，即使进程之间的执行顺序无从得知，但无论如何都会有一个或两个进程写入了数据，最终可以读取到。

primes

通过创建子进程和管道来筛选素数，就像一个筛网一样层层筛选：

由于xv6的文件描述符和进程数量有限，所以进程的最大数量为35，同时还要及时关闭用不到的文件描述符。

采取递归的方式来实现：

#include "kernel/types.h"
#include "user/user.h"

#define READEND 0
#define WRITEEND 1
#define MAXFEEDS 35

void child(int *pl); 

int main() {
  int p[2];
  pipe(p);

  if (fork() == 0) {
    child(p);
  } else {
    close(p[READEND]); // 关闭输出端口
    for (int i = 2; i <= MAXFEEDS; ++i) {
      write(p[WRITEEND], &i, sizeof(int));
    }
    close(p[WRITEEND]);
    wait((int *) 0);
  }
  exit(0);
}

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Winfinite-recursion"

void child(int *pl) {
  int pr[2];
  int n;
  close(pl[WRITEEND]);
  
  // 输入端口关闭时，read返回0，这代表当前处于最后一层递归
  int ret = read(pl[READEND], &n, sizeof(int));
  if (ret == 0) {
    exit(0);
  }

  pipe(pr);

  if (fork() == 0) {
    child(pr);
  } else {
    close(pr[READEND]);
    printf("prime %d\n", n);
    int prime = n;
    while (read(pl[READEND], &n, sizeof(int)) != 0) {
      if (n % prime != 0) {
        write(pr[WRITEEND], &n, sizeof(int));
      }
    }
    close(pr[WRITEEND]);
    wait((int *) 0);
  }
  exit(0);
}

#pragma GCC diagnostic pop

第17行需要关闭用不到的输出端口，但是为什么不在一开始即 if 之前关？因为子进程会复制父进程的文件描述符，如果一开始就关那么子进程将无法读取数据；
由于递归的终止条件是管道读取完毕(read返回0)，但这是运行时行为，编译器无法预知，于是其会认为此程序无限递归从而会引发报错，所以需要在 child 函数的前后加上编译指示。

find

在目录树中查找所有具有特定名称的文件，将其打印出来。此函数重点考查文件系统。

位于 fs.h 中的 struct dirent，用来描述目录条目：

// 文件名的最大长度
#define DIRSIZ 14

struct dirent {
  ushort inum; // 文件的i节点号，用于唯一标识文件。inum=0为空闲条目
  char name[DIRSIZ]; // 文件名
};

位于 stat.h 中的 struct stat，用来描述文件元数据：

#define T_DIR     1   // Directory
#define T_FILE    2   // File
#define T_DEVICE  3   // Device

struct stat {
  int dev;     // File system's disk device
  uint ino;    // Inode number
  short type;  // Type of file
  short nlink; // Number of links to file
  uint64 size; // Size of file in bytes
};

依旧是通过递归实现，代码与 ls.c 存在大量重叠：

#include "kernel/types.h"
#include "kernel/stat.h"
#include "user/user.h"
#include "kernel/fs.h"

void find(char *path, char *file);

int main(int argc, char *argv[]) {
  if (argc != 3) { // 只能为3个参数
    fprintf(2, "ERROR: need to pass only 2 arguments\n");
    exit(1);
  }

  find(argv[1], argv[2]);
  exit(0);
}

void find(char *path, char *file) {
  char buf[512], *p;
  int fd;
  struct dirent de;
  struct stat st;

  // 打开现有文件（只读）
  if ((fd = open(path, 0)) < 0) {
    fprintf(2, "find: cannot open %s\n", path);
    return;
  }

  // 将fd指定的文件元数据存储到st中
  if (fstat(fd, &st) < 0) {
    fprintf(2, "find: cannot stat %s\n", path);
    close(fd);
    return;
  }
  
  switch (st.type) {
    case T_FILE: // 如果是文件，直接打印名称
      if (strcmp(path + strlen(path) - strlen(file), file) == 0) {
        printf("%s\n", path);
      }
      break;
    case T_DIR: // 如果是目录，需要继续递归寻找，同时维护当前路径名
      if (strlen(path) + 1 + DIRSIZ + 1 > sizeof buf) {
        printf("find: path too long\n");
        break;
      } 
      strcpy(buf, path);
      p = buf + strlen(buf);
      *p++ = '/';
      while (read(fd, &de, sizeof(de)) == sizeof(de)) {
        if (de.inum == 0) // 空闲条目
          continue;
        memmove(p, de.name, DIRSIZ);
        p[DIRSIZ] = 0;
        if (strcmp(de.name, ".") != 0 && strcmp(de.name, "..") != 0) {
          // 子目录递归寻找
          find(buf, file);
        }
      }
      break;
  }
  close(fd); // 当前递归结束前记得要关闭文件描述符
}

xargs

从标准输入读取行数据，并为每行数据执行指定命令，将该行内容作为命令参数传入。

例如命令 echo hello too | xargs echo bye，由于使用了管道符，因此 xargs 的标准输入为 hello too，而指定命令则是 echo bye，组合时候也就是 echo bye hello too。

但是需要注意这里的命令参数是以行为单位（上面的例子只有一行标准输入），因此执行 echo "1\n2" | xargs -n 1 echo line 实际上是执行 echo line 1 和 echo line 2（其中 -n 1意为只传入一个命令）。

#include "kernel/types.h"
#include "user/user.h"
#include "kernel/param.h"

#define MAXLEN 100 // 参数的最大长度

int main(int argc, char *argv[]) {
  char *command = argv[1]; // 命令
  char bf;
  char paramv[MAXARG][MAXLEN]; // 存储行数据
  char *para[MAXARG]; 

  while (1) {
    int cnt = argc - 1;
    memset(paramv, 0, MAXARG * MAXLEN);
    // argv的第一个参数为程序本身，第二个才是命令
    for (int i = 1; i < argc - 1; ++i) {
      strcpy(paramv[i - 1], argv[i + 1]);
    }
    
    int ret;
    int cursor = 0;
    int flag = 0; // 标志位，为0时表示一个参数读取完毕

    while ((ret = read(0, &bf, 1)) > 0 && bf != '\n') {
      if (bf != ' ') {
        paramv[cnt][cursor++] = bf;
        flag = 1;
      } else if (bf == ' ' && flag == 1) {
        cnt++;
        cursor = 0;
        flag = 0;
      }
    }

    if (ret <= 0) { // 标准输入全部读取完
      break;
    }
    
    // 当前行参数已经读取完成
    for (int i = 0; i < MAXARG - 1; ++i) {
      para[i] = paramv[i];
    }
    para[MAXARG - 1] = 0;

    if (fork() == 0) {
      exec(command, para);
      exit(0);
    } else {
      wait((int *) 0);
    }
  }
  exit(0);
}

MIT6.S081 环境配置及踩坑

Fri, 11 Jul 2025 04:38:10 GMT

记录在配置MIT6.S081时所踩的坑。

系统为Archlinux物理机，环境如下：

学习的课程版本为Fall 2021，因为这一版本兼容新版本的 qemu，而2020版本不兼容，需要额外降级。

至于前置操作，已经有博主给出了详细的指导：MIT 6.S081 lab0：配置xv6环境+vscode调试，这里不再赘述。

但是我按照其步骤配置时，另外发现一个坑。即修改完 runcmd函数时再次运行 make qemu，出现以下报错：

解决方法是修改 user/usertests.c文件中的 rwsbrk()函数声明：

之后便可编译成功！

2025-06-27

Fri, 27 Jun 2025 17:39:51 GMT

今天是心心念念的期末考试结束日，经过了许多的折磨和挣扎后终于熬过了这段时光，理所应当值得庆祝。但是考试周暴露出来的很多问题也值得总结和反思。

堆积课程带来的高压

学校课程堆积太多导致考试周持续高压：本学期有很多基础课程如“高等数学”、“大学物理”、“离散结构”和“线性代数”，知识点较为繁杂，这导致速通的效果并不显著，还容易把自己搞得身心俱疲。因此在之后的期末考试准备中可以将战线拉的长一点，给自己留下更多的时间准备。

高压带来的反弹放纵

白天的高强度速通令人疲惫，这成为了晚上打游戏的理由。劳役结合是好事，但是在打游戏中我并没有得到真正的娱乐和放松，反而给我带来虚度光阴的愧疚：一是因为我并不是真的喜欢玩这些游戏，只是将其当作消磨时光的一种途径，并没有起到真正的放松效果；二是想到自己与同龄人之间逐渐拉开的的差距以及对前程的不确定性。

《认知觉醒》中提到人在在疲惫时，最容易松懈自己的元认知（监督自己）能力，进而会抵不住一些诱惑或做出错误的事情。考试周打乱了我的整体节奏，速通期末的疲惫也使得我无心过问CS的内容。因此在考试周结束的暑假中，要尽快重新找到自己的节奏，用充实的生活代替现在的荒废。

知识管理的再认知

在整理笔记中无意接触到 PKMer 这个网站，里面除了介绍一些工作流之外，还详细讲解了“知识管理”这一专题。我一直想找到一套适合自己学习流，包括知识的摄入、组织和回顾，于是便据此完善我的知识管理体系。

大一阶段的总结

总的来说，整个大一阶段还是处于摸索，但是却极大的拓宽了我的眼界，使我能够较早地开始为未来作准备。期间接触到很多厉害的人，也感谢这些前辈的无私和开源精神，使得我少走了许多弯路。经过了一年的曲折，我的认知和能力得到了极大的提升，希望接下来的时间能继续坚持之前的优良习惯，减少之前的不良行为。

2025-06-08

Sun, 08 Jun 2025 21:18:41 GMT

由于考试周的即将到来，不得不放下专业课的学习，转而开始备考。

回顾

完成了CSAPP的第一部分（1至6章），虽然经历了许多曲折，比如个别高难度的lab和一些基层的概念，但是也收获颇丰。对于我这种代码能力较差的人来说，能够独立完成这些lab无疑是巨大的挑战，只能在借助资料的情况下尽可能有自己的理解。
搭建了自己的博客，于是也算在这广袤天地有了属于自己的精神净土。搭建博客有如下几方面目的：
- 博客的输出可以检验并加深我对知识点的理解，毕竟学习需要输入与输出结合，而写博客本身就是一种输出；
- 可以进行总结和规划，将自己的行为和规划清晰化、透明化，不仅起到监督和勉励自己的作用，还可以消除心中对行动模糊的恐惧；
- 发表自己的想法，也算是在赛博世界有了额外的精神寄托。
完成了一些学校事务，如体育考试和英语的Presentation。

规划

许多学校课程的结课以及考试近在咫尺，随之而来的是各种大作业以及课程复习（对于我来说更应该是开始学习）。

全面准备期末考试，尽量的做到不挂科
沉淀之前的CS所学，如数据结构与算法、JavaSE以及学过的部分《CSAPP》（实在做不到完全不碰CS）

对学校的各种繁杂琐碎始终反感，但是转念一想，生活中很少存在完全顺心顺意的时刻，就像“Life is like a box of chocolates.”所言，这一切构成了整个人生经历。