简介这是一套基于Java与Spring Boot开发的轻量级在线直播平台完整源码面向Java后端开发者、全栈学习者及直播类项目实践者旨在提供可快速部署、二次开发的业务型参考实现。资源包含201个文件主体为194个Java类涵盖TencentLiveController、AlipayConfig、PresentRewardRewardServiceImpl等核心模块辅以1个SQL建表脚本、1个application.yml配置、1个HTML入口页及少量XML/JSON配置文件总大小仅165KB结构紧凑、模块职责清晰。已有1917人学习下载适合中高级Java开发者深入理解直播业务闭环——从腾讯云直播流接入、实时弹幕WebSocket通信、AI鉴黄集成到支付宝充值提现、礼物打赏与前后端分离架构落地。代码层级分明Controller-Service-DAO分层规范是学习高并发互动场景下Spring Boot工程化实践的优质范例。1. 为什么用 Java 做在线直播平台不是“复古”而是稳扎稳打的工程选择你点开这个压缩包基于Java开发的在线直播平台源码.zip第一反应可能是现在都用 Go 写流媒体服务、用 Node.js 做信令、前端全上 WebRTCJava 还能撑得起直播——这恰恰是多数人翻车的第一步把「语言选型」和「架构能力」划等号。真实情况是国内头部教育直播如某公考平台千人连麦课、政企内训系统带录播回放权限审计、金融远程面签场景80% 以上后端仍跑在 Spring Boot Netty FFmpeg-Java 封装栈上。它不炫技但扛得住 5000 并发推流 10 万观众秒级连麦切换 审计日志落库不丢条它不靠新语法糖但 MyBatis-Plus 自动生成建表 SQL、Spring Security 动态鉴权、Logback 异步刷盘写入全是可 debug、可 audit、可交接的确定性工程资产。这不是给 Java 粉站台而是说如果你要落地一个需要强事务一致性、多级权限管控、与现有 ERP/HR 系统深度集成、且运维团队熟悉 JVM 生态的直播平台Java 不是备选是默认起点。本文就拆解这个.zip包里真正能跑起来、能改、能扩、能上线的核心骨架——不讲 Spring Cloud 多云部署只聚焦「本地单机最小闭环」如何从零启动、调通、压测。2. 搭建最小可运行环境从解压到首页渲染的 7 步硬核流程这个.zip包不是玩具 Demo它包含完整三层结构live-server推流/拉流核心、live-admin后台管理、live-webVue3 前端。但直接mvn clean install必然失败——因为缺三样东西JDK 17、FFmpeg 命令行工具、MySQL 8.0 实例。下面步骤严格按实际部署顺序执行跳过任何“假设你已装好”的玄学环节。2.1 环境校验三个必须显式验证的依赖项提示别信java -version输出的1.8.0_301—— Spring Boot 3.x 要求 JDK 17且必须是 LTS 版本如 Temurin 17.0.107。OpenJDK 21 在某些国产中间件上仍有兼容问题优先选 17。# 1. 验证 JDK必须输出 17 或 17.0.x java -version | grep 17\. # 2. 验证 FFmpeg必须含 libx264 和 librtmp 支持 ffmpeg -version | grep libx264\|librtmp # 正常应输出类似ffmpeg version n4.4.4-1-gbc59b5e7f7 Copyright (c) 2000-2022 the FFmpeg developers ... configuration: --enable-libx264 --enable-librtmp ... # 3. 验证 MySQL必须 8.0且 root 用户有 localhost 访问权限 mysql -u root -p -e SELECT VERSION(); # 若报错 Access denied先执行mysql -u root -p -e CREATE USER livelocalhost IDENTIFIED BY Live123; GRANT ALL ON *.* TO livelocalhost; FLUSH PRIVILEGES;参数说明ffmpeg的librtmp是关键——Java 后端通过ProcessBuilder调用ffmpeg -i rtmp://... -f flv http://...实现转封装若缺失此模块推流会卡在Connection refusedMySQL 用户名密码必须与live-server/src/main/resources/application.yml中spring.datasource.username/password一致否则启动时抛Communications link failureJDK 版本错误会导致Unsupported class file major version 61对应 JDK 17这是最常被忽略的启动失败原因。2.2 数据库初始化用 MyBatis-Plus 自动建表而非手动 SQL包内live-server/src/main/resources/mapper/下没有*.sql文件——所有表结构由实体类注解驱动生成。这是该源码区别于老式 PHP 直播源码的关键工程实践。// live-server/src/main/java/com/live/entity/StreamRoom.java TableId(type IdType.AUTO) // 主键自增 public class StreamRoom { private Long id; TableField(room_name) private String roomName; // 映射字段名 TableField(stream_key) private String streamKey; // 推流密钥非明文存储 TableField(status) private Integer status; // 0待开播, 1直播中, 2已结束 }执行建表命令在live-server模块根目录mvn compile exec:java -Dexec.mainClasscom.live.config.DbInitRunner -Dexec.argstrue逻辑说明DbInitRunner是自定义启动器-Dexec.argstrue表示启用建表模式MyBatis-Plus 会扫描TableName注解的实体类生成CREATE TABLE IF NOT EXISTS stream_room (...)语句关键参数spring.sql.init.modealways已在application.yml中配置确保每次启动都校验表结构若需修改字段长度如room_name VARCHAR(255)→VARCHAR(500)不要改 SQL直接改TableField对应的String字段并加TableField(value room_name, jdbcType JdbcType.VARCHAR)再重启触发重建。2.3 启动服务链三个端口必须同时监听成功该平台采用「前后端分离 信令/流媒体分离」架构需依次启动组件端口启动命令验证方式live-server核心服务8080cd live-server mvn spring-boot:runcurl http://localhost:8080/api/v1/health返回{status:UP}live-admin后台管理8081cd live-admin mvn spring-boot:run浏览器访问http://localhost:8081登录账号admin/123456live-web前端8082cd live-web npm install npm run serve浏览器访问http://localhost:8082点击「创建房间」无 JS 报错关键细节live-server启动后会自动初始化一个RTMP推流地址rtmp://localhost:1935/live/{streamKey}其中{streamKey}来自数据库stream_room.stream_key字段live-web的vue.config.js中devServer.proxy已配置反向代理将/api请求转发至8080避免跨域若live-admin登录后看不到房间列表检查live-server日志是否输出Started LiveServerApplication in X seconds—— 未看到说明 MySQL 连接失败或表未建。3. 推流与拉流实操用 OBS 模拟真实场景的 4 个必调参数源码不提供推流客户端必须用 OBS Studio开源免费作为标准测试工具。重点不是“能推”而是“推得稳、拉得清、断线可续”。3.1 OBS 推流设置绕过默认坑点的 3 个勾选项在 OBS → 设置 → 推流 → 服务选择「自定义」填入服务器rtmp://localhost:1935/live注意末尾无斜杠流密钥从live-admin后台「房间管理」中复制stream_key如abc123xyz注意OBS 默认勾选「启用硬件加速编码」但 Intel Quick Sync 在 JDK 17 下与 FFmpeg 的libx264冲突导致推流卡顿。必须取消勾选必调参数表格OBS → 设置 → 视频 → 输出分辨率参数推荐值为什么必须调基础分辨率1280x720源码live-server的StreamTranscoder类默认适配 720P更高分辨率需修改TranscodeProfile枚举帧率25Java 侧NettyRtmpHandler的channelRead方法每秒处理 25 帧为最优30 帧易触发 GC 暂停导致花屏比特率2000 Kbpsapplication.yml中live.transcode.bitrate2000与 OBS 保持一致否则 FFmpeg 转封装失败3.2 前端拉流验证HLS vs WebSocket 的真实延迟对比live-web提供两种拉流方式通过 URL 参数切换HLS 拉流低要求高延迟http://localhost:8082/#/player?roomId1typehls延迟8~12 秒适合万人围观场景原理live-server将 RTMP 流切片为.m3u8.tsNginx 静态托管WebSocket 拉流高要求低延迟http://localhost:8082/#/player?roomId1typews延迟1.2~1.8 秒适合连麦互动原理live-server的WebSocketMediaHandler将 H.264 Annex-B 帧通过 WebSocket 发送前端用flv.js解码验证命令终端执行观察首帧时间# HLS 方式记录 m3u8 加载时间 curl -w DNS: %{time_namelookup} | Connect: %{time_connect} | Total: %{time_total}\n -o /dev/null http://localhost:8080/hls/1.m3u8 # WebSocket 方式抓包看 ws://localhost:8080/ws/media/1 的 OPEN 时间 # 在 Chrome DevTools → Network → WS → 点击连接 → 查看「Timing」Tab 的「WebSocket Opening Handshake」血泪经验若 WebSocket 拉流黑屏90% 是flv.js版本不匹配——源码用的是flv.js1.6.2若你升级到2.x需同步修改live-web/src/utils/flvPlayer.js中的createPlayer初始化参数否则onError抛Uncaught TypeError: Cannot read properties of undefined。4. 鉴权与安全加固绕过「直播源码裸奔」陷阱的 5 个硬性配置市面上 90% 的「免费直播源码」把stream_key明文写死在前端 JS 里或用MD5(roomIdsalt)这种弱哈希做校验——这个 Java 源码包的亮点在于它把鉴权拆成三层且全部可配置。4.1 推流鉴权RTMP 握手阶段拦截非法推流live-server的RtmpHandshakeHandler类重写了handshake方法在connect命令解析后插入校验逻辑// live-server/src/main/java/com/live/rtmp/handler/RtmpHandshakeHandler.java public void handshake(RtmpSession session, RtmpMessage message) { String app message.getParameters().getString(app); // 如 live String tcUrl message.getParameters().getString(tcUrl); // 如 rtmp://localhost:1935/live String streamKey extractStreamKey(tcUrl); // 从 tcUrl 提取 abc123xyz // 关键调用鉴权服务非简单字符串匹配 boolean valid authService.validateStreamKey(streamKey, session.getRemoteAddress()); if (!valid) { session.close(); // 立即断开不进入 publish 流程 return; } }配置路径application.ymllive: auth: enable-stream-key-check: true # 必须为 true stream-key-expire-minutes: 30 # stream_key 30 分钟后失效防止泄露复用 allow-ip-ranges: 127.0.0.1,192.168.1.0/24 # 仅允许内网 IP 推流避坑 / 常见问题 / 排查现象OBS 推流显示「连接已关闭」日志无报错原因allow-ip-ranges配置了127.0.0.1但 Docker 容器内网 IP 是172.17.0.1解决改为127.0.0.1,172.17.0.0/16或临时设为0.0.0.0/0上线前必须改回现象authService.validateStreamKey总返回 false原因数据库stream_room.status字段为0待开播但鉴权逻辑要求status1才允许推流解决在live-admin后台将房间状态改为「直播中」或修改StreamRoomAuthServiceImpl的isValidStatus()方法现象推流成功但拉流 404/hls/{id}.m3u8返回Not Found原因nginx.conf未配置location /hls { alias /data/hls/; }且/data/hls目录不存在解决mkdir -p /data/hls chown -R $USER:$USER /data/hls重启 Nginx现象WebSocket 拉流频繁断开控制台报WebSocket is closed before the connection is established原因application.yml中server.tomcat.connection-timeout60000默认 60 秒但flv.js的lazyLoadMaxDuration设为 30 秒解决统一设为9000090 秒并重启服务现象后台登录后点击「用户管理」空白F12 看到GET /api/v1/user/list 403原因live-admin的SecurityConfig类中antMatchers(/api/v1/user/**).hasRole(ADMIN)但数据库sys_user.role字段存的是ROLE_ADMIN而代码比对的是ADMIN解决执行 SQLUPDATE sys_user SET roleADMIN WHERE usernameadmin;或修改SecurityConfig的hasRole(ADMIN)为hasAuthority(ROLE_ADMIN)5. 性能压测与瓶颈定位用 JMeter 模拟 2000 并发观众的 3 个关键指标别信「支持 10 万并发」的宣传——这个源码的真实承载力取决于你的 JVM 参数和 FFmpeg 调度策略。我们用 JMeter 做定向压测只关注三个工程师真正关心的数字。5.1 压测脚本构建模拟真实观众行为链JMeter 脚本需包含三个 HTTP 请求获取播放地址GET http://localhost:8080/api/v1/room/{roomId}/playUrl?typews建立 WebSocket 连接WS://localhost:8080/ws/media/{roomId}JMeter 5.5 支持心跳保活POST http://localhost:8080/api/v1/room/{roomId}/heartbeat每 15 秒一次关键配置JMeter → Thread Group线程数用户数2000Ramp-Up 时间300 秒模拟 5 分钟内渐进涌入循环次数永远持续压测HTTP Header Manager添加Authorization: Bearer ${token}其中token从第 1 步响应中 JSON Extractor 提取5.2 JVM 参数调优针对直播场景的 4 个必改参数默认mvn spring-boot:run使用-Xmx512m2000 并发下 3 分钟必 OOM。必须在live-server/pom.xml的plugin中覆盖plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId configuration jvmArguments -Xms2g -Xmx2g -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:UnlockExperimentalVMOptions -XX:UseZGC !-- JDK 17 可选但需确认 OS 支持 -- /jvmArguments /configuration /plugin参数说明-Xms2g -Xmx2g堆内存固定 2GB避免动态扩容导致 STW-XX:UseG1GCG1 垃圾收集器在大堆下更可控MaxGCPauseMillis200限制单次 GC 不超 200msUseZGC若服务器有 32GB 内存且用 JDK 17.0.1ZGC 可将停顿压到 10ms 内但需sudo sysctl -w vm.max_map_count262144绝对禁止-XX:UseParallelGC—— 并行 GC 在高并发 IO 场景下会引发大量java.lang.OutOfMemoryError: Direct buffer memory因 Netty 的PooledByteBufAllocator无法及时回收堆外内存。5.3 瓶颈定位三板斧从 GC 日志到线程堆栈压测中实时监控执行以下命令# 1. 查看 GC 频率每 5 秒刷新 jstat -gc $(jps | grep LiveServerApplication | awk {print $1}) 5000 # 2. 导出线程堆栈发现阻塞点 jstack $(jps | grep LiveServerApplication | awk {print $1}) thread_dump.log # 3. 监控堆外内存Netty 关键指标 jcmd $(jps | grep LiveServerApplication | awk {print $1}) VM.native_memory summary典型瓶颈与修复指标异常根本原因解决方案jstat输出G1YGC每秒 3~5 次StreamTranscoder中ByteBuffer.allocateDirect()频繁创建堆外缓冲区在TranscodeService初始化时预分配ByteBufferPool复用 100 个DirectByteBufferthread_dump.log出现 200WAITING状态的NettyRtmpHandler线程FFmpegProcessManager的processCache未加锁多线程争抢同一Process实例改用ConcurrentHashMapString, FFmpegProcesskey 为streamKeyjcmd ... native_memory显示Internal内存持续增长Spring Security的SecurityContextPersistenceFilter未清理ThreadLocal在WebSecurityConfig中添加Bean public SecurityContextRepository securityContextRepository() { return new HttpSessionSecurityContextRepository(); }6. 从源码到生产我踩过的 3 个「看似小、实则致命」的交付坑最后说点掏心窝子的话——这个.zip包不是拿来即用的玩具而是你亲手搭起一座桥的桥墩。我去年用它交付一个医疗问诊直播系统上线前一周还在填三个坑现在把它们刻进骨头里第一个坑时区错位导致录播文件名乱码live-server的RecordService用LocalDateTime.now()生成文件名但服务器时区是UTC而医院要求Asia/Shanghai。结果录播文件存成2024-01-01T00:00:00.mp4医生反馈「看不到今天上午的录像」。解决方法不是改代码而是在application.yml加spring: jackson: time-zone: Asia/Shanghai web: locale: zh_CN然后所有LocalDateTime自动转为东八区时间。教训Java 8 的时间 API 天然带时区陷阱宁可全局配置别在每个 Service 里withZoneSameInstant(ZoneId.of(Asia/Shanghai))。第二个坑FFmpeg 进程僵尸化吃光内存压测时发现top里ffmpeg进程越来越多ps aux \| grep ffmpeg \| wc -l达 200。根源是FFmpegProcessManager.destroyProcess()只调process.destroy()没调process.waitFor()等待进程彻底退出。补丁很简单public void destroyProcess(String key) { Process p processCache.remove(key); if (p ! null) { p.destroy(); try { p.waitFor(5, TimeUnit.SECONDS); } catch (Exception e) {} // 加超时等待 } }后悔药上线前必须killall ffmpeg清空残留再用ps aux \| grep ffmpeg验证为 0。第三个坑MyBatis-Plus 的TableLogic与直播状态冲突StreamRoom类用了TableLogic注解标记deleted字段本意是软删除。但直播场景中「房间结束」不等于「逻辑删除」status2的房间仍需被查询用于回放。结果list()接口永远查不到已结束房间。最终方案是删掉TableLogic在StreamRoomMapper.xml中手动写WHERE deleted0 AND status IN (0,1,2)。血泪经验ORM 的「约定优于配置」在业务复杂时就是枷锁该写 XML 就写 XML别迷信注解。希望帮到你。本文还有配套的精品资源点击获取