简介：这是一套基于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-RTMP），Java 后端通过 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.0，Redis 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?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/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。另外serverTimezone=Asia/Shanghai不能省，否则 MyBatis 查询时间字段会报错。
3.3 OBS 推流 + FFplay 拉流：用一条命令验证源码是否真的通
配置改完，启动 Java 后端：
mvn clean install -DskipTests cd live-server nohup java -jar target/live-server.jar --spring.profiles.active=dev & cd ../live-im nohup java -jar target/live-im.jar --spring.profiles.active=dev &后端起来后，用 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 弹幕与 IM：WebSocket 接入与消息广播
一份能跑的直播源码，通常只把视频链路做通了，弹幕和礼物往往是简版实现。如果你的目标是拿这套源码做二次开发，第一件要做的事就是把弹幕模块从“轮询”改成“长连接推送”。常见的做法是用 Netty 单独开一个服务，端口和业务端口分开，客户端通过 WebSocket 连接上来，然后按直播间维度做分组广播。
以 Netty 的实现为例，核心逻辑是维护一个ChannelGroup的映射，key 是直播间 ID，value 是这个房间里所有连接的 Channel：
// 弹幕消息广播的核心结构 public class ChatRoom { // key: roomId, value: 该房间所有客户端连接 private static final ConcurrentHashMap<Long, 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 Map<String, 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.1，SRS 和 Java 不在一台机器上，回调打不到 Java。第二个是云服务器安全组没放行 TCP 1935（RTMP）、1985（SRS API）和 8080 端口。
解决：回调地址改成内网 IP，安全组按端口放行。这里还要注意一点，如果 Java 和 SRS 都在同一台机器，回调地址用127.0.0.1没问题；但只要 SRS 是独立机器，这个地址必须改成 SRS 能访问到的 Java 机器内网地址。每次排查这类问题，先curl一下回调地址，确认 SRS 能访问到再往下查。
5.5 数据库连接池被打满：直播间的状态轮询写坏了
现象：直播间人数过千后，MySQL 连接数飙升，最终报Too many connections，直播间集体卡死。原因很典型——前端每隔几秒轮询一次直播间状态接口，而这个接口内部如果用 MyBatis 直接查数据库，每次轮询都是一次完整的事务查询。一千人在线，每秒就有几百次数据库查询，连接池自然被打爆。
解决：把直播间状态、在线人数、礼物总值这些高频读数据全部放到 Redis，Java 接口只查 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 部分写得再漂亮，流媒体链路不通就是白搭。看源码时先画链路图，再动手改配置，最后才去碰代码，这个习惯让我少踩了很多冤枉路。希望帮到你。
本文还有配套的精品资源，点击获取
