Java电影推荐系统实战：协同过滤算法从源码到工程落地

简介：一套基于协同过滤算法的Java电影推荐系统源码，面向Java学习者、毕业设计开发者以及需要搭建推荐模块的小型流媒体平台，核心解决如何通过用户历史行为数据实现个性化影片推荐。项目采用Java为主、JavaScript与CSS为辅的技术栈，完整包含业务后端与Web展示端，可同时作为课程设计或推荐系统入门项目参考。压缩包共76个文件，以38个Java源文件、15个JSP页面为主要代码主体，配合10个XML配置管理项目结构、2个SQL脚本初始化数据库，另有少量JavaScript、CSS、属性文件与说明文档，整体仅1.1MB，轻量易用。系统利用协同过滤算法对用户观影记录、评分或相似偏好进行建模，输出贴合个人口味的推荐列表，并可直接导入开发环境运行调试。目前已有823人学习下载，包内包含源码、数据库脚本、配置文件及说明文档，适合对照工程目录理解算法落地过程，也能为后续功能扩展与平台优化提供基础。

1. 这套 Java 电影推荐系统源码，解决的是推荐系统从 0 到 1 的落地问题

如果你打开过招聘网站，会发现 Java 后端岗位的 JD 里经常出现「熟悉常用推荐算法」；如果你自己动手查过电影推荐系统源码，又会发现网上绝大多数项目要么是 Python 写的，要么是只给一个算法 demo 没法跑起来。这个标题把「协同过滤算法」和「Java」绑定在一起，本质上是想解决一个问题：用 Java 技术栈、基于协同过滤算法，搭建一套可以离线训练、在线推荐的电影推荐系统源码。它面向的人群很明确：正在做 Java 课程设计的大学生、准备 Java 面试需要项目经验的开发者、以及想在企业内部快速搭建推荐 POC 的后端工程师。

这类源码通常包含用户评分数据导入、相似度计算、推荐结果生成和 Web 接口展示这几块内容。你拿到手之后能学到的不只是几个相似度公式，而是怎么把数学公式变成 Java 代码，怎么设计内存数据结构来承载计算，以及数据量上来之后会发生什么。本文我会站在一位做过推荐系统落地的工程师角度，把这个项目的核心算法原理、工程结构、核心代码、参数调优和常见踩坑都拆开讲一遍，保证你照着走能把系统跑起来，并且知道下一步往哪改。

2. 协同过滤的两种主流算法：UserCF 与 ItemCF 的选型逻辑

2.1 基于用户的协同过滤（UserCF）的数学直觉

基于用户的协同过滤核心思想很简单：和你兴趣相似的用户喜欢的电影，你也大概率会喜欢。它分三步走：第一，构建用户-物品评分矩阵；第二，计算用户与用户之间的相似度；第三，取相似度最高的 K 个用户，把他们评分高且你没有看过的电影推荐给你。

用数学语言表达，假设有用户 (u) 和用户 (v)，他们各自对一组电影有过评分，那么用户相似度可以用余弦相似度计算：

[ sim(u,v) = \frac{\sum_{i \in I_{uv}} r_{u,i} \cdot r_{v,i}}{\sqrt{\sum_{i \in I_u} r_{u,i}^2} \cdot \sqrt{\sum_{i \in I_v} r_{v,i}^2}} ]

其中 (I_{uv}) 是用户 (u) 和用户 (v) 共同评分过的电影集合，(I_u) 是用户 (u) 评分过的电影集合。分母做归一化，目的是让相似度落在 0 到 1 之间。这里有一个最容易被忽视的细节：如果两个用户只共同看过一部电影，哪怕评分完全一致，算出来的相似度也会很高，但这只是偶然重合，不是真正的兴趣相似。所以工程上一般会给 (sim(u,v)) 乘以一个惩罚系数，也就是所谓的 IDF 惩罚，降低热门电影对相似度计算的干扰。

2.2 基于物品的协同过滤（ItemCF）的数学直觉

基于物品的协同过滤在电商和视频网站里用得更多。它推荐的逻辑不是找相似的用户，而是找相似的物品——你给《盗梦空间》打了高分，系统找到和《盗梦空间》最相似的《星际穿越》推荐给你。注意，这里的「物品相似」不是基于内容属性（导演、演员、类型），而是基于用户行为：两个物品被同一批用户评分或点击，它们就被认为是相似的。

ItemCF 的计算过程是：先建立用户-物品倒排表，也就是每个用户评分过的物品列表；然后遍历所有用户的物品列表，统计物品与物品之间共同出现的次数。这里有一个经典的公式，物品 (i) 和物品 (j) 的相似度：

[ sim(i,j) = \frac{|N(i) \cap N(j)|}{\sqrt{|N(i)| \cdot |N(j)|}} ]

(N(i)) 表示对物品 (i) 产生过行为的用户集合。这个公式就是 Jaccard 相似度的变体，它惩罚了热门物品——一个物品被太多人评分，分母就变大了，相似度会被压下去。

2.3 选型顺序与参数表

做这个 Java 电影推荐系统时，我建议你优先实现 ItemCF。原因有三：第一，电影场景下用户兴趣相对分散，UserCF 的用户相似度矩阵在用户量大的时候计算量爆炸；第二，ItemCF 的推荐结果更容易解释，你可以直接告诉用户「因为你喜欢《肖申克的救赎》，所以推荐《阿甘正传》」；第三，ItemCF 的物品相似度矩阵可以离线计算、定时更新，在线推荐时只需要查表，非常适合 Java Web 项目的架构。

如果你做的是新闻推荐或者社群推荐，那 UserCF 会更合适，因为它对热点和突发话题的反应速度快。选型没有绝对的对错，但电影推荐这个场景下 ItemCF 是最稳妥的起点。下表是核心参数的推荐值：

3. 把数据准备好：MovieLens 数据集与相似度计算的落地步骤

3.1 数据集的下载与表结构

做推荐系统源码，最怕的就是没有数据可跑。业界最常见的做法是使用 MovieLens 数据集，这是一个明尼苏达大学研究组维护的电影评分数据集，里面包含用户 ID、电影 ID、评分和时间戳。我一般在课程设计或 POC 项目里用 ml-latest-small 版本，它大约有 600 个用户、9000 部电影和 100000 条评分，对于单机 Java 程序来说大小刚好，既能体现算法效果又不会让内存吃不消。

数据文件是 CSV 格式，你需要建两张表来承载：评分表ratings.csv包含userId,movieId,rating,timestamp四个字段，电影表movies.csv包含movieId,title,genres三个字段。注意timestamp在推荐算法里默认用不到，如果你想做时间衰减可以留着，不想做就直接忽略。将两个 CSV 文件放到项目的src/main/resources/data目录下，接下来用 Java 读取。

3.2 相似度计算代码：余弦相似度实现与归一化

这是整个源码的核心。我用一个裸的 Java 类来实现 ItemCF 的物品相似度计算，不依赖任何第三方框架，方便你移植到任何项目里。

// ItemCFSimilarity.java import java.util.*; public class ItemCFSimilarity { // key: movieId, value: 所有对该电影评过分的 userId -> 评分的映射 private Map<Integer, Map<Integer, Double>> movieUsers; public ItemCFSimilarity(Map<Integer, Map<Integer, Double>> movieUsers) { this.movieUsers = movieUsers; } // 计算所有物品之间的相似度 public Map<Integer, Map<Integer, Double>> calcSimilarity() { Map<Integer, Map<Integer, Double>> simMap = new HashMap<>(); List<Integer> movieIds = new ArrayList<>(movieUsers.keySet()); for (int i = 0; i < movieIds.size(); i++) { int movieA = movieIds.get(i); Map<Integer, Double> usersA = movieUsers.get(movieA); for (int j = i + 1; j < movieIds.size(); j++) { int movieB = movieIds.get(j); Map<Integer, Double> usersB = movieUsers.get(movieB); Set<Integer> commonUsers = new HashSet<>(usersA.keySet()); commonUsers.retainAll(usersB.keySet()); if (commonUsers.size() < 5) { continue; // 过滤共同评分人数太少的物品对 } double dotProduct = 0; double normA = 0; double normB = 0; for (Integer userId : commonUsers) { dotProduct += usersA.get(userId) * usersB.get(userId); } for (Double rating : usersA.values()) { normA += rating * rating; } for (Double rating : usersB.values()) { normB += rating * rating; } double similarity = dotProduct / (Math.sqrt(normA) * Math.sqrt(normB)); simMap.computeIfAbsent(movieA, k -> new HashMap<>()).put(movieB, similarity); simMap.computeIfAbsent(movieB, k -> new HashMap<>()).put(movieA, similarity); } } return simMap; } }

这段代码的逻辑核心在双重循环上。外层循环取电影 A，内层循环取电影 B，只计算一次并把结果对称写入 map，避免重复计算。commonUsers.size() < 5是一个硬性过滤条件，这个参数就是我在第 2 章参数表里提到的「最小共同评分数量」，它能把偶然相似的情况压下去。分母是两个向量的模长乘积，属于标准的余弦相似度。如果后续你想加 IDF 惩罚，可以在dotProduct累加时乘以一个权重系数，比如：

// 加权版本：热门电影降权 double weight = 1 / Math.log(1 + usersA.size()); dotProduct += usersA.get(userId) * usersB.get(userId) * weight;

这样改动只为体现一个思想：被 1000 个人评分过的电影和被 5 个人评分过的电影，它们产生的共同行为对相似度的贡献应该不同。《泰坦尼克号》这类热门片谁都会看，用它来判断两人的兴趣相似性没啥价值。

3.3 Filtering 和 Top-N 推荐的主流程代码

有了物品相似度矩阵，推荐主流程就比较直白了：找到用户评分最高的几部电影，再找这些电影最相似的 Top-K 个电影做推荐。这里我写一个推荐器：

// Recommender.java import java.util.*; import java.util.stream.Collectors; public class Recommender { // 生成针对某个用户的 Top-N 推荐 public static List<Integer> recommend(int userId, Map<Integer, Map<Integer, Double>> ratings, Map<Integer, Map<Integer, Double>> similarityMatrix, int topN) { // 第 1 步：找到用户评分最高的 5 部电影 Map<Integer, Double> userRatings = ratings.getOrDefault(userId, new HashMap<>()); List<Integer> favoriteMovies = userRatings.entrySet().stream() .sorted((a, b) -> Double.compare(b.getValue(), a.getValue())) .limit(5) .map(Map.Entry::getKey) .collect(Collectors.toList()); // 第 2 步：从这些电影的相似物品中收集候选 Map<Integer, Double> candidateScores = new HashMap<>(); for (Integer movie : favoriteMovies) { Map<Integer, Double> similarMovies = similarityMatrix.getOrDefault(movie, new HashMap<>()); for (Map.Entry<Integer, Double> entry : similarMovies.entrySet()) { int candidateMovie = entry.getKey(); if (userRatings.containsKey(candidateMovie)) { continue; // 用户已经看过的电影不再推荐 } candidateScores.merge(candidateMovie, entry.getValue(), Double::sum); } } // 第 3 步：按累计得分排序，取 Top-N return candidateScores.entrySet().stream() .sorted((a, b) -> Double.compare(b.getValue(), a.getValue())) .limit(topN) .map(Map.Entry::getKey) .collect(Collectors.toList()); } }

merge方法是 Java 8 引入的黑科技，第一次遇到某个候选电影时直接 put 值，再次遇到相同电影时把两个相似度相加，这比先get再put的写法省掉了一堆空指针判断。limit(5)控制了「种子电影」数量，我一般取 5 到 10，取太少推荐结果会被单部电影的强相似物品主导，取太多则后面的低分电影会引入噪声。这里一共调了三个参数——种子电影数、Top-N、相似度矩阵里每个物品保留的相似物品数，三个参数配合着调才能出理想效果。

4. 在 Java 工程里把推荐逻辑接成可运行的服务

4.1 工程结构与推荐器接口设计

如果你拿到的源码用的是 Maven 工程结构，核心包结构应该长这样：

src/main/java ├── com.example.movie │ ├── config/ // 配置类，读取参数 │ ├── dao/ // 数据访问层，解析 CSV │ ├── model/ // 实体类：User, Movie, Rating │ ├── recommender/ // 推荐算法核心 │ │ ├── ItemCFSimilarity.java │ │ ├── UserCFSimilarity.java │ │ └── Recommender.java │ └── controller/ // Web 接口层

接口设计上，我建议定义一个顶层的RecommendService接口，里面只放一个方法：

public interface RecommendService { List<Movie> recommendMovies(int userId, int topN); }

好处是上层 Web 接口只依赖这个接口，下面不管底层换成 ItemCF 还是 UserCF，甚至是后面引入 Spark 做分布式计算，Controller 层的代码一行都不用改。这就是面向接口编程的价值，也是面试官最想听你讲的亮点。

4.2 用内存模型托底：Map 缓存与评分矩阵

推荐系统源码跑起来的第一步是把 CSV 文件加载为内存 Map。对 ml-latest-small 这种 10 万条评分数据来说，Java 堆内存吃掉 200MB 左右完全能接受。加载代码写法：

// RatingDao.java public Map<Integer, Map<Integer, Double>> loadRatings(String filePath) throws IOException { Map<Integer, Map<Integer, Double>> ratings = new HashMap<>(); Map<Integer, Map<Integer, Double>> movieUsers = new HashMap<>(); try (BufferedReader br = new BufferedReader(new FileReader(filePath))) { String line = br.readLine(); // 跳过表头 while ((line = br.readLine()) != null) { String[] parts = line.split(","); int userId = Integer.parseInt(parts[0].trim()); int movieId = Integer.parseInt(parts[1].trim()); double rating = Double.parseDouble(parts[2].trim()); ratings.computeIfAbsent(userId, k -> new HashMap<>()).put(movieId, rating); movieUsers.computeIfAbsent(movieId, k -> new HashMap<>()).put(userId, rating); } } return ratings; }

这里有个实际工程里容易翻车的点：CSV 字段里如果包含逗号（比如电影名《了不起的盖茨比, 第二部》），用split(",")会把字段拆裂。MovieLens 的movies.csv里电影类型字段确实会带逗号，建议先看原始数据再决定用哪种解析方式。稳妥的做法是引入 commons-csv 库，或者至少用带引号的 CSV 解析规则。评分数据加载一次，同时构建出用户维度和物品维度两个 Map，后续算法层就不需要再扫描文件了。

4.3 Web 接口、批量打分与降级策略

有了内存里的相似度矩阵和推荐器，剩下的就是暴露 HTTP 接口给前端调用。最简单的方式是用 Spring Boot 写一个 Controller，但如果你拿到的源码没有用 Spring，而是用纯 Servlet，也不用慌——逻辑完全一样：

// RecommendController.java @RestController @RequestMapping("/api/recommend") public class RecommendController { @Autowired private RecommendService recommendService; @GetMapping("/{userId}") public ResponseEntity<Map<String, Object>> recommend(@PathVariable Integer userId, @RequestParam(defaultValue = "10") int topN) { long start = System.currentTimeMillis(); List<Movie> movies = recommendService.recommendMovies(userId, topN); long cost = System.currentTimeMillis() - start; Map<String, Object> result = new HashMap<>(); result.put("userId", userId); result.put("recommendations", movies); result.put("costMs", cost); return ResponseEntity.ok(result); } }

costMs这个字段建议保留。推荐系统的算法效果可以用离线指标评估，但接口性能必须在线观察。ItemCF 的在线推荐过程其实很快，因为相似度矩阵离线算好存在内存里，在线推荐只需要做几次 Map 查询和排序，理想情况下应在 10ms 以内返回。如果你发现接口响应时间超过 100ms，大概率是相似度矩阵构建放在了请求路径里，或者矩阵大到发生了频繁 GC。给自己留一个降级策略，比如在 Redis 里缓存每个用户最近一版的推荐列表，当计算超时或数据源抖动时直接返回缓存结果。这是生产环境的标准动作，写在简历里也会比单纯说「我实现了一个推荐算法」更有亮点。

5. 避坑指南：推荐系统源码从运行到调通的 5 条实战记录

5.1 相似度计算结果全是 NaN

现象：运行 ItemCF 后，推荐接口返回的电影列表是空的，或者推荐结果里的得分全是NaN。排查日志发现相似度计算时出现了 0 除以 0 的情况。

原因：用户对电影评分全部为零。比如 CSV 文件里缺少某些电影的评分，导致normA或normB计算出来是 0，分母为 0，结果自然是 NaN。另一种情况是评分没有做归一化，原始评分为 0 到 5 时，某个向量可能全部为 0。

解决：在计算相似度之前，对所有评分做偏移处理，将评分从 1~5 映射到 0~4 或者做 Min-Max 归一化。同时加一个条件判断，如果normA == 0 || normB == 0，直接跳过这对物品。

if (normA == 0 || normB == 0) { continue; }

5.2 CSV 解析时字段被逗号拆裂

现象：加载movies.csv时，电影标题解析出来不完整，比如《The Terminator, The》这种标题被截断，导致电影 ID 和标题对不上，推荐结果里出现一串无意义的数字。

原因：CSV 中电影标题字段本身包含逗号，而代码用了line.split(",")这种粗暴方式。

解决：改用 CSVParser 库，或者简单一点，手工按逗号分割后，把头部和尾部的引号"去掉。如果你只需要电影 ID 和标题，也可以按split(",", 3)限定分割次数，让最后一个字段完整保留逗号。

5.3 内存溢出 OutOfMemoryError

现象：把 ml-latest（25MB 版本）数据集加载进项目后，直接抛出java.lang.OutOfMemoryError: Java heap space。

原因：相似度矩阵是一个二维稠密的结构，即使只保留 Top-K 相似的物品，临时计算时仍然会创建大量中间 Map 对象。我见过有源码为了简化，给每个物品都保存所有相似物品的相似度，10 万部电影就是 10 亿条数据，内存直接爆掉。

解决：相似度矩阵只保留每个物品相似度最高的 K 个物品，K 一般取 20 以内。这样矩阵规模从 (O(n^2)) 降到 (O(nK))。启动参数加上：

java -Xmx1g -Xms256m -jar movie-recommend.jar

如果还不够，把相似度矩阵刷到 Redis 或本地文件里，启动时加载。

5.4 推荐结果全是同一部电影的相似片

现象：推荐列表里 10 部电影全部是《蝙蝠侠：黑暗骑士》的相似片，用户的个性化完全没体现。

原因：种子电影选择策略有问题。用户只对一部电影打了 5 分，其他电影都是 1~2 分，按评分排序后种子电影被这一部高分片垄断了。

解决：种子电影不只看绝对评分，要限制单个电影的种子比例，或者对种子电影做去重——同一个导演、同一种类型的电影最多保留两部。另一个更常见的做法是给评分加入时间衰减，最近看的电影加权更大：

double weight = 1.0 / (1.0 + daysSince(ratedAt));

这样用户半年前打的高分电影权重变低，最近的兴趣才有机会冒出来。

5.5 新用户没有推荐结果

现象：新增一个用户后，调用推荐接口返回空列表。

原因：冷启动问题。新用户没有任何评分数据，userRatings为空，favoriteMovies为空，候选集自然是空的。

解决：最少做一个兜底策略，给新用户推荐全局最高评分的 10 部电影，这在行业里叫热门榜推荐。等用户有了第一条评分记录，再切换到个性化推荐。如果追求更好的效果，可以让用户注册时选择喜欢的类型标签，把类型偏好映射到电影上，获得第一批种子。冷启动不是算法问题，是产品问题，源码里至少要有一种兜底策略才算完整。

6. 把源码用起来的三条进阶建议：从能跑到能讲

拿到这套源码，第一步当然是把它跑起来。我建议你按下面的顺序验证：导入 Maven 工程，运行RatingDaoTest确认数据加载成功，然后跑ItemCFSimilarityTest看相似度矩阵的规模和几个热门电影的相似片是否正确，最后启动 Spring Boot，用带评分的用户 ID 调接口。我自己的习惯是准备三个测试用户：一个只看了 5 部电影的稀疏用户，一个看了 200 部电影的重度用户，一个新的没有任何行为的用户。三个用户跑通，基本能覆盖八成运行时报错。

进阶的第一件事，是给项目加一个简单的离线评估模块。把评分数据按 8:2 切成训练集和测试集，在训练集上计算相似度，用测试集里的真实评分验证推荐结果的准确率。你可以用 precision@10 这个指标——推荐列表里有几部电影是测试集中用户真实看过的。这个模块的价值在于，它能量化你每次调参是变好了还是变差了，而不是靠感觉说「好像推荐得更准了」。

第二件事，是把 ItemCF 的相似度计算从单机搬到批量任务里。我见过不少项目把相似度计算放在每次启动时做，数据量小时还行，涨到 100 万条评分就要几十秒。常见做法是写一个定时任务，每天凌晨计算一次相似度矩阵，序列化到本地文件或者 Redis 里，白天推荐接口只读缓存。这属于架构上的小改造，但面试官很吃这套，因为这说明你想过生产环境的问题。

第三件事，是给物品相似度加一个可解释的维度。当前相似度矩阵只有数值，前端只能显示「因为推荐了所以推荐」，用户信任感很低。把相似度的计算依据存下来，给每一个推荐结果附带一条理由文案：「因为你给《盗梦空间》打了 5 分，而看过《盗梦空间》的人 83% 也喜欢《星际穿越》」。这一行代码不复杂，但从产品角度来说，它比单纯提高 0.01 的准确率更值钱。我自己的教训是，早期做推荐系统时只盯着算法指标，冷启动和可解释性完全没预留，结果线下指标好看，线上用户就是不买账。后来才明白，推荐系统是个工程问题，算法只是其中一环，数据、评测、兜底、解释、降级，每一项都值得在源码层面看到痕迹。希望这篇笔记能帮你把这套源码真正吃透，少走我踩过的那些弯路，把推荐系统从「能跑」做到「能讲、能改、能上生产」。

本文还有配套的精品资源，点击获取