简介这是一套基于Java与Spring Boot构建的在线直播平台完整源码工程包面向具备Java基础、希望学习企业级直播业务落地的开发者。项目采用前后端分离架构涵盖腾讯云直播流接入、直播鉴黄、礼物打赏、支付宝充值提现、弹幕聊天室等核心模块能帮助读者理解直播系统从API设计、数据库建模到第三方服务集成与支付回调的全链路实现。资源包共201个文件大小约165KB以194个Java源文件为主体兼顾SQL数据库脚本、yml工程配置、XML配置、HTML页面及JSON数据等结构属于典型Spring Boot工程布局便于按模块拆解与运行调试。目前已有1916人学习下载适合用于二次开发、毕业设计参考或直播业务源码研读。1. 基于Java开发的在线直播平台源码拿到手先分清它是玩具还是骨架一提直播平台大多数人默认这是 C 或 Go 的地盘Java 顶多做个后台管理。但你要是真正在线上环境里被压垮过一次就会明白视频流只是直播的壳壳里面全是状态同步、消息分发、连麦信令、礼物订单和并发计数这才是 Java 的主场。这份基于Java开发的在线直播平台源码核心价值不在于“能不能播”而在于它把推流接入、业务 API、弹幕 IM、播放鉴权这一整套链路用 Java 串了起来。它能解决的是从零搭一个可扩展直播后台的问题适合三类人正在做 Java 课程设计的学生、想快速搭建直播业务原型的后端工程师、以及准备把直播模块嵌入现有 Spring Cloud 体系的团队。先别急着点运行这套源码的坑多半不在 Java 代码里而在你对着流媒体协议发呆的那半个小时。2. 打开这套 Java 直播源码先搞懂它把直播拆成了哪几块2.1 数据链路与模块推流不是你想象的一根管道在线直播从数据流向上看至少分成三条独立管线很多新手拿到源码后只盯着视频流看结果把另外两条完全忽略。第一条是视频链路主播端通过 RTMP 协议把视频推到流媒体服务器流媒体服务器转成 HTTP-FLV 或 HLS 分发给观众端。第二条是信令链路主播开播、关播、踢人、切换清晰度这些控制消息走的是 HTTP 接口或 WebSocket。第三条是互动链路弹幕、礼物、点赞、在线人数全部走长连接推送。这套源码里 Java 负责的是第二和第三条链路的绝大部分以及第一条链路的“边缘部分”——不是转发视频本身而是处理推流地址的鉴权、流状态的回调、播放地址的签发。理清这个边界非常重要如果你拿到源码后到处找“RTMP 转发实现”大概率找不到因为这不是 Java 该干的活。常见做法是配一个独立的流媒体服务比如 SRS 或 Nginx-RTMPJava 后端通过 HTTP 回调感知流的上下线再通过 API 生成带鉴权的拉流地址。2.2 目录结构与关键类先用十分钟定位核心代码拿到解压后的工程先别急着用 IDEA 打开先看目录把模块边界画出来。基于 Java 的直播平台源码业内常见的结构是把工程拆成几个 Maven 模块一个live-common放公共类一个live-server放业务接口一个live-im放长连接服务一个live-admin放运营后台。live-platform/ ├── live-common/ # 公共模块实体、工具、常量 │ ├── src/main/java/com/live/common/ │ │ ├── model/ # 直播间、礼物、用户实体 │ │ └── util/ # Token 生成、签名工具 ├── live-server/ # 业务后端直播间的 CRUD 与鉴权 │ └── src/main/java/com/live/server/ │ ├── controller/ # Rest API创建直播间、生成推流地址 │ ├── service/ # 业务逻辑开播、关播、状态流转 │ └── mapper/ # MyBatis 数据访问 ├── live-im/ # 长连接服务弹幕、礼物、在线人数推送 │ └── src/main/java/com/live/im/ │ ├── netty/ # Netty 服务端与 ChannelHandler │ └── protocol/ # 自定义消息协议编解码 ├── live-admin/ # 运营后台房间管理、流状态查看、录制管理 └── sql/ # 建表脚本以我的经验你打开源码后最先应该读三个类controller/LiveRoomController.java看房间接口怎么设计的netty/ChatServer.java看长连接怎么启动的service/StreamCallbackService.java看流媒体回调怎么接的。这三个类读明白了整套源码的骨架就清楚了。2.3 依赖选型为什么是 Netty Spring Boot Redis直播源码的技术选型不是拍脑袋决定的每一层都有明确理由。业务接口层用 Spring Boot 是顺手的事社区生态成熟和 MyBatis、Redis、消息队列的整合成本最低。长连接层用 Netty 而不是 Tomcat 的 WebSocket原因很直接Netty 对 TCP 连接的承载能力远高于 Tomcat 的线程模型一个直播间几万人同时发弹幕Tomcat 的线程池会先被打满而 Netty 的 EventLoop 模型可以轻松扛住十万级连接。状态层用 Redis 而不是本地 Map是因为在线人数、礼物总值这些数据要被多个服务实例共享。你可以看到源码里大概率有类似RoomOnlineCountService这样的类内部就是redis.incr和redis.expire的组合。如果源码里用的是本地ConcurrentHashMap说明这份源码只适合单机 Demo上生产前必须换掉。消息推送层很少直接每个直播间维护一个线程常见做法是引入消息队列做削峰弹幕先写 Kafka 或 RocketMQ再由 IM 服务批量推给客户端。值得注意的一个点是流媒体转发一般不落在 Java 里而是由独立的 SRS 或 Nginx 承担。源码里的StreamCallbackService就是接收流媒体服务器发来的 HTTP 回调更新直播间状态为“直播中”或“已结束”。这是 Java 和流媒体服务器的唯一交集。3. 本地跑通最小闭环推流、转发、播放三步走3.1 准备环境JDK、MySQL、Redis、流媒体服务一个不能少在本地把整套源码跑起来前期准备最容易翻车很多人卡在“代码没问题但就是黑屏”。先把依赖装齐JDK 建议 1.8 以上Maven 3.6 以上MySQL 5.7 或 8.0Redis 5 以上。流媒体服务选 SRS这也是目前 Java 直播后端对接最顺的方案下载 release 包解压即可不需要编译。# 以 CentOS 或 macOS 为例安装基础依赖 yum install -y java-1.8.0-openjdk-devel maven mysql-server redis # 启动 MySQL 和 Redis systemctl start mysqld systemctl start redis # 导入源码自带的建表脚本 mysql -uroot -p sql/live_platform.sql # 下载并启动 SRS 流媒体服务器 wget https://github.com/ossrs/srs/releases/download/v3.0-r0/srs-3.0-r0-linux-amd64.zip unzip srs-3.0-r0-linux-amd64.zip cd srs-3.0-r0-linux-amd64 ./objs/srs -c conf/srs.conf这段命令的含义很直白前两步保证有地方存业务数据和在线状态第三步把表结构建好第四步启动一个监听 1935 端口的 RTMP 服务器。SRS 默认配置已经能工作但有一点必须确认——srs.conf里的http_api要打开否则 Java 后端无法调用 SRS 的 API 去查询流状态。检查方式很简单打开配置文件看有没有api段落没有的话手动加上listen 1935; max_connections 1000; http_api { enabled on; listen 1985; }3.2 配置改三处连库、连 Redis、对流媒体回源地址环境起来后改配置这套源码不用全改重点改三个文件application.yml或application.properties、redisson.yml如果用 Redisson 的话、以及 SRS 的回调地址配置。第一次跑通的关键是让 Java 后端知道去哪里连 MySQL、去哪里连 Redis、以及 SRS 回调要打到哪个端口。# application.yml 核心配置 server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/live_platform?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password redis: host: 127.0.0.1 port: 6379 database: 0 live: # 流媒体配置SRS 的 HTTP API 地址和回调地址 srs: api: http://127.0.0.1:1985 callback: http://127.0.0.1:8080/live/callback配置里的live.srs.api是 Java 调用 SRS 查询流列表、踢流用的live.srs.callback是 SRS 在推流开始和结束时回调 Java 后端的地址。第二个地址容易理解但第一个地址很多人会踩坑——如果 SRS 和 Java 不在同一台机器127.0.0.1要改成 SRS 所在机器的内网 IP。另外serverTimezoneAsia/Shanghai不能省否则 MyBatis 查询时间字段会报错。3.3 OBS 推流 FFplay 拉流用一条命令验证源码是否真的通配置改完启动 Java 后端mvn clean install -DskipTests cd live-server nohup java -jar target/live-server.jar --spring.profiles.activedev cd ../live-im nohup java -jar target/live-im.jar --spring.profiles.activedev 后端起来后用 OBS 或 FFmpeg 模拟主播推流。FFmpeg 更轻量适合验证链路命令如下# 用 FFmpeg 推送一个测试视频流到本地 SRS ffmpeg -re -i test.mp4 -c copy -f flv rtmp://127.0.0.1:1935/live/room_001推流成功后SRS 会向 Java 回调地址发一个 HTTP 请求StreamCallbackService收到后把房间状态改为直播中。这时候用 FFplay 拉流验证# 拉取 HTTP-FLV 流验证播放链路 ffplay http://127.0.0.1:8080/live/room_001.flv注意这个地址不是 SRS 直接提供的而是 Java 后端生成的播放地址通常带 Token 鉴权参数。整个闭环的意思是FFmpeg 推到 SRS → SRS 回调 Java → Java 更新房间状态并生成播放地址 → 播放端拿着带签名 Token 的地址从 SRS 拉流。如果 FFplay 能正常出画面说明这条链路已经通了。如果黑屏先别怀疑 Java用ffprobe http://127.0.0.1:8080/live/room_001.flv看看 SRS 那边有没有流输出。4. 从能看到能商用补齐弹幕、在线人数与录制回放的实现4.1 弹幕与 IMWebSocket 接入与消息广播一份能跑的直播源码通常只把视频链路做通了弹幕和礼物往往是简版实现。如果你的目标是拿这套源码做二次开发第一件要做的事就是把弹幕模块从“轮询”改成“长连接推送”。常见的做法是用 Netty 单独开一个服务端口和业务端口分开客户端通过 WebSocket 连接上来然后按直播间维度做分组广播。以 Netty 的实现为例核心逻辑是维护一个ChannelGroup的映射key 是直播间 IDvalue 是这个房间里所有连接的 Channel// 弹幕消息广播的核心结构 public class ChatRoom { // key: roomId, value: 该房间所有客户端连接 private static final ConcurrentHashMapLong, ChannelGroup ROOM_GROUPS new ConcurrentHashMap(); // 用户加入直播间 public static void join(Long roomId, Channel channel) { ChannelGroup group ROOM_GROUPS.computeIfAbsent(roomId, k - new DefaultChannelGroup(GlobalEventExecutor.INSTANCE)); group.add(channel); // 给房间内其他人广播“xxx进入直播间” String msg {\type\:\join\,\userId\:\ channel.attr(AttributeKey.valueOf(userId)).get() \}; group.writeAndFlush(new TextWebSocketFrame(msg)); } // 用户发弹幕 public static void sendMessage(Long roomId, String message) { ChannelGroup group ROOM_GROUPS.get(roomId); if (group ! null) { group.writeAndFlush(new TextWebSocketFrame(message)); } } }这段代码的关键在于ROOM_GROUPS这个全局 Map 的设计。每个直播间维护一个ChannelGroup当有用户断开时Netty 的channelInactive回调里要记得调用group.remove(channel)否则这个房间的连接数会只增不减最终把内存耗尽。这是弹幕服务最常见的隐性问题——看起来运行正常但跑一天后内存就涨上去了。4.2 在线人数统计Redis 原子计数与过期策略直播间的在线人数统计看起来是个简单计数器实际上最容易出并发问题。常见实现是每次心跳incr用户断开decr但这样会有两个问题一是心跳和断开的时机对不上人数会飘二是用户直接关浏览器没有正常断开人数只增不减。靠谱的实现在源码里通常是 Redis 的incr expire配合心跳续期。具体逻辑是每个用户进入直播间时以room:online:{roomId}为 key用HyperLogLog或Set记录用户 ID同时设置过期时间。每收到一次心跳就更新过期时间这样超时未心跳的用户会被 Redis 自动清理。// 用户心跳续期 去重统计 public void heartbeat(Long roomId, Long userId) { String key live:room:online: roomId; // 把 userId 加入去重集合过期时间 120 秒 redisTemplate.opsForSet().add(key, userId.toString()); redisTemplate.expire(key, 120, TimeUnit.SECONDS); } // 获取直播间的实时在线人数 public Long getOnlineCount(Long roomId) { String key live:room:online: roomId; return redisTemplate.opsForSet().size(key); }这里有个细节值得注意为什么用 Set 而不是简单的incr因为用户断线重连、切后台再回来incr会被重复计数而 Set 天然去重。120 秒的过期时间要和你前端的保活心跳间隔匹配——前端每 30 秒发一次心跳那 120 秒过期时间就是安全的如果前端心跳间隔是 60 秒过期时间建议调到 180 秒以上否则高峰期会误删在线用户。4.3 录制回放回调对接与低频任务转封装直播做完后要能看回放这部分 Java 后端做编排FFmpeg 做真正的转码。SRS 支持在推流开始时回调 Java 接口Java 收到回调后启动一个录制任务// 收到 SRS 推流开始回调后启动录制 PostMapping(/live/callback/on_publish) public String onPublish(RequestBody MapString, Object body) { String streamId (String) body.get(stream); // stream 形如 live/room_001 String roomId streamId.split(/)[1]; // 启动 FFmpeg 录制线程拉 RTMP 流转存为 FLV 文件 String cmd String.format( ffmpeg -i rtmp://127.0.0.1:1935/live/%s -c copy /data/record/%s.flv, roomId, roomId); Runtime.getRuntime().exec(cmd); // 记录录制任务状态到数据库 recordMapper.insert(roomId, recording); return {\code\:0}; }这段逻辑里有两个坑。第一个是exec启动的 FFmpeg 进程不受 Spring 容器管理进程崩溃没人知道建议用ProcessBuilder接管并记录 PID或者干脆独立成一个定时任务去检查每五分钟查一次录制任务发现进程不在了就重启。第二个坑是 FLV 文件不能直接做回放你得在直播结束后跑一次转封装把 FLV 转成 MP4 以支持拖拽播放。别在回调里同步做转码直播刚断流 CPU 正忙转码会拖垮主业务。正确的做法是收到断流回调后只更新数据库状态由一个定时任务扫描“待转码”的录制记录逐个处理。5. 直播源码常见的坑从黑屏到延迟飙升的排查笔记5.1 推流正常但播放黑屏先查关键帧间隔现象FFmpeg 推流没有报错SRS 控制台也能看到流但播放端就是黑屏或一直转圈。这个问题我在验收源码时几乎每次都遇到十次里有八次不是代码问题而是推流端的 GOP 设置不对。直播要求关键帧间隔GOP不能太长如果推流端用默认设置两个关键帧之间可能隔了 4 到 5 秒播放端要等下一个关键帧才能出画面表现就是黑屏。解决在 FFmpeg 推流命令里显式加-g 60 -keyint_min 60强制每 2 秒一个关键帧。OBS 里则在“输出→高级→关键帧间隔”里填 2。如果是在源码的推流端代码里控制编码器那就检查 X264 编码器的gop_size参数。还有一个隐蔽点有些源码会在播放端做缓冲如果你在代码里看到播放器初始化时缓冲设得很大黑屏时间会被拉长顺手把初始缓冲压到 300ms 以内。5.2 延迟越拉越大缓冲积压和 GOP 缓存是主因现象刚连上时延迟 1 秒播了十分钟变成 5 秒半小时后延迟到 10 秒以上观众和主播对不上话。这是直播里最常见的“延迟漂移”问题原因基本有两类。一类是播放端的缓冲区策略如果播放器实现是“宁可等着也不丢帧”网络抖动时缓冲区一直堆积延迟自然越来越大。另一类在流媒体服务端SRS 或 Nginx-RTMP 默认会开启 GOP 缓存这个缓存是为了解决播放端尤其是 HLS 场景画面卡顿的但它会让新加入的观众从关键帧开始播放延迟被硬生生拉高。解决播放端开启追帧策略当缓冲超过阈值时主动丢帧。服务端则调节 SRS 的配置把gop_cache关掉或者改为按房间配置。以 SRS 为例vhost __defaultVhost__ { play { gop_cache off; # 关闭 GOP 缓存 queue_length 5; # 播放队列只缓冲 5 秒 } }改完重启 SRS延迟会明显收窄。代价是网络抖动时画面可能短暂卡顿这是延迟和流畅度的经典取舍没有两全方案。5.3 线上人数一多弹幕服务就崩线程模型和心跳没做好现象本地测试 20 个连接一切正常放到服务器上跑到两千人弹幕延迟明显甚至出现大面积断线重连。这个坑要分两层看。第一层是 Netty 的 bossGroup 和 workerGroup 线程数没调。默认的EventLoopGroup线程数是 CPU 核数乘以二对长连接场景够用但如果源码里每个连接都做了耗时的同步数据库操作则会阻塞 IO 线程。第二层是心跳机制设计不合理。很多源码的断线判定只在服务端做readTimeout客户端没有主动发送心跳。移动网络下 TCP 连接半开状态普遍存在服务端迟迟等不到数据也不主动断开导致僵尸连接占满 Channel 资源。解决服务端把读超时设为 60 秒客户端每 30 秒发送一个 Ping 消息服务端收到 Ping 回 Pong。连续三次没收到 Pong 就主动关闭连接。这一个改动就能让弹幕服务扛住几倍的压力。如果源码里没有心跳优先补这个。5.4 公网部署后一直拉不起流回调地址和防火墙现象本地一切正常部署到云服务器后推流提示成功但观众端一直进不去直播间后端日志里也没有收到 SRS 回调。排查后通常是两个原因。第一个是回调地址配置成了127.0.0.1SRS 和 Java 不在一台机器上回调打不到 Java。第二个是云服务器安全组没放行 TCP 1935RTMP、1985SRS API和 8080 端口。解决回调地址改成内网 IP安全组按端口放行。这里还要注意一点如果 Java 和 SRS 都在同一台机器回调地址用127.0.0.1没问题但只要 SRS 是独立机器这个地址必须改成 SRS 能访问到的 Java 机器内网地址。每次排查这类问题先curl一下回调地址确认 SRS 能访问到再往下查。5.5 数据库连接池被打满直播间的状态轮询写坏了现象直播间人数过千后MySQL 连接数飙升最终报Too many connections直播间集体卡死。原因很典型——前端每隔几秒轮询一次直播间状态接口而这个接口内部如果用 MyBatis 直接查数据库每次轮询都是一次完整的事务查询。一千人在线每秒就有几百次数据库查询连接池自然被打爆。解决把直播间状态、在线人数、礼物总值这些高频读数据全部放到 RedisJava 接口只查 Redis不回源数据库。数据库只在开播和关播时写入一次状态变更。这个改动对源码结构影响不大但能直接把数据库压力降两个数量级。到了这一步你手里这套源码才真正具备支撑线上小规模运营的能力。6. 把 Demo 做成能运营的直播面延迟调优与分发延伸当核心链路跑通下一步就是延迟和分发质量。直播的端到端延迟由四段组成推流端编码缓冲、流媒体服务器转发、CDN 分发、播放端缓冲。Java 能控制的是最后一段以及通过配置间接控制前两段。HTTP-FLV 在源站层面可以把延迟压到 2 到 3 秒WebRTC 可以压到 500 毫秒以内但 WebRTC 需要额外的信令服务和媒体网关不是简单改配置就能接入的。我建议的路线是先用 HTTP-FLV 上线把交互延迟控制在 3 秒内等业务验证通过再评估 WebRTC。延迟调优优先级排序第一是播放端追帧策略第二是关闭 GOP 缓存第三是推流端关键帧间隔设为 2 秒第四是 CDN 分发的回源超时配置。前三项在上面已经说过第四项在你没有自建 CDN 时可以暂时跳过但如果你用云厂商的 CDN 分发直播流记得把回源超时调到 3 到 5 秒否则主播推流抖动时 CDN 会频繁回源反而加剧卡顿。# 拉流侧同时开启追帧ffplay 示例 ffplay -fflags nobuffer -flags low_delay -framedrop \ -analyzeduration 1000000 -probesize 1000000 \ http://127.0.0.1:8080/live/room_001.flv这几个参数的含义是nobuffer禁用输入缓冲framedrop允许丢帧追时间analyzeduration和probesize缩短探测时长以降低首屏耗时。这套参数同样适配 VLC 以外的自定义播放器移动端播放器如 ijkplayer也有对应的framedrop和packet-buffering开关。我每次验收一套直播源码第一件事就是把推流端 GOP 拉到 2 秒然后看首屏时间。首屏超过 1.5 秒就调整播放器参数而不是去怀疑后端代码——直播的卡顿有七成是播放器策略问题源码本身的问题反而是少数。直播源码是典型的“入门容易精通难”Java 部分写得再漂亮流媒体链路不通就是白搭。看源码时先画链路图再动手改配置最后才去碰代码这个习惯让我少踩了很多冤枉路。希望帮到你。本文还有配套的精品资源点击获取