用纯Java内存实现简易音乐推荐系统，核心是基于用户的协同过滤：用HashMap存用户-歌曲评分，Integer作ID，评分归一化至[0.0,5.0]；先求共同评过分的歌曲交集再算相似度；预测时用小顶堆维护Top-K，注意NaN和空值处理；调试聚焦commonItems.size()、similarity、predictedRating三处日志。
Java 里做简易音乐推荐系统，不靠 Spark 或 Flink 这类大数据框架，用纯 Java + 内存计算 + 简单协同过滤就能跑通核心逻辑。关键不是“多准”，而是“能动、可调、易 debug”。
用 HashMap 存用户-歌曲评分数据，别急着上数据库
冷启动阶段，硬编码或读取 CSV 后存进内存结构最省事。用 Map<integer map double>></integer> 表示 “用户ID → {歌曲ID → 评分}”，比一上来连 MySQL 或 Redis 快得多，也方便你随时打印、断点、改值。
- 用户 ID 和歌曲 ID 建议统一用
Integer，避免String带来的哈希不一致或空格问题 - 评分建议归一化到 [0.0, 5.0] 区间，后续皮尔逊相关系数计算更稳定
- 如果某用户没评过歌，对应 value 是
null或空Map，算法里得判空，否则NullPointerException直接炸
实现基于用户的协同过滤：userSimilarity 函数要先算共同评分项
两个用户相似度不能只看总分接近，得找他们共同评过分的歌曲交集。直接套公式前，务必先过滤出共现集合——这是最容易漏掉、导致相似度虚高或 NaN 的地方。
- 用
Set.retainAll()求用户 A 和 B 都评过的歌曲 ID 集合 - 若交集大小
- 计算皮尔逊时，对每个用户先算自己评分均值（仅在共现歌曲子集上），不是全量平均
- 示例片段：
double sum1 = 0.0, sum2 = 0.0; for (int sid : commonItems) { sum1 += ratingsA.get(sid); sum2 += ratingsB.get(sid); } double meanA = sum1 / commonItems.size(); // ……后续代入协方差公式
推荐结果生成：用 PriorityQueue 控制 Top-K，别用 Arrays.sort
给用户 A 推荐时，要遍历所有其他用户，预测其对未评分歌曲的喜好值，再取前 N。如果把全部预测分存进 List 再排序，内存和时间都浪费——尤其歌曲数 > 1000 时。
立即学习“Java免费学习笔记（深入）”；
- 定义
PriorityQueue<map.entry double>></map.entry>，按预测分小顶堆，容量设为 K - 每算出一个新预测分，
offer()后检查 size > K 就poll()掉最小的 - 注意：堆里比较器必须处理
Double.NaN和Double.NEGATIVE_INFINITY，否则compareTo报异常 - 最终导出结果记得反转顺序（堆是小顶，你要高分在前）
调试时必打的三个日志点：commonItems.size()、similarity、predictedRating
推荐不准？八成卡在中间某步静默失败。协同过滤链条长，但真正影响输出的就这三处：
- 打印每个目标用户与其他用户的
commonItems.size()，确认有没有足够邻居（比如全是 0 或 1） - 把相似度
similarity输出到控制台，看是否大量集中在 [−0.1, 0.1] ——说明用户行为太稀疏，该加热度平滑或换物品协同 - 对某个待预测歌曲，手动挑 2–3 个高相似邻居，打印他们各自的
predictedRating，验证公式代入是否正确（均值偏移、权重累加逻辑）
协同过滤看着简单，但共同项为空、除零、NaN 传播、整数除法截断这些坑，全藏在看似平淡的 for 循环里。先让 userSimilarity 和 predictRating 能稳定吐出非 NaN 数字，再谈准确率。
