简介一套基于协同过滤算法的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 是最稳妥的起点。下表是核心参数的推荐值参数推荐值说明相似用户/物品数量 K10 ~ 20K 太小推荐结果太窄太大则引入噪声最小共同评分数量≥ 5过滤掉只有一两次共同行为的偶然相似推荐结果数量 Top-N10大多数电影推荐系统默认展示 10 条相似度阈值0.4相似度低于阈值的物品对直接忽略评分归一化范围0 ~ 1余弦相似度计算前对评分做 Min-Max 归一化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 MapInteger, MapInteger, Double movieUsers; public ItemCFSimilarity(MapInteger, MapInteger, Double movieUsers) { this.movieUsers movieUsers; } // 计算所有物品之间的相似度 public MapInteger, MapInteger, Double calcSimilarity() { MapInteger, MapInteger, Double simMap new HashMap(); ListInteger movieIds new ArrayList(movieUsers.keySet()); for (int i 0; i movieIds.size(); i) { int movieA movieIds.get(i); MapInteger, Double usersA movieUsers.get(movieA); for (int j i 1; j movieIds.size(); j) { int movieB movieIds.get(j); MapInteger, Double usersB movieUsers.get(movieB); SetInteger 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 ListInteger recommend(int userId, MapInteger, MapInteger, Double ratings, MapInteger, MapInteger, Double similarityMatrix, int topN) { // 第 1 步找到用户评分最高的 5 部电影 MapInteger, Double userRatings ratings.getOrDefault(userId, new HashMap()); ListInteger favoriteMovies userRatings.entrySet().stream() .sorted((a, b) - Double.compare(b.getValue(), a.getValue())) .limit(5) .map(Map.Entry::getKey) .collect(Collectors.toList()); // 第 2 步从这些电影的相似物品中收集候选 MapInteger, Double candidateScores new HashMap(); for (Integer movie : favoriteMovies) { MapInteger, Double similarMovies similarityMatrix.getOrDefault(movie, new HashMap()); for (Map.EntryInteger, 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 { ListMovie recommendMovies(int userId, int topN); }好处是上层 Web 接口只依赖这个接口下面不管底层换成 ItemCF 还是 UserCF甚至是后面引入 Spark 做分布式计算Controller 层的代码一行都不用改。这就是面向接口编程的价值也是面试官最想听你讲的亮点。4.2 用内存模型托底Map 缓存与评分矩阵推荐系统源码跑起来的第一步是把 CSV 文件加载为内存 Map。对 ml-latest-small 这种 10 万条评分数据来说Java 堆内存吃掉 200MB 左右完全能接受。加载代码写法// RatingDao.java public MapInteger, MapInteger, Double loadRatings(String filePath) throws IOException { MapInteger, MapInteger, Double ratings new HashMap(); MapInteger, MapInteger, 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 ResponseEntityMapString, Object recommend(PathVariable Integer userId, RequestParam(defaultValue 10) int topN) { long start System.currentTimeMillis(); ListMovie movies recommendService.recommendMovies(userId, topN); long cost System.currentTimeMillis() - start; MapString, 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-latest25MB 版本数据集加载进项目后直接抛出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 切成训练集和测试集在训练集上计算相似度用测试集里的真实评分验证推荐结果的准确率。你可以用 precision10 这个指标——推荐列表里有几部电影是测试集中用户真实看过的。这个模块的价值在于它能量化你每次调参是变好了还是变差了而不是靠感觉说「好像推荐得更准了」。第二件事是把 ItemCF 的相似度计算从单机搬到批量任务里。我见过不少项目把相似度计算放在每次启动时做数据量小时还行涨到 100 万条评分就要几十秒。常见做法是写一个定时任务每天凌晨计算一次相似度矩阵序列化到本地文件或者 Redis 里白天推荐接口只读缓存。这属于架构上的小改造但面试官很吃这套因为这说明你想过生产环境的问题。第三件事是给物品相似度加一个可解释的维度。当前相似度矩阵只有数值前端只能显示「因为推荐了所以推荐」用户信任感很低。把相似度的计算依据存下来给每一个推荐结果附带一条理由文案「因为你给《盗梦空间》打了 5 分而看过《盗梦空间》的人 83% 也喜欢《星际穿越》」。这一行代码不复杂但从产品角度来说它比单纯提高 0.01 的准确率更值钱。我自己的教训是早期做推荐系统时只盯着算法指标冷启动和可解释性完全没预留结果线下指标好看线上用户就是不买账。后来才明白推荐系统是个工程问题算法只是其中一环数据、评测、兜底、解释、降级每一项都值得在源码层面看到痕迹。希望这篇笔记能帮你把这套源码真正吃透少走我踩过的那些弯路把推荐系统从「能跑」做到「能讲、能改、能上生产」。本文还有配套的精品资源点击获取