做实时推送、在线IM、行情订阅这类系统只要网络一波动WebSocket连接就可能悄悄断掉而你的代码如果不做处理用户那边就永远卡在一个连接已断开的假死状态。这算是Java后端做WebSocket最常踩的坑之一客户端没有心跳、没有重连、没有消息补偿断线之后一切都停摆了。这篇文章我想围绕java-websocket断线重连这个主题把一套能直接落地的完整方案拆开讲透从为什么断、怎么检测到用什么策略重连、断线消息怎么补发全部用Java代码体现适合正在做实时通信功能、或者想在项目里接入WebSocket但对稳定性心里没底的开发者参考。我早期做某个实时行情推送项目时服务端每天晚上都会自动发版重启客户端连接瞬间全断。当时客户端逻辑很简单打开连接、收数据、断开就提示网络异常然后用户得手动刷新页面。这个体验有多糟糕用过的人都知道。后来我把断线重连做进客户端才彻底告别了那种一断就死的状态。下面就把这套方案的经验和代码整理出来希望能帮你少走点弯路。1. 为什么WebSocket连接说断就断先搞清楚病根不先把断线原因摸清楚后面的重连机制做得再花哨也是瞎忙活。WebSocket连接不是一根埋在地下的水管埋好就永远不漏。它是一条基于TCP的持久连接TCP层一旦出问题上层协议一点办法都没有。我把日常工作中最常见的断线原因分成两类一类是网络环境的隐形杀手一类是服务端和客户端自己的人为事故。1.1 网络环境的隐形杀手第一类就是NAT超时。在公司上网、或者用手机流量访问服务器时中间基本都会经过一层NAT设备路由器、运营商网关。NAT设备为了节省资源会在映射表里给每条连接设置一个超时时间正常情况下可能几分钟到几十分钟不等常见的有2分钟、4分钟、5分钟。如果这条TCP连接在这段时间内没有任何数据往来NAT设备就会静默地把这条映射记录删掉。结果就是客户端以为连接还活着服务端也以为连接还活着实际上中间的链路已经断了。后续任何数据包都发不过去而客户端只有在真正尝试发送时才会感知到异常。第二类是代理和网关的空闲超时。如果你在WebSocket前面挂了Nginx、HAProxy这类反向代理它们默认会对空闲连接做回收处理比如Nginx的proxy_read_timeout默认值是60秒意味着60秒内如果没有从上游读到数据连接就会被主动关闭。很多WebSocket服务端的默认心跳间隔又恰好超过这个值那就必然会出现莫名其妙掉线的问题。第三类是网络切换。手机从WiFi切到4G/5G、或者从4G切到5GIP地址和TCP连接都会失效。这类断线是瞬时的客户端根本来不及知道只有在下次心跳或者发送数据时才会发现连接已经废了。1.2 服务端与客户端的主动断连服务端主动断开最常见的就是发版、重启。服务进程一停所有连接立刻被操作系统回收。线上发布如果没做过优雅停机前端大概率会看到一大批1006异常码。还有一种情况是服务端自己做了空闲踢人比如某些IM系统规定超过一定时间没有活动的连接直接关闭这也是合理的资源保护策略。客户端这边的主动断连就更多了最常见的是程序出错、内存溢出导致崩溃或者客户端进程被系统回收。还有一种容易被忽略的场景客户端App进入后台后系统把网络权限收走了连接虽然没有触发onClose但实际上已经不可用这时候如果唤醒回前台必须先做一次连接活性检测。1.3 状态码隐含的信息排查断线原因时WebSocket的关闭状态码是很重要的线索。我整理了一份常见状态码和对应的处理建议你可以直接参考。状态码含义常见场景是否需要重连1000正常关闭两端协商后主动关闭视业务情况不要无脑重连1001服务端正在重启服务端发版、停机维护需要且要配合等待期1002协议错误数据格式不符合规范检查代码不建议立即重连1006异常关闭网络中断、TCP连接被重置必须重连1011服务端内部错误服务端程序异常需要但要注意频率看到1006这种异常关闭码基本不用多想直接进重连流程。而如果是1000这种正常关闭很可能是用户主动退出或者服务端主动踢人这时候要么不重连要么延迟一段时间再连否则会给服务端造成压力。这个区分必须要在重连逻辑里做不能把所有关闭都当成故障处理。2. 方案选型Java生态里的WebSocket客户端到底怎么选明确了断线原因之后接下来要解决用什么来做。Java生态里做WebSocket客户端常见的方案就那么几个原生API、Java-WebSocket库、Spring WebSocket、Netty、OkHttp。很多人一开始会纠结其实只要搞清楚自己的场景选择并不难。2.1 三套主流方案横向对比我列一张对比表把最常见的选择放在一起看维度Java-WebSocket库Spring WebSocketNetty原生JDK API封装程度高回调清晰高但偏服务端低需自己封装低几乎没有封装学习成本低API简单中需理解Spring抽象高需理解异步模型中重连支持无内置需自己写无内置需自己写无内置需自己写需自己写心跳支持有Ping/Pong封装需自己编帧需自己实现需自己实现适用场景独立客户端、快速集成Spring全家桶项目高并发网关、自研协议极简单的连接需求其实看这张表就很清楚了所有方案都没有现成的断线重连和心跳机制最终都要自己写。区别只是底层库帮你做了多少。Spring WebSocket虽然生态完整但它的设计重心在服务端处理起客户端连接来反而没那么顺手。Netty性能好但开发量真的大除非你在做一个自定义协议的网关否则用Netty做WebSocket客户端有点大材小用。原生JDK那个API我是不建议直接用的写起来繁琐而且对Ping/Pong支持不够友好。2.2 为什么我推荐Java-WebSocket库做底层我最终选择了Java-WebSocket这个开源库主要看中三点。第一API设计非常直观。你需要做的事就是继承WebSocketClient类然后重写四个方法onOpen、onMessage、onClose、onError。这种事件回调模型和前端写onmessage、onclose的习惯几乎一模一样学习曲线极其平缓。第二它内置了WebSocket协议层的心跳支持。WebSocketClient类直接提供了sendPing()和sendPong()方法不需要自己拼接控制帧的字节。不要小看这一步如果直接用Netty或者原生API光是控制帧的编解码就要折腾一阵子。第三它足够轻量。整个库核心代码量不大没有依赖一堆Spring上下文非常适合嵌在任何Java项目里当客户端用。而且它的事件分发在单独的IO线程里执行配合onClose做重连触发是自然顺畅的。基于这些原因后面所有示例代码我都用Java-WebSocket库来写。如果你用的是Spring Boot项目代码一样能直接整合进去没有任何冲突。3. 断线重连三大机制详细拆解一个健壮的断线重连方案绝对不只断线了再连这一个动作。我习惯把它拆成三个机制心跳检测、重连策略、消息补偿。这三者缺一不可。只有心跳没有重连策略连上又断反复横跳只有重连没有心跳连接假死时你根本不知道要重连重连成功了不处理断线期间的消息用户就会看到数据丢失。3.1 心跳检测如何确认连接是真死还是假死先说心跳。TCP协议层面其实有保活机制即TCP KeepAlive默认情况下需要两个小时才探测一次对WebSocket这种实时业务来说完全不够用。所以必须在应用层做心跳。WebSocket协议本身定义了Ping和Pong两种控制帧。Ping是客户端或服务端主动发起的心跳探测包收到Ping的一方必须回一个Pong。在Java-WebSocket里客户端可以调用sendPing()发送Ping帧并通过重写onWebsocketPong或类似回调来接收Pong帧。这个机制用来做连接活性检测是恰到好处的。具体实现思路是客户端每隔一段时间比如30秒发送一个Ping并记录上次收到Pong的时间戳。每次收到Pong就更新这个时间戳。每次发送Ping之前先检查当前时间和最后Pong时间之差。如果超过某个阈值比如60秒就认为连接已经假死主动调用client.close()关闭当前连接从而触发onClose回调进而走进重连流程。这里要给一个基准参数建议我实测下来比较稳的组合是心跳间隔30秒、超时阈值60秒。这么设置的原因是大部分NAT设备的空闲超时在2到5分钟之间30秒的间隔能保证连接在NAT超时之前就有数据经过链路不会被动删除。而60秒的超时阈值也给了服务端和网络足够的时间去处理偶发的尖峰延迟。如果网络条件本身就差阈值可以放到90秒甚至120秒但不能无限放大否则心跳就失去了意义。还有一点要特别注意心跳必须用Ping/Pong控制帧而不是发送普通业务消息。原因有两点一是业务消息需要业务层响应服务端如果不做回执你根本不知道消息是否送达二是Ping/Pong帧在协议层面就有收到必回的语义配合它来判断连接活性是标准的做法。3.2 重连策略固定间隔还是指数退避连接断开后多久重连一次新手最容易犯的错就是写一个固定间隔的重连比如每5秒重连一次。这个方案在客户端数量少的时候问题不大但客户端一多瞬时断连比如服务端重启就会引发惊群效应成千上万个客户端同时重连服务端刚起来就被重连请求打爆导致部分连接再次失败然后又触发重连形成恶性循环。正确的做法是指数退避 随机抖动。核心思路是第一次重连等待1秒第二次2秒第三次4秒第四次8秒……计算方式是指数递增到某个上限后封顶比如60秒并且在每次计算出的延迟基础上加一个0到500毫秒之间的随机数。随机抖动的目的就是让所有客户端的重连请求错开避免扎堆。指数退避为什么靠谱因为连续重连失败往往意味着服务端或者网络出了大问题短时间内反复重连只会加剧问题。指数退避天然惩罚了连续失败的情况给服务端留出恢复时间。那要不要设置最大重连次数我的建议是保留一个最大次数比如连续重连10次之后仍然失败就不要再继续高频重连了改成长时间间隔的慢速重试比如每5分钟一次同时抛出一个告警事件让上层逻辑感知到客户端已处于离线状态。这里的关键是不能无限重试把服务端压垮也不能一次失败就彻底放弃。保持底线机制然后交给业务层决定是提示用户还是继续等待。3.3 消息补偿断线期间的消息怎么不丢心跳和重连解决了连接恢复的问题但连接断开的那段时间里用户端正常应该收到的消息以及用户端想发出去的消息该怎么办。这是很多自研WebSocket方案容易忽略的部分。消息补偿有两条链路一条是客户端发给服务端的消息另一条是服务端推给客户端的消息。先看客户端发消息这条链路。如果客户端发现连接已断开此时调用send()大概率会失败或者消息被静默丢弃。我的做法是设计一个消息队列发送消息时先判断连接是否打开如果打开就直接发如果没打开就先把消息放进队列。等重连成功后再统一把队列里的消息补发出去。这里面有个关键点——消息一定要有全局唯一的幂等标识。比如给每条消息生成一个UUID作为messageId服务端拿到这个消息后先查重如果处理过就直接返回ACK不再重复处理。这样即使重发多次也不会造成重复数据。再看服务端推送消息这条链路。重连成功后客户端要主动向服务端发起一次状态同步或增量拉取。比如记录一下断开前收到的最后一条消息的序号lastSeq重连成功后发送一个sync请求带上这个序号服务端把后续消息补推过来。这个方案的前提是服务端有消息持久化和按序发送的能力但对于IM、行情这类系统这本来就是应该有的。4. 完整实战从零打造一个可用的断线重连客户端理论知识讲完了下面进入动手环节。我会给你一套能直接复制到项目里用的代码框架包含依赖配置、核心客户端类、心跳管理器、重连策略以及Spring Boot的整合示例。代码不是我随手写的是我在项目里反复验证过、去掉业务细节后的通用骨架。4.1 项目依赖与工程结构先用Maven建一个普通的Java项目引入Java-WebSocket依赖。我这里用的是1.5.x版本也是目前比较稳定的版本。dependency groupIdorg.java-websocket/groupId artifactIdJava-WebSocket/artifactId version1.5.4/version /dependency如果你用的是Spring Boot 2.x或3.x还需要引入Spring的依赖管理这个和WebSocket本身没有直接冲突。工程结构上我建议这样组织代码分层会非常清晰com.example.ws ├── WsClient.java // 核心客户端封装对外提供连接、发送、关闭接口 ├── HeartbeatManager.java // 心跳管理器负责Ping/Pong检测 ├── ReconnectStrategy.java // 指数退避重连策略 ├── MessageQueue.java // 待补发消息队列 ├── MessageListener.java // 消息监听接口业务方实现 └── SpringWsClientConfig.java // Spring Boot 配置类核心类之间的协作关系大致是WsClient持有WebSocketClient实例HeartbeatManager在连接建立后启动、在连接关闭时停止ReconnectStrategy在onClose回调里计算下一次重连延迟MessageQueue负责存储和补发消息。4.2 核心客户端类封装连接、发送、重连触发先看最重要的WsClient。这个类把Java-WebSocket的WebSocketClient封装起来对外提供简单的connect、send、close接口。public class WsClient { private final URI serverUri; private WebSocketClient internalClient; private final HeartbeatManager heartbeatManager new HeartbeatManager(); private final ReconnectStrategy reconnectStrategy new ReconnectStrategy(); private final MessageQueue messageQueue new MessageQueue(); private final ListMessageListener listeners new CopyOnWriteArrayList(); private volatile boolean manuallyClosed false; public WsClient(URI serverUri) { this.serverUri serverUri; } public synchronized void connect() { manuallyClosed false; createInternalClient(); internalClient.connect(); System.out.println([WsClient] 发起连接: serverUri); } private void createInternalClient() { if (internalClient ! null) { try { internalClient.close(); } catch (Exception ignored) { } } internalClient new WebSocketClient(serverUri) { Override public void onOpen(ServerHandshake handshakeData) { System.out.println([WsClient] 连接已建立); reconnectStrategy.reset(); heartbeatManager.start(this); messageQueue.flushAll(this); } Override public void onMessage(String message) { // 业务消息在这里分发 for (MessageListener listener : listeners) { listener.onMessage(message); } } Override public void onClose(int code, String reason, boolean remote) { System.out.println([WsClient] 连接关闭 code code , reason reason); heartbeatManager.stop(); if (!manuallyClosed) { scheduleReconnect(); } } Override public void onError(Exception ex) { // 网络异常不一定立刻触发 close所以只记录日志 System.err.println([WsClient] 连接错误: ex.getMessage()); } }; // 这个参数是指定连接丢失检测的超时时间秒配合底层TCP探测 internalClient.setConnectionLostTimeout(HeartbeatManager.TIMEOUT_SECONDS); } private void scheduleReconnect() { if (manuallyClosed) { return; } long delay reconnectStrategy.nextDelay(); System.out.println([WsClient] delay ms 后进行第 reconnectStrategy.getAttempts() 次重连); Thread thread new Thread(() - { try { Thread.sleep(delay); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } if (!manuallyClosed) { connect(); } }, ws-reconnect-thread); thread.setDaemon(true); thread.start(); } public synchronized void close() { manuallyClosed true; heartbeatManager.stop(); if (internalClient ! null) { internalClient.close(); } } public boolean isOpen() { return internalClient ! null internalClient.isOpen(); } public boolean send(String message) { if (isOpen()) { internalClient.send(message); return true; } // 连接不可用先缓存到本地队列等重连成功后补发 messageQueue.add(message); return false; } public void addListener(MessageListener listener) { listeners.add(listener); } }这里有几个设计细节要特别说明。connect()方法用synchronized修饰是为了防止并发重连。回调线程和定时任务线程都有可能触发连接操作如果不加锁可能出现两个WebSocketClient实例同时创建底层连接一会通一会断非常难排查。另外每次创建新客户端之前先close掉旧的实例是为了释放旧连接的IO线程和文件描述符避免内存泄漏和连接句柄耗尽。manuallyClosed这个标志位很关键。当业务方主动调用close()时我们不希望触发自动重连所以置为true而正常连接断掉时它保持false在onClose里走进重连分支。这个标志位必须用volatile修饰因为它在多个线程之间共享。重连用的是独立线程加Thread.sleep而不是在onClose回调里直接同步connect()。原因很简单Java-WebSocket的onClose回调执行在WebSocket的IO线程里如果在这个线程里执行阻塞式的重连逻辑会把这个线程拖住影响后续其他事件的处理严重的会出现死锁。单独起一个线程配合sleep延迟既能避开这个问题又方便控制重连的时机。4.3 心跳管理器与重连策略实现再看HeartbeatManager。它的任务只有一个定期发Ping检查Pong超时必要时触发关闭。public class HeartbeatManager { public static final int INTERVAL_SECONDS 30; public static final int TIMEOUT_SECONDS 60; private ScheduledExecutorService scheduler; private volatile long lastPongTime 0; public void start(WebSocketClient client) { stop(); lastPongTime System.currentTimeMillis(); scheduler Executors.newSingleThreadScheduledExecutor(r - { Thread t new Thread(r, ws-heartbeat-thread); t.setDaemon(true); return t; }); scheduler.scheduleAtFixedRate(() - { long now System.currentTimeMillis(); // 先检查上次pong距今是否超时 if (now - lastPongTime TIMEOUT_SECONDS * 1000L) { System.err.println([心跳] 超过 TIMEOUT_SECONDS 秒未收到pong判定连接假死); client.close(); return; } // 发送Ping if (client.isOpen()) { client.sendPing(ByteBuffer.wrap(ping.getBytes(StandardCharsets.UTF_8))); } }, INTERVAL_SECONDS, INTERVAL_SECONDS, TimeUnit.SECONDS); } // 在收到pong时由WebSocket底层回调调用 public void onPong() { lastPongTime System.currentTimeMillis(); } public void stop() { if (scheduler ! null) { scheduler.shutdownNow(); scheduler null; } } }使用时要记得在WebSocketClient的回调里把onWebsocketPong事件转发到heartbeatManager.onPong()。Java-WebSocket的WebSocketClient类没有直接暴露onPong回调你得重写onWebsocketPong方法一些版本里回调签名是protected void onWebsocketPong(WebSocket conn, ByteBuffer message)。再来看ReconnectStrategy也就是指数退避加随机抖动的具体实现。public class ReconnectStrategy { private static final int BASE_DELAY_MS 1000; private static final int MAX_DELAY_MS 60_000; private static final int MAX_ATTEMPTS 10; private static final Random RANDOM new Random(); private int attempts 0; public long nextDelay() { attempts; if (attempts MAX_ATTEMPTS) { // 超过最大连续重连次数进入更慢的重试节奏 return 5 * 60_000L RANDOM.nextInt(1000); } long expDelay BASE_DELAY_MS * (1L Math.min(attempts, 10)); long capped Math.min(MAX_DELAY_MS, expDelay); return capped RANDOM.nextInt(500); } public void reset() { attempts 0; } public int getAttempts() { return attempts; } }这段代码计算出来的重连延迟大概是这样的序列1秒、2秒、4秒、8秒、16秒、32秒、60秒、60秒……加上抖动之后每个客户端的实际重连时间都不完全一致错峰效果就有了。重连成功后reset()会把attempts归零这样下次断线又从头开始快速恢复。特别提醒一点1L Math.min(attempts, 10)这里。如果attempts已经比较大不加Math.min直接移位会导致数值溢出变成负数那延迟时间就乱了。这种边界问题在写代码时很容易漏。消息队列MessageQueue很简单就是一个带锁的队列容我做了一下简化核心逻辑就是add和flushAllpublic class MessageQueue { private final QueueString queue new ConcurrentLinkedQueue(); public void add(String message) { queue.offer(message); } public void flushAll(WebSocketClient client) { String msg; while ((msg queue.poll()) ! null) { client.send(msg); } } }断线期间业务方调send()时消息被塞进队列重连成功后在onOpen里统一补发。这个设计虽然简单但配合消息ID幂等机制已经能解决大部分场景下的消息丢失问题了。4.4 接入Spring Boot管理客户端生命周期如果项目用了Spring Boot把WsClient做成单例Bean是常规操作。关键在于生命周期管理应用启动时连接应用关闭时优雅断开。Configuration public class SpringWsClientConfig { Bean(destroyMethod close) public WsClient wsClient() { WsClient client new WsClient(URI.create(ws://localhost:8080/ws)); client.addListener(message - System.out.println([业务] 收到消息: message)); client.connect(); return client; } }destroyMethod close保证了Spring容器关闭时会自动调用WsClient.close()把manuallyClosed置为true不再触发重连。如果不做这一步应用发布停机时可能还有后台线程在尝试重连造成应用关了还在往外打请求的诡异现象。还有一点Spring环境下最好不要用PostConstruct直接调用connect()因为此时WsClient实例可能还没完成依赖注入。把connect()调用放在Bean方法里是最稳妥的。5. 踩坑实录与调优参数速查代码部分讲完了我再把实际项目中遇到的几个高频问题、以及怎么验证这套重连机制的方法整理出来。这一部分是我最想说的很多坑是写代码时根本想不到的。5.1 我踩过的几个典型坑先说第一个坑重连触发写成双倍触发。我在第一版代码里做了两件事在onError里面调scheduleReconnect()又在onClose里面调scheduleReconnect()。结果是一次网络抖动触发两个重连线程然后两个线程各自创建WebSocketClient连接状态变得极其混乱。后来改成只在onClose里触发重连onError里只记录日志问题立刻消失。想明确告诉大家Java-WebSocket的onError和onClose不是互斥关系一次断线可能先触发onError再触发onClose重连逻辑放在onClose一个入口就够了。第二个坑connect()非阻塞导致判断失真。Java-WebSocket的connect()方法是非阻塞的它内部会创建一个线程去建立连接你调用connect()之后立刻检查isOpen()大概率是false。我见过有人写了个if (client.connect() client.isOpen())来判断连接是否成功这明显是错误用法。正确的做法是在onOpen回调里确认连接成功而不是在connect()返回值上做文章。第三个坑重连成功后没有重置退避计数器。结果就是程序运行时间越长重连间隔越大最后变成每5分钟才重连一次。用户早就失去耐心了。onOpen里必须调用reconnectStrategy.reset()我上面代码里也包含这行别漏。第四个坑心跳定时器没停导致叠加。如果每次重连都start()一个新的心跳调度器但旧调度器没有shutdownNow()那么到后面可能有十几个线程同时在发Ping。我在HeartbeatManager.start()的第一行就调用stop()就是为了清理之前残留的调度器。第五个坑服务端没有心跳机制。很多问题出在服务端完全不做心跳虽然客户端定期发Ping但服务端的WebSocket框架如果不自动回Pong客户端一样会判定超时。所以客户端和服务端的心跳必须同时配上两边都要支持WebSocket协议的标准Ping/Pong。5.2 如何模拟断网验证重连机制代码写好了怎么测试这里给大家几种我认为比较实用的断网模拟方式。第一种直接杀服务端进程。在测试服务器上启动服务端然后kill -9杀掉进程。这是最暴力的方式能立刻看到客户端日志里出现onClose然后开始指数退避重连。等服务端重新启动后客户端应该在几十秒内自动恢复连接。这个场景能覆盖服务端重启导致的断线。第二种用防火墙丢包而不是拒包。在Linux测试机上执行iptables -A INPUT -p tcp --dport 8080 -j DROP注意我用的是DROP而非REJECT。REJECT会让TCP层立刻收到RST包并报错而DROP是直接把包丢弃客户端不会立刻感知需要依靠心跳超时判断连接已死。这个场景恰好能模拟NAT超时导致的假死。清除规则时执行iptables -D INPUT -p tcp --dport 8080 -j DROP第三种在客户端代码里手动调用internalClient.close()来模拟连接被服务端主动断开。这种方式最简单但只能测到重连流程测不到心跳超时分支。我建议至少把第一种和第二种场景都测一遍尤其是第二种心跳超时判定的逻辑只有在这种场景下才会被完整走一遍。5.3 参数调优速查表最后给一个参数速查表方便不同场景下直接参考调整参数推荐值说明心跳间隔30秒小于常见NAT超时时间2分钟即可心跳超时阈值60秒至少为心跳间隔的2倍留出网络延迟余量初始重连延迟1秒建议不要小于1秒避免频繁触发最大重连延迟60秒过高会让恢复变慢过低会打爆服务端最大连续重连次数10次超过后转为5分钟一次的慢速重试随机抖动范围0~500毫秒缓解惊群效应这个表只是一个基准实际要根据你的服务端负载和客户端数量做微调。如果客户端数量上千抖动范围建议拉到1秒左右错峰效果更好如果是内网可靠环境心跳间隔甚至可以调到60秒减少无效包。写在最后这套断线重连框架我在实际项目里已经稳定跑过很久。它的设计并不复杂核心的心跳、退避重连、消息补偿这三点也就是那几十行代码的事。但真正让它稳定的是那些多考虑一步的细节重连只在onClose触发、旧连接要清理、心跳调度器要停干净、manuallyClosed标志位要置位。踩过这些坑之后你会深刻理解重连机制不是在连接断了之后才工作而是在连接建立的那一刻就开始了它的使命。最后再分享一个小建议刚开始做断线重连时不要追求一步到位先把心跳和基础重连跑通加上日志观察几天再逐步加入消息补偿和幂等处理。稳扎稳打比一次写出一套复杂系统要靠谱得多。
做实时推送、在线IM、行情订阅这类系统只要网络一波动WebSocket连接就可能悄悄断掉而你的代码如果不做处理用户那边就永远卡在一个连接已断开的假死状态。这算是Java后端做WebSocket最常踩的坑之一客户端没有心跳、没有重连、没有消息补偿断线之后一切都停摆了。这篇文章我想围绕java-websocket断线重连这个主题把一套能直接落地的完整方案拆开讲透从为什么断、怎么检测到用什么策略重连、断线消息怎么补发全部用Java代码体现适合正在做实时通信功能、或者想在项目里接入WebSocket但对稳定性心里没底的开发者参考。我早期做某个实时行情推送项目时服务端每天晚上都会自动发版重启客户端连接瞬间全断。当时客户端逻辑很简单打开连接、收数据、断开就提示网络异常然后用户得手动刷新页面。这个体验有多糟糕用过的人都知道。后来我把断线重连做进客户端才彻底告别了那种一断就死的状态。下面就把这套方案的经验和代码整理出来希望能帮你少走点弯路。1. 为什么WebSocket连接说断就断先搞清楚病根不先把断线原因摸清楚后面的重连机制做得再花哨也是瞎忙活。WebSocket连接不是一根埋在地下的水管埋好就永远不漏。它是一条基于TCP的持久连接TCP层一旦出问题上层协议一点办法都没有。我把日常工作中最常见的断线原因分成两类一类是网络环境的隐形杀手一类是服务端和客户端自己的人为事故。1.1 网络环境的隐形杀手第一类就是NAT超时。在公司上网、或者用手机流量访问服务器时中间基本都会经过一层NAT设备路由器、运营商网关。NAT设备为了节省资源会在映射表里给每条连接设置一个超时时间正常情况下可能几分钟到几十分钟不等常见的有2分钟、4分钟、5分钟。如果这条TCP连接在这段时间内没有任何数据往来NAT设备就会静默地把这条映射记录删掉。结果就是客户端以为连接还活着服务端也以为连接还活着实际上中间的链路已经断了。后续任何数据包都发不过去而客户端只有在真正尝试发送时才会感知到异常。第二类是代理和网关的空闲超时。如果你在WebSocket前面挂了Nginx、HAProxy这类反向代理它们默认会对空闲连接做回收处理比如Nginx的proxy_read_timeout默认值是60秒意味着60秒内如果没有从上游读到数据连接就会被主动关闭。很多WebSocket服务端的默认心跳间隔又恰好超过这个值那就必然会出现莫名其妙掉线的问题。第三类是网络切换。手机从WiFi切到4G/5G、或者从4G切到5GIP地址和TCP连接都会失效。这类断线是瞬时的客户端根本来不及知道只有在下次心跳或者发送数据时才会发现连接已经废了。1.2 服务端与客户端的主动断连服务端主动断开最常见的就是发版、重启。服务进程一停所有连接立刻被操作系统回收。线上发布如果没做过优雅停机前端大概率会看到一大批1006异常码。还有一种情况是服务端自己做了空闲踢人比如某些IM系统规定超过一定时间没有活动的连接直接关闭这也是合理的资源保护策略。客户端这边的主动断连就更多了最常见的是程序出错、内存溢出导致崩溃或者客户端进程被系统回收。还有一种容易被忽略的场景客户端App进入后台后系统把网络权限收走了连接虽然没有触发onClose但实际上已经不可用这时候如果唤醒回前台必须先做一次连接活性检测。1.3 状态码隐含的信息排查断线原因时WebSocket的关闭状态码是很重要的线索。我整理了一份常见状态码和对应的处理建议你可以直接参考。状态码含义常见场景是否需要重连1000正常关闭两端协商后主动关闭视业务情况不要无脑重连1001服务端正在重启服务端发版、停机维护需要且要配合等待期1002协议错误数据格式不符合规范检查代码不建议立即重连1006异常关闭网络中断、TCP连接被重置必须重连1011服务端内部错误服务端程序异常需要但要注意频率看到1006这种异常关闭码基本不用多想直接进重连流程。而如果是1000这种正常关闭很可能是用户主动退出或者服务端主动踢人这时候要么不重连要么延迟一段时间再连否则会给服务端造成压力。这个区分必须要在重连逻辑里做不能把所有关闭都当成故障处理。2. 方案选型Java生态里的WebSocket客户端到底怎么选明确了断线原因之后接下来要解决用什么来做。Java生态里做WebSocket客户端常见的方案就那么几个原生API、Java-WebSocket库、Spring WebSocket、Netty、OkHttp。很多人一开始会纠结其实只要搞清楚自己的场景选择并不难。2.1 三套主流方案横向对比我列一张对比表把最常见的选择放在一起看维度Java-WebSocket库Spring WebSocketNetty原生JDK API封装程度高回调清晰高但偏服务端低需自己封装低几乎没有封装学习成本低API简单中需理解Spring抽象高需理解异步模型中重连支持无内置需自己写无内置需自己写无内置需自己写需自己写心跳支持有Ping/Pong封装需自己编帧需自己实现需自己实现适用场景独立客户端、快速集成Spring全家桶项目高并发网关、自研协议极简单的连接需求其实看这张表就很清楚了所有方案都没有现成的断线重连和心跳机制最终都要自己写。区别只是底层库帮你做了多少。Spring WebSocket虽然生态完整但它的设计重心在服务端处理起客户端连接来反而没那么顺手。Netty性能好但开发量真的大除非你在做一个自定义协议的网关否则用Netty做WebSocket客户端有点大材小用。原生JDK那个API我是不建议直接用的写起来繁琐而且对Ping/Pong支持不够友好。2.2 为什么我推荐Java-WebSocket库做底层我最终选择了Java-WebSocket这个开源库主要看中三点。第一API设计非常直观。你需要做的事就是继承WebSocketClient类然后重写四个方法onOpen、onMessage、onClose、onError。这种事件回调模型和前端写onmessage、onclose的习惯几乎一模一样学习曲线极其平缓。第二它内置了WebSocket协议层的心跳支持。WebSocketClient类直接提供了sendPing()和sendPong()方法不需要自己拼接控制帧的字节。不要小看这一步如果直接用Netty或者原生API光是控制帧的编解码就要折腾一阵子。第三它足够轻量。整个库核心代码量不大没有依赖一堆Spring上下文非常适合嵌在任何Java项目里当客户端用。而且它的事件分发在单独的IO线程里执行配合onClose做重连触发是自然顺畅的。基于这些原因后面所有示例代码我都用Java-WebSocket库来写。如果你用的是Spring Boot项目代码一样能直接整合进去没有任何冲突。3. 断线重连三大机制详细拆解一个健壮的断线重连方案绝对不只断线了再连这一个动作。我习惯把它拆成三个机制心跳检测、重连策略、消息补偿。这三者缺一不可。只有心跳没有重连策略连上又断反复横跳只有重连没有心跳连接假死时你根本不知道要重连重连成功了不处理断线期间的消息用户就会看到数据丢失。3.1 心跳检测如何确认连接是真死还是假死先说心跳。TCP协议层面其实有保活机制即TCP KeepAlive默认情况下需要两个小时才探测一次对WebSocket这种实时业务来说完全不够用。所以必须在应用层做心跳。WebSocket协议本身定义了Ping和Pong两种控制帧。Ping是客户端或服务端主动发起的心跳探测包收到Ping的一方必须回一个Pong。在Java-WebSocket里客户端可以调用sendPing()发送Ping帧并通过重写onWebsocketPong或类似回调来接收Pong帧。这个机制用来做连接活性检测是恰到好处的。具体实现思路是客户端每隔一段时间比如30秒发送一个Ping并记录上次收到Pong的时间戳。每次收到Pong就更新这个时间戳。每次发送Ping之前先检查当前时间和最后Pong时间之差。如果超过某个阈值比如60秒就认为连接已经假死主动调用client.close()关闭当前连接从而触发onClose回调进而走进重连流程。这里要给一个基准参数建议我实测下来比较稳的组合是心跳间隔30秒、超时阈值60秒。这么设置的原因是大部分NAT设备的空闲超时在2到5分钟之间30秒的间隔能保证连接在NAT超时之前就有数据经过链路不会被动删除。而60秒的超时阈值也给了服务端和网络足够的时间去处理偶发的尖峰延迟。如果网络条件本身就差阈值可以放到90秒甚至120秒但不能无限放大否则心跳就失去了意义。还有一点要特别注意心跳必须用Ping/Pong控制帧而不是发送普通业务消息。原因有两点一是业务消息需要业务层响应服务端如果不做回执你根本不知道消息是否送达二是Ping/Pong帧在协议层面就有收到必回的语义配合它来判断连接活性是标准的做法。3.2 重连策略固定间隔还是指数退避连接断开后多久重连一次新手最容易犯的错就是写一个固定间隔的重连比如每5秒重连一次。这个方案在客户端数量少的时候问题不大但客户端一多瞬时断连比如服务端重启就会引发惊群效应成千上万个客户端同时重连服务端刚起来就被重连请求打爆导致部分连接再次失败然后又触发重连形成恶性循环。正确的做法是指数退避 随机抖动。核心思路是第一次重连等待1秒第二次2秒第三次4秒第四次8秒……计算方式是指数递增到某个上限后封顶比如60秒并且在每次计算出的延迟基础上加一个0到500毫秒之间的随机数。随机抖动的目的就是让所有客户端的重连请求错开避免扎堆。指数退避为什么靠谱因为连续重连失败往往意味着服务端或者网络出了大问题短时间内反复重连只会加剧问题。指数退避天然惩罚了连续失败的情况给服务端留出恢复时间。那要不要设置最大重连次数我的建议是保留一个最大次数比如连续重连10次之后仍然失败就不要再继续高频重连了改成长时间间隔的慢速重试比如每5分钟一次同时抛出一个告警事件让上层逻辑感知到客户端已处于离线状态。这里的关键是不能无限重试把服务端压垮也不能一次失败就彻底放弃。保持底线机制然后交给业务层决定是提示用户还是继续等待。3.3 消息补偿断线期间的消息怎么不丢心跳和重连解决了连接恢复的问题但连接断开的那段时间里用户端正常应该收到的消息以及用户端想发出去的消息该怎么办。这是很多自研WebSocket方案容易忽略的部分。消息补偿有两条链路一条是客户端发给服务端的消息另一条是服务端推给客户端的消息。先看客户端发消息这条链路。如果客户端发现连接已断开此时调用send()大概率会失败或者消息被静默丢弃。我的做法是设计一个消息队列发送消息时先判断连接是否打开如果打开就直接发如果没打开就先把消息放进队列。等重连成功后再统一把队列里的消息补发出去。这里面有个关键点——消息一定要有全局唯一的幂等标识。比如给每条消息生成一个UUID作为messageId服务端拿到这个消息后先查重如果处理过就直接返回ACK不再重复处理。这样即使重发多次也不会造成重复数据。再看服务端推送消息这条链路。重连成功后客户端要主动向服务端发起一次状态同步或增量拉取。比如记录一下断开前收到的最后一条消息的序号lastSeq重连成功后发送一个sync请求带上这个序号服务端把后续消息补推过来。这个方案的前提是服务端有消息持久化和按序发送的能力但对于IM、行情这类系统这本来就是应该有的。4. 完整实战从零打造一个可用的断线重连客户端理论知识讲完了下面进入动手环节。我会给你一套能直接复制到项目里用的代码框架包含依赖配置、核心客户端类、心跳管理器、重连策略以及Spring Boot的整合示例。代码不是我随手写的是我在项目里反复验证过、去掉业务细节后的通用骨架。4.1 项目依赖与工程结构先用Maven建一个普通的Java项目引入Java-WebSocket依赖。我这里用的是1.5.x版本也是目前比较稳定的版本。dependency groupIdorg.java-websocket/groupId artifactIdJava-WebSocket/artifactId version1.5.4/version /dependency如果你用的是Spring Boot 2.x或3.x还需要引入Spring的依赖管理这个和WebSocket本身没有直接冲突。工程结构上我建议这样组织代码分层会非常清晰com.example.ws ├── WsClient.java // 核心客户端封装对外提供连接、发送、关闭接口 ├── HeartbeatManager.java // 心跳管理器负责Ping/Pong检测 ├── ReconnectStrategy.java // 指数退避重连策略 ├── MessageQueue.java // 待补发消息队列 ├── MessageListener.java // 消息监听接口业务方实现 └── SpringWsClientConfig.java // Spring Boot 配置类核心类之间的协作关系大致是WsClient持有WebSocketClient实例HeartbeatManager在连接建立后启动、在连接关闭时停止ReconnectStrategy在onClose回调里计算下一次重连延迟MessageQueue负责存储和补发消息。4.2 核心客户端类封装连接、发送、重连触发先看最重要的WsClient。这个类把Java-WebSocket的WebSocketClient封装起来对外提供简单的connect、send、close接口。public class WsClient { private final URI serverUri; private WebSocketClient internalClient; private final HeartbeatManager heartbeatManager new HeartbeatManager(); private final ReconnectStrategy reconnectStrategy new ReconnectStrategy(); private final MessageQueue messageQueue new MessageQueue(); private final ListMessageListener listeners new CopyOnWriteArrayList(); private volatile boolean manuallyClosed false; public WsClient(URI serverUri) { this.serverUri serverUri; } public synchronized void connect() { manuallyClosed false; createInternalClient(); internalClient.connect(); System.out.println([WsClient] 发起连接: serverUri); } private void createInternalClient() { if (internalClient ! null) { try { internalClient.close(); } catch (Exception ignored) { } } internalClient new WebSocketClient(serverUri) { Override public void onOpen(ServerHandshake handshakeData) { System.out.println([WsClient] 连接已建立); reconnectStrategy.reset(); heartbeatManager.start(this); messageQueue.flushAll(this); } Override public void onMessage(String message) { // 业务消息在这里分发 for (MessageListener listener : listeners) { listener.onMessage(message); } } Override public void onClose(int code, String reason, boolean remote) { System.out.println([WsClient] 连接关闭 code code , reason reason); heartbeatManager.stop(); if (!manuallyClosed) { scheduleReconnect(); } } Override public void onError(Exception ex) { // 网络异常不一定立刻触发 close所以只记录日志 System.err.println([WsClient] 连接错误: ex.getMessage()); } }; // 这个参数是指定连接丢失检测的超时时间秒配合底层TCP探测 internalClient.setConnectionLostTimeout(HeartbeatManager.TIMEOUT_SECONDS); } private void scheduleReconnect() { if (manuallyClosed) { return; } long delay reconnectStrategy.nextDelay(); System.out.println([WsClient] delay ms 后进行第 reconnectStrategy.getAttempts() 次重连); Thread thread new Thread(() - { try { Thread.sleep(delay); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } if (!manuallyClosed) { connect(); } }, ws-reconnect-thread); thread.setDaemon(true); thread.start(); } public synchronized void close() { manuallyClosed true; heartbeatManager.stop(); if (internalClient ! null) { internalClient.close(); } } public boolean isOpen() { return internalClient ! null internalClient.isOpen(); } public boolean send(String message) { if (isOpen()) { internalClient.send(message); return true; } // 连接不可用先缓存到本地队列等重连成功后补发 messageQueue.add(message); return false; } public void addListener(MessageListener listener) { listeners.add(listener); } }这里有几个设计细节要特别说明。connect()方法用synchronized修饰是为了防止并发重连。回调线程和定时任务线程都有可能触发连接操作如果不加锁可能出现两个WebSocketClient实例同时创建底层连接一会通一会断非常难排查。另外每次创建新客户端之前先close掉旧的实例是为了释放旧连接的IO线程和文件描述符避免内存泄漏和连接句柄耗尽。manuallyClosed这个标志位很关键。当业务方主动调用close()时我们不希望触发自动重连所以置为true而正常连接断掉时它保持false在onClose里走进重连分支。这个标志位必须用volatile修饰因为它在多个线程之间共享。重连用的是独立线程加Thread.sleep而不是在onClose回调里直接同步connect()。原因很简单Java-WebSocket的onClose回调执行在WebSocket的IO线程里如果在这个线程里执行阻塞式的重连逻辑会把这个线程拖住影响后续其他事件的处理严重的会出现死锁。单独起一个线程配合sleep延迟既能避开这个问题又方便控制重连的时机。4.3 心跳管理器与重连策略实现再看HeartbeatManager。它的任务只有一个定期发Ping检查Pong超时必要时触发关闭。public class HeartbeatManager { public static final int INTERVAL_SECONDS 30; public static final int TIMEOUT_SECONDS 60; private ScheduledExecutorService scheduler; private volatile long lastPongTime 0; public void start(WebSocketClient client) { stop(); lastPongTime System.currentTimeMillis(); scheduler Executors.newSingleThreadScheduledExecutor(r - { Thread t new Thread(r, ws-heartbeat-thread); t.setDaemon(true); return t; }); scheduler.scheduleAtFixedRate(() - { long now System.currentTimeMillis(); // 先检查上次pong距今是否超时 if (now - lastPongTime TIMEOUT_SECONDS * 1000L) { System.err.println([心跳] 超过 TIMEOUT_SECONDS 秒未收到pong判定连接假死); client.close(); return; } // 发送Ping if (client.isOpen()) { client.sendPing(ByteBuffer.wrap(ping.getBytes(StandardCharsets.UTF_8))); } }, INTERVAL_SECONDS, INTERVAL_SECONDS, TimeUnit.SECONDS); } // 在收到pong时由WebSocket底层回调调用 public void onPong() { lastPongTime System.currentTimeMillis(); } public void stop() { if (scheduler ! null) { scheduler.shutdownNow(); scheduler null; } } }使用时要记得在WebSocketClient的回调里把onWebsocketPong事件转发到heartbeatManager.onPong()。Java-WebSocket的WebSocketClient类没有直接暴露onPong回调你得重写onWebsocketPong方法一些版本里回调签名是protected void onWebsocketPong(WebSocket conn, ByteBuffer message)。再来看ReconnectStrategy也就是指数退避加随机抖动的具体实现。public class ReconnectStrategy { private static final int BASE_DELAY_MS 1000; private static final int MAX_DELAY_MS 60_000; private static final int MAX_ATTEMPTS 10; private static final Random RANDOM new Random(); private int attempts 0; public long nextDelay() { attempts; if (attempts MAX_ATTEMPTS) { // 超过最大连续重连次数进入更慢的重试节奏 return 5 * 60_000L RANDOM.nextInt(1000); } long expDelay BASE_DELAY_MS * (1L Math.min(attempts, 10)); long capped Math.min(MAX_DELAY_MS, expDelay); return capped RANDOM.nextInt(500); } public void reset() { attempts 0; } public int getAttempts() { return attempts; } }这段代码计算出来的重连延迟大概是这样的序列1秒、2秒、4秒、8秒、16秒、32秒、60秒、60秒……加上抖动之后每个客户端的实际重连时间都不完全一致错峰效果就有了。重连成功后reset()会把attempts归零这样下次断线又从头开始快速恢复。特别提醒一点1L Math.min(attempts, 10)这里。如果attempts已经比较大不加Math.min直接移位会导致数值溢出变成负数那延迟时间就乱了。这种边界问题在写代码时很容易漏。消息队列MessageQueue很简单就是一个带锁的队列容我做了一下简化核心逻辑就是add和flushAllpublic class MessageQueue { private final QueueString queue new ConcurrentLinkedQueue(); public void add(String message) { queue.offer(message); } public void flushAll(WebSocketClient client) { String msg; while ((msg queue.poll()) ! null) { client.send(msg); } } }断线期间业务方调send()时消息被塞进队列重连成功后在onOpen里统一补发。这个设计虽然简单但配合消息ID幂等机制已经能解决大部分场景下的消息丢失问题了。4.4 接入Spring Boot管理客户端生命周期如果项目用了Spring Boot把WsClient做成单例Bean是常规操作。关键在于生命周期管理应用启动时连接应用关闭时优雅断开。Configuration public class SpringWsClientConfig { Bean(destroyMethod close) public WsClient wsClient() { WsClient client new WsClient(URI.create(ws://localhost:8080/ws)); client.addListener(message - System.out.println([业务] 收到消息: message)); client.connect(); return client; } }destroyMethod close保证了Spring容器关闭时会自动调用WsClient.close()把manuallyClosed置为true不再触发重连。如果不做这一步应用发布停机时可能还有后台线程在尝试重连造成应用关了还在往外打请求的诡异现象。还有一点Spring环境下最好不要用PostConstruct直接调用connect()因为此时WsClient实例可能还没完成依赖注入。把connect()调用放在Bean方法里是最稳妥的。5. 踩坑实录与调优参数速查代码部分讲完了我再把实际项目中遇到的几个高频问题、以及怎么验证这套重连机制的方法整理出来。这一部分是我最想说的很多坑是写代码时根本想不到的。5.1 我踩过的几个典型坑先说第一个坑重连触发写成双倍触发。我在第一版代码里做了两件事在onError里面调scheduleReconnect()又在onClose里面调scheduleReconnect()。结果是一次网络抖动触发两个重连线程然后两个线程各自创建WebSocketClient连接状态变得极其混乱。后来改成只在onClose里触发重连onError里只记录日志问题立刻消失。想明确告诉大家Java-WebSocket的onError和onClose不是互斥关系一次断线可能先触发onError再触发onClose重连逻辑放在onClose一个入口就够了。第二个坑connect()非阻塞导致判断失真。Java-WebSocket的connect()方法是非阻塞的它内部会创建一个线程去建立连接你调用connect()之后立刻检查isOpen()大概率是false。我见过有人写了个if (client.connect() client.isOpen())来判断连接是否成功这明显是错误用法。正确的做法是在onOpen回调里确认连接成功而不是在connect()返回值上做文章。第三个坑重连成功后没有重置退避计数器。结果就是程序运行时间越长重连间隔越大最后变成每5分钟才重连一次。用户早就失去耐心了。onOpen里必须调用reconnectStrategy.reset()我上面代码里也包含这行别漏。第四个坑心跳定时器没停导致叠加。如果每次重连都start()一个新的心跳调度器但旧调度器没有shutdownNow()那么到后面可能有十几个线程同时在发Ping。我在HeartbeatManager.start()的第一行就调用stop()就是为了清理之前残留的调度器。第五个坑服务端没有心跳机制。很多问题出在服务端完全不做心跳虽然客户端定期发Ping但服务端的WebSocket框架如果不自动回Pong客户端一样会判定超时。所以客户端和服务端的心跳必须同时配上两边都要支持WebSocket协议的标准Ping/Pong。5.2 如何模拟断网验证重连机制代码写好了怎么测试这里给大家几种我认为比较实用的断网模拟方式。第一种直接杀服务端进程。在测试服务器上启动服务端然后kill -9杀掉进程。这是最暴力的方式能立刻看到客户端日志里出现onClose然后开始指数退避重连。等服务端重新启动后客户端应该在几十秒内自动恢复连接。这个场景能覆盖服务端重启导致的断线。第二种用防火墙丢包而不是拒包。在Linux测试机上执行iptables -A INPUT -p tcp --dport 8080 -j DROP注意我用的是DROP而非REJECT。REJECT会让TCP层立刻收到RST包并报错而DROP是直接把包丢弃客户端不会立刻感知需要依靠心跳超时判断连接已死。这个场景恰好能模拟NAT超时导致的假死。清除规则时执行iptables -D INPUT -p tcp --dport 8080 -j DROP第三种在客户端代码里手动调用internalClient.close()来模拟连接被服务端主动断开。这种方式最简单但只能测到重连流程测不到心跳超时分支。我建议至少把第一种和第二种场景都测一遍尤其是第二种心跳超时判定的逻辑只有在这种场景下才会被完整走一遍。5.3 参数调优速查表最后给一个参数速查表方便不同场景下直接参考调整参数推荐值说明心跳间隔30秒小于常见NAT超时时间2分钟即可心跳超时阈值60秒至少为心跳间隔的2倍留出网络延迟余量初始重连延迟1秒建议不要小于1秒避免频繁触发最大重连延迟60秒过高会让恢复变慢过低会打爆服务端最大连续重连次数10次超过后转为5分钟一次的慢速重试随机抖动范围0~500毫秒缓解惊群效应这个表只是一个基准实际要根据你的服务端负载和客户端数量做微调。如果客户端数量上千抖动范围建议拉到1秒左右错峰效果更好如果是内网可靠环境心跳间隔甚至可以调到60秒减少无效包。写在最后这套断线重连框架我在实际项目里已经稳定跑过很久。它的设计并不复杂核心的心跳、退避重连、消息补偿这三点也就是那几十行代码的事。但真正让它稳定的是那些多考虑一步的细节重连只在onClose触发、旧连接要清理、心跳调度器要停干净、manuallyClosed标志位要置位。踩过这些坑之后你会深刻理解重连机制不是在连接断了之后才工作而是在连接建立的那一刻就开始了它的使命。最后再分享一个小建议刚开始做断线重连时不要追求一步到位先把心跳和基础重连跑通加上日志观察几天再逐步加入消息补偿和幂等处理。稳扎稳打比一次写出一套复杂系统要靠谱得多。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
