Java实现网页弹幕：WebSocket长连接教程

本文深入剖析了Java实现网页弹幕系统时的关键技术难点与实战避坑指南：从WebSocket连接后弹幕“石沉大海”的根源——Session意外关闭、异步发送遗漏和轮询滥用，到服务端统一时间归一化（offsetMs）解决前端渲染不一致；从高并发下synchronized广播导致的性能瓶颈，到用CopyOnWriteArraySet+预过滤提升吞吐；再到绕过前端防护的XSS攻击风险，强调后端必须基于白名单（如Jsoup.clean）严格清洗内容。文章直击“偶尔丢弹幕”这类隐蔽问题的本质——客户端时钟偏差与session集合弱一致性，并指出弹幕系统的真正挑战不在连接本身，而在于全链路消息生命周期的精准管控。

WebSocket 连接建立后收不到弹幕消息？检查 Session 是否被意外关闭

Java 后端用 WebSocketHandler 或 @OnMessage 接收前端消息时，常见问题是连接看似建立成功，但后续发来的弹幕数据根本没进处理逻辑。核心原因往往是：Spring 的 WebSocketSession 在 handler 执行完方法后被自动关闭，尤其在用了异步操作（比如往 ConcurrentHashMap 里写入后没主动调用 session.sendMessage()）或未捕获异常时。

• 确保每次广播弹幕前，先用 session.isOpen() 判断连接状态，避免 IllegalStateException: The session is closed
• 不要在 @OnOpen 里启动线程池轮询推送；改用 SimpMessagingTemplate.convertAndSend() 或直接调用 session.sendMessage()
• 若用 TextMessage 发送 JSON，注意字符编码：必须用 new TextMessage(jsonString.getBytes(StandardCharsets.UTF_8))，否则中文变乱码

前端弹幕飞过太快看不清？服务端别直接透传原始时间戳

很多实现让前端自己解析 timestamp 并计算入场位置和持续时间，结果不同设备渲染帧率不一致，弹幕速度忽快忽慢。真正可控的做法是：服务端统一做时间归一化，把“发送时刻”转成相对当前服务端时间的偏移毫秒值，并限制最小间隔。

• 发弹幕时，后端记录 System.currentTimeMillis()，减去客户端传来的 clientTime 得到网络延迟补偿值
• 实际推送给所有客户端的弹幕对象里，用 offsetMs 字段代替绝对时间，前端只负责按这个 offset 做延时入场
• 对同一用户连续发送的弹幕，服务端应拦截 interval < 500 的请求（单位毫秒），防止刷屏

大量并发连接下 CPU 占用飙升？慎用 synchronized 包裹广播逻辑

当在线人数超千级，用 synchronized (broadcastLock) { sessions.forEach(...); } 做群发，会形成强竞争点，导致线程阻塞、吞吐骤降。这不是锁粒度问题，而是设计层面没避开共享状态。

• 改用 CopyOnWriteArraySet 存储活跃会话，遍历时无需加锁
• 广播前先用 sessions.stream().filter(WebSocketSession::isOpen).toList() 过滤，避免反复调用 isOpen() 触发底层心跳检测开销
• 如果用 Netty 实现自定义 WebSocket 服务，务必禁用 ChannelOption.AUTO_READ 默认行为，改用手动 channel.read() 控制读取节奏

弹幕内容含 HTML 标签被 XSS 攻击？过滤不能只靠前端 textContent

有开发者觉得“前端用 textContent 渲染就安全”，但攻击者可在连接建立阶段发恶意 payload，比如通过 WebSocket 消息注入 ，一旦后端没过滤就存库或透传，后续任何页面加载该历史弹幕都会触发。

• 后端收到弹幕文本后，必须用白名单方式清洗：只保留字母、数字、常用标点、Emoji Unicode 范围（\u1F600-\u1F64F 等），其余一律替换为空格或删除
• 避免用正则删