Java实现WebSocket主动推送消息，含客户端、服务端相关示例
时间：2026-01-16 来源： 本站 阅读：次
现今，不管是我们运用手机应用之时，还是翻动游览网页途中，差不多都有着感觉消息“主动”于眼前呈现开来的推送服务体验。这背后是客户端跟服务端不断进行沟通然后产生的结果，而达成这种实时数据交换的技术方案，其选择直接会对于应用的性能以及用户体验产生关联 。
轮询拉取数据
Testing websockets
最基础的方式之一是轮询，它是由客户端定时向服务器发起请求，以此来询问新消息，这种方式实现起来较为简单，就比如说一个股票行情页面能够设置成每5秒钟自动进行一次刷新 。
package com.tony.websocket;
import javax.websocket.OnClose;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;
import java.io.IOException;
@ServerEndpoint("/websocketTest")
public class WebSocketTest {
@OnMessage
public void onMessage(String message, Session session) throws IOException, InterruptedException {
// Print the client message for testing purposes
System.out.println("Received: " + message);
// Send the first message to the client
session.getBasicRemote().sendText("This is the first server message");
// Send 3 messages to the client every 5 seconds
int sentMessages = 0;
while (sentMessages < 3) {
Thread.sleep(5000);
session.getBasicRemote().sendText("This is an intermediate server message. Count: " + sentMessages);
sentMessages++;
}
// Send a final message to the client
session.getBasicRemote().sendText("This is the last server message");
}
@OnOpen
public void onOpen() {
System.out.println("Client connected");
}
@OnClose
public void onClose() {
System.out.println("Connection closed");
}
}
可是，轮询有着明显的弊端，频繁地请求，会耗费大量的网络以及服务器资源。要是信息更新并不频繁，那么大部分请求返回的皆是“无新数据”，这就导致了显著的资源浪费。
4.0.0
com.tony
wesocket
0.0.1-SNAPSHOT
javax.websocket
javax.websocket-api
1.0-rc5
provided
长连接保持通信
长时间保持打开状态的连接技术，在客户端与服务器建立一次连接后得以允许，当服务器出现新消息之时，能够借助此连接立刻推送给客户端，并不用等待客户端进行询问 。
实现真正的实时推送可通过这种方式达成，在微信之类即时通讯软件后台运行进程里被广泛运用，它极大地削减众多无效的网络进行交互行为的频次状况，然而针对服务器的连接管理方面能力需求则要树立起更高标准要求。
短连接与服务器推送
跟长连接形成对照，短连接在每一回请求与响应之后马上就关闭，然而借助Server - Sent Events等技术，服务器能够于单个响应里持续不断地发送多个数据块，以此模拟推送的效果 。
这样的方法适用于新闻更新的场景，也适用于实时评论流之类的场景。它是基于HTTP协议的，相较于WebSocket等方案而言更简单，然而，但在浏览器兼容性这方面以及功能完整性这方面上存在一定的局限。
技术框架的选择
存在多种编程语言生态，它们给出了丰富的推送框架。于Java这个领域，Netty框架凭借其高性能以及异步事件驱动模型，常常被运用来搭建IM系统的后端服务。
而Go语言依靠其轻量级协程，同样极其适宜编写高并发的推送服务中间件。开发者对于其要选取的话，得依据项目大小、团队技术体系和确切的性能标准来进行权衡 。
应用场景的适配
进行价格竞争比拼的系统以及能够在线共同协作编辑的工具等这些类型，对于延迟的反应是极其敏感的，一般情况下会采用WebSocket来构建全双工的长连接方式。然而当涉及到天气情况的更新或者邮件到达之后的提醒这类情况时，使用间隔时间稍微长一些的轮询方式可能就已经足够了。
在二零二四年，众多企业网站管理系统着手开展集成消息中心的工作，依据用户在线时状态，对推送策略实行智能切换，这样的一种混合方案，于保证实时性之际，还兼顾到了服务器成本。
实现中的核心考量
在实际开展开发期间，是除开技术选型之外的，还需要去考量消息的可靠投递情况，以及连接保活这块，还有心跳检测方面，以及海量连接情形下的扩容这个问题。而一个具备健壮性的推送服务是需要有配套的监控机制以及预警机制的。
比如说，要设计出重连机制来应对网络出现的波动情况，利用唯一ID确保消息不会出现丢失现象。在客户端这边，需要妥善处置应用切换到后台之际的连接策略，以此来平衡实时性以及电量消耗。
在您开展或者运用各类应用期间，有没有曾经由于消息推送出现延迟这种状况，或者过于频繁地去打扰您，从而让您产生困扰呢？要是有请欢送到评论区域那儿去分享您所经历的事情以及您内心的看法，要是您以为本文能够起到帮衬作用，那也请点个赞予以支持 。
