簡(jiǎn)介一套基于 Tomcat8、Java7 與 ExtJS 搭建的 WebSocket 實(shí)時(shí)聊天室完整源碼面向已具備 Java Web 基礎(chǔ)、希望打通服務(wù)端推送與富客戶(hù)端界面聯(lián)動(dòng)的開(kāi)發(fā)者。服務(wù)端依托 Tomcat8 容器與 JSR 356 提供的 javax.websocket 端點(diǎn)通過(guò) ServerEndpoint 生命周期回調(diào)、連接池管理與消息廣播完成收發(fā)前端用 ExtJS 組件搭建輸入框、消息列表與聊天窗口可作為實(shí)時(shí)通信從入門(mén)到進(jìn)階的實(shí)踐樣本。壓縮包共 1753 個(gè)文件、約 7.01MB其中大量 gif 與 png 為框架圖標(biāo)及主題素材scss 與 css 對(duì)應(yīng)皮膚樣式j(luò)s 承載前端邏輯與組件定義另有少量 java、class、jar 及 xml 構(gòu)成服務(wù)端代碼與工程配置。已有 263 人學(xué)習(xí)下載。讀者可據(jù)此理清握手連接、消息編解碼、在線(xiàn)用戶(hù)管理與歷史消息展示的完整鏈路并參考其中的部署調(diào)試思路。1. 從一個(gè)內(nèi)網(wǎng)協(xié)作需求說(shuō)起Tomcat8 Java7 ExtJS 的聊天室為什么還要手寫(xiě) WebSocket某內(nèi)網(wǎng)協(xié)作工具的前端是 ExtJS 管理臺(tái)后端只有 Tomcat8 和 Java7需求是在不改動(dòng)現(xiàn)有部署結(jié)構(gòu)的前提下加一個(gè)聊天室群聊、私聊、在線(xiàn)列表、斷線(xiàn)重連。很多同學(xué)第一反應(yīng)是上 Spring Boot 或 Node但現(xiàn)場(chǎng)環(huán)境不允許加新運(yùn)行時(shí)于是把目光放回 Tomcat8 自帶的 JSR-356 WebSocket。這套源碼和工具清單圍繞一個(gè)最小閉環(huán)展開(kāi)服務(wù)端用ServerEndpoint管連接前端用 ExtJS 封裝適配器消息走 JSON 協(xié)議最后用檢查表驗(yàn)收。適合正在做聊天室畢設(shè)或課設(shè)的人也適合要在老管理臺(tái)里嵌實(shí)時(shí)消息的開(kāi)發(fā)者。2. 總體架構(gòu)與技術(shù)選型連接層、路由層、視圖層的職責(zé)邊界2.1 選型對(duì)比輪詢(xún)、長(zhǎng)輪詢(xún)與 JSR-356 原生 WebSocket聊天室最核心的動(dòng)作是“服務(wù)端有新消息時(shí)瀏覽器能立刻知道”。用傳統(tǒng)輪詢(xún)前端每隔幾秒發(fā)一次請(qǐng)求消息延遲取決于輪詢(xún)間隔連接數(shù)一多Tomcat 的線(xiàn)程池會(huì)被大量空請(qǐng)求占住長(zhǎng)輪詢(xún)稍好一點(diǎn)但每次消息推送都要重新建立一次 HTTP 請(qǐng)求服務(wù)端和前端都要維護(hù)掛起狀態(tài)代碼復(fù)雜度并不低。SSE 是單向推送做在線(xiàn)列表廣播夠用但私聊和“正在輸入”這類(lèi)客戶(hù)端到服務(wù)端的事件還得另開(kāi)接口協(xié)議會(huì)變成兩套。Tomcat8 實(shí)現(xiàn)了 JSR-356也就是 Java API for WebSocket服務(wù)端用注解聲明端點(diǎn)容器負(fù)責(zé)握手和幀解析。對(duì)這套項(xiàng)目來(lái)說(shuō)選它的理由很直接不新增運(yùn)行時(shí)不引入額外容器Java7 能編譯ExtJS 前端用瀏覽器原生WebSocket對(duì)象就能對(duì)接。代價(jià)是 JSR-356 只提供連接和消息收發(fā)會(huì)話(huà)表、消息路由、心跳、重連都要自己寫(xiě)。這恰好是方案里最值得展開(kāi)的部分也是課程設(shè)計(jì)能講出設(shè)計(jì)含量的地方。方式實(shí)時(shí)性服務(wù)端資源占用前端改造量適用場(chǎng)景短輪詢(xún)秒級(jí)延遲空請(qǐng)求多小消息頻率極低長(zhǎng)輪詢(xún)準(zhǔn)實(shí)時(shí)掛起連接多中兼容舊瀏覽器SSE單向?qū)崟r(shí)連接常駐中通知、廣播WebSocket雙向?qū)崟r(shí)連接常駐但幀開(kāi)銷(xiāo)小中聊天室、協(xié)作提示選型表不要只寫(xiě)“WebSocket 更好”要把“為什么當(dāng)前環(huán)境不能選別的”寫(xiě)清楚答辯時(shí)老師通常會(huì)追問(wèn)這一句。2.2 三層架構(gòu)接入層、會(huì)話(huà)路由層、ExtJS 視圖層這套聊天室按三層劃分。接入層由 Tomcat8 的 WebSocket 容器承擔(dān)負(fù)責(zé) HTTP Upgrade 握手、幀的編解碼、連接超時(shí)控制會(huì)話(huà)路由層是 Java 代碼里的 Endpoint、SessionRegistry 和 MessageRouter負(fù)責(zé)“誰(shuí)在線(xiàn)”“消息發(fā)給誰(shuí)”“發(fā)不出去怎么清理”視圖層是 ExtJS 的聊天面板、在線(xiàn)用戶(hù)表格和輸入框負(fù)責(zé)把用戶(hù)操作變成 JSON 幀把收到的 JSON 幀變成 Store 里的記錄。三層之間只靠 JSON 消息協(xié)議耦合前端不關(guān)心服務(wù)端用的是ConcurrentHashMap還是別的會(huì)話(huà)容器服務(wù)端也不關(guān)心 ExtJS 用的是 Grid 還是 DataView。這樣做的好處是后面要把在線(xiàn)列表從表格換成樹(shù)、要把消息存儲(chǔ)從內(nèi)存換成表改動(dòng)都收在一層里。課程設(shè)計(jì)里常犯的錯(cuò)是把廣播邏輯寫(xiě)進(jìn)前端讓每個(gè)客戶(hù)端收到消息后再轉(zhuǎn)發(fā)給別人結(jié)果一端掉線(xiàn)整條鏈路就斷這種設(shè)計(jì)在答辯時(shí)很容易被問(wèn)住。數(shù)據(jù)流可以按一條群聊消息走一遍用戶(hù)在 ExtJS 輸入框點(diǎn)發(fā)送適配器把{type:chat, to:all, content:...}轉(zhuǎn)成字符串通過(guò)WebSocket.send()發(fā)到/chat/{userId}服務(wù)端OnMessage收到后解析 type交給 MessageRouterRouter 從 SessionRegistry 取出所有在線(xiàn) Session逐個(gè)調(diào)用發(fā)送方法每個(gè)前端收到后把消息 add 到消息 Store聊天面板只渲染新增行。整條鏈路里沒(méi)有輪詢(xún)也沒(méi)有額外 HTTP 接口。2.3 四個(gè)核心模塊與目錄劃分把代碼按職責(zé)拆成四個(gè)模塊后面排查問(wèn)題時(shí)能快速定位。連接管理模塊負(fù)責(zé)ServerEndpoint的生命周期方法和 Session 注冊(cè)注銷(xiāo)消息路由模塊負(fù)責(zé)協(xié)議解析、群聊廣播、私聊定向發(fā)送在線(xiàn)狀態(tài)模塊負(fù)責(zé)用戶(hù)列表和最后活躍時(shí)間前端適配模塊負(fù)責(zé) ExtJS 的 WebSocket 封裝、重連和 Store 聯(lián)動(dòng)。目錄不必照搬某個(gè)框架但要讓別人一眼看出哪塊歸哪塊。webapp/ chat/ app/ view/ # ChatPanel、OnlineGrid、MessageList store/ # OnlineUsers、Messages ux/ # WebSocketAdapter controller/ # ChatController app.js src/ main/ java/ com/example/chat/ ws/ # ChatEndpoint、ChatConfigurator service/ # SessionRegistry、MessageRouter model/ # ChatMessage、UserSession上面這份目錄把“連接”和“路由”分開(kāi)放ws包只處理 WebSocket 協(xié)議層的事情service包不依賴(lài)javax.websocket之外的容器類(lèi)。實(shí)際交付時(shí)如果項(xiàng)目是傳統(tǒng) Web 工程而不是 Maven 結(jié)構(gòu)把src換成src/main/java對(duì)應(yīng)的源碼目錄即可包名保持一致后面貼的代碼不用改。2.4 連接生命周期與數(shù)據(jù)流JSR-356 的端點(diǎn)有四個(gè)生命周期回調(diào)OnOpen在握手成功后觸發(fā)OnMessage在收到文本或二進(jìn)制幀時(shí)觸發(fā)OnClose在連接關(guān)閉時(shí)觸發(fā)OnError在連接或發(fā)送出錯(cuò)時(shí)觸發(fā)。聊天室的會(huì)話(huà)表就在OnOpen里寫(xiě)入在OnClose和OnError里刪除。這里有一個(gè)容易被忽略的點(diǎn)OnClose不保證一定執(zhí)行比如進(jìn)程被 kill、網(wǎng)絡(luò)中途斷開(kāi)、容器強(qiáng)制回收所以發(fā)送消息時(shí)還要做一次session.isOpen()判斷和失敗清理不能只依賴(lài)關(guān)閉回調(diào)。連接建立后前端適配器會(huì)先發(fā)一條join消息服務(wù)端回一條online消息帶當(dāng)前在線(xiàn)列表之后每 25 秒發(fā)一次ping服務(wù)端回pong同時(shí)刷新該用戶(hù)的最后活躍時(shí)間。超過(guò) 60 秒沒(méi)有收到任何幀Tomcat 會(huì)按setMaxIdleTimeout關(guān)閉連接前端收到onclose后進(jìn)入重連流程。這個(gè)“心跳 空閑超時(shí) 前端重連”的組合是后面驗(yàn)收時(shí)最能體現(xiàn)設(shè)計(jì)完整性的部分。3. 服務(wù)端落地會(huì)話(huà)表、消息協(xié)議與心跳清理的 Java7 寫(xiě)法3.1 ServerEndpoint 的生命周期方法與參數(shù)獲取服務(wù)端端點(diǎn)用注解聲明路徑把用戶(hù)標(biāo)識(shí)放在路徑參數(shù)里前端連接時(shí)拼上去。這樣不用在握手階段解析 query stringPathParam在OnOpen和OnMessage里都能直接拿到。Java7 沒(méi)有 lambda集合初始化用傳統(tǒng)寫(xiě)法代碼看起來(lái)啰嗦一點(diǎn)但和 Tomcat8 的 JSR-356 實(shí)現(xiàn)完全兼容。ServerEndpoint(value /chat/{userId}, configurator ChatConfigurator.class) public class ChatEndpoint { private static final ConcurrentHashMapString, Session ONLINE new ConcurrentHashMapString, Session(); private static final ConcurrentHashMapString, Long LAST_ACTIVE new ConcurrentHashMapString, Long(); OnOpen public void onOpen(Session session, PathParam(userId) String userId) { // 空閑超時(shí)設(shè)成 60 秒前端 25 秒發(fā)一次心跳留出重試余量 session.setMaxIdleTimeout(60000L); ONLINE.put(userId, session); LAST_ACTIVE.put(userId, Long.valueOf(System.currentTimeMillis())); // 把當(dāng)前在線(xiàn)用戶(hù)推給新連接格式由 MessageRouter 統(tǒng)一封裝 MessageRouter.sendOnlineList(session, ONLINE.keySet()); } OnMessage public void onMessage(String text, Session session, PathParam(userId) String userId) { LAST_ACTIVE.put(userId, Long.valueOf(System.currentTimeMillis())); ChatMessage msg ChatMessage.parse(text); if (msg null) { MessageRouter.sendError(session, BAD_MESSAGE); return; } MessageRouter.route(userId, msg); } OnClose public void onClose(Session session) { String userId session.getPathParameters().get(userId); if (userId ! null) { ONLINE.remove(userId, session); LAST_ACTIVE.remove(userId); MessageRouter.broadcastOnlineList(ONLINE.keySet()); } } OnError public void onError(Session session, Throwable error) { String userId session.getPathParameters().get(userId); if (userId ! null) { ONLINE.remove(userId, session); LAST_ACTIVE.remove(userId); } // 這里只記日志不再向已出錯(cuò)的連接寫(xiě)消息 LoggerFactory.getLogger(ChatEndpoint.class).error(ws error, user userId, error); } }這段代碼里ONLINE.remove(userId, session)用了雙參數(shù)刪除只有當(dāng)前 Session 和表里的一致才刪避免用戶(hù)重連后舊連接的OnClose把新連接誤刪。setMaxIdleTimeout(60000L)的單位是毫秒前端心跳間隔要小于它否則連接會(huì)被容器提前關(guān)掉。ChatConfigurator用來(lái)在握手前做 Origin 校驗(yàn)或注入依賴(lài)如果沒(méi)有額外配置可以去掉 configurator 屬性不影響主流程。3.2 會(huì)話(huà)表設(shè)計(jì)ConcurrentHashMap 與用戶(hù)維度索引會(huì)話(huà)表用ConcurrentHashMapString, Sessionkey 是用戶(hù) IDvalue 是當(dāng)前連接。聊天室場(chǎng)景讀多寫(xiě)少?gòu)V播時(shí)要遍歷所有 SessionConcurrentHashMap的弱一致性迭代器允許遍歷時(shí)發(fā)生刪除不會(huì)拋ConcurrentModificationException。如果要支持同一賬號(hào)多端登錄value 要換成SetSession或CopyOnWriteArrayListSessionkey 仍然用用戶(hù) ID發(fā)送時(shí)對(duì)該用戶(hù)的所有連接逐個(gè)寫(xiě)。在線(xiàn)狀態(tài)還需要一張“最后活躍時(shí)間”表用來(lái)做兜底清理。Tomcat 的空閑超時(shí)會(huì)關(guān)閉連接但某些網(wǎng)絡(luò)環(huán)境下關(guān)閉事件可能延遲定時(shí)任務(wù)每 30 秒掃一遍L(zhǎng)AST_ACTIVE超過(guò) 90 秒沒(méi)有更新的用戶(hù)直接從ONLINE里移除并廣播在線(xiàn)列表。這個(gè)定時(shí)任務(wù)用ScheduledExecutorService起單線(xiàn)程就夠不要每個(gè)連接起一個(gè)線(xiàn)程否則連接數(shù)一多線(xiàn)程數(shù)會(huì)失控。public final class SessionRegistry { private static final ScheduledExecutorService CLEANER Executors.newSingleThreadScheduledExecutor(); static { CLEANER.scheduleAtFixedRate(new Runnable() { public void run() { long now System.currentTimeMillis(); for (Map.EntryString, Long entry : ChatEndpoint.LAST_ACTIVE.entrySet()) { if (now - entry.getValue().longValue() 90000L) { Session session ChatEndpoint.ONLINE.remove(entry.getKey()); ChatEndpoint.LAST_ACTIVE.remove(entry.getKey()); closeQuietly(session); } } } }, 30L, 30L, TimeUnit.SECONDS); } private static void closeQuietly(Session session) { if (session ! null session.isOpen()) { try { session.close(new CloseReason( CloseReason.CloseCodes.GOING_AWAY, idle timeout)); } catch (IOException ignored) { // 關(guān)閉失敗不再重試Map 已經(jīng)移除連接會(huì)被容器回收 } } } }這段清理邏輯的關(guān)鍵參數(shù)是 90 秒閾值它要比setMaxIdleTimeout的 60 秒大給容器留出關(guān)閉和回調(diào)的時(shí)間。closeQuietly里捕獲IOException后不再重試因?yàn)闀?huì)話(huà)已經(jīng)從表里移除重試沒(méi)有意義反而可能把異常日志刷滿(mǎn)。定時(shí)任務(wù)用靜態(tài)塊啟動(dòng)項(xiàng)目里如果有 Spring 容器可以改成PostConstruct初始化但不要在每次連接時(shí)新建線(xiàn)程池。3.3 消息協(xié)議與路由群聊、私聊、系統(tǒng)消息消息協(xié)議用 JSON字段不多但要在前端和服務(wù)端保持一致。type區(qū)分消息類(lèi)型from由服務(wù)端根據(jù)路徑參數(shù)填to對(duì)群聊填all對(duì)私聊填目標(biāo)用戶(hù) IDcontent是文本內(nèi)容ts是服務(wù)端時(shí)間戳。服務(wù)端解析后不信任前端傳來(lái)的from統(tǒng)一用路徑參數(shù)覆蓋避免冒充。協(xié)議表如下字段類(lèi)型說(shuō)明typestringchat、private、system、ping、pong、onlinefromstring服務(wù)端填充的發(fā)送者 IDtostringall 或目標(biāo)用戶(hù) IDcontentstring文本內(nèi)容system 消息為提示文案tslong服務(wù)端毫秒時(shí)間戳usersarray僅 online 消息攜帶在線(xiàn)用戶(hù) ID 列表路由方法收到chat時(shí)遍歷ONLINE廣播收到private時(shí)只發(fā)給to對(duì)應(yīng)的 Session收到ping時(shí)回pong。廣播時(shí)不要在主線(xiàn)程里同步寫(xiě)所有連接某個(gè)客戶(hù)端網(wǎng)絡(luò)慢會(huì)拖住整個(gè)廣播可以把每個(gè)發(fā)送包成一個(gè)任務(wù)丟給線(xiàn)程池但線(xiàn)程池要有界隊(duì)列滿(mǎn)了就丟棄并記日志避免消息堆積把內(nèi)存撐爆。課程設(shè)計(jì)規(guī)模小直接同步寫(xiě)也可以但要在代碼注釋里寫(xiě)清楚這是簡(jiǎn)化處理答辯時(shí)能說(shuō)明取舍。public static void route(String from, ChatMessage msg) { if (ping.equals(msg.getType())) { sendText(ONLINE.get(from), {\type\:\pong\,\ts\: System.currentTimeMillis() }); return; } if (chat.equals(msg.getType())) { msg.setFrom(from); msg.setTs(System.currentTimeMillis()); String json msg.toJson(); for (Session session : ONLINE.values()) { sendText(session, json); } return; } if (private.equals(msg.getType())) { msg.setFrom(from); msg.setTs(System.currentTimeMillis()); Session target ONLINE.get(msg.getTo()); if (target null) { sendError(ONLINE.get(from), USER_OFFLINE); return; } sendText(target, msg.toJson()); sendText(ONLINE.get(from), msg.toJson()); } }route里對(duì)私聊做了“發(fā)給目標(biāo)并回顯給發(fā)送者”的處理前端不用自己往消息列表里補(bǔ)一條所有消息都以服務(wù)端回執(zhí)為準(zhǔn)這樣多端登錄時(shí)消息順序一致。sendText內(nèi)部要做空判斷和isOpen判斷發(fā)送失敗時(shí)從ONLINE移除對(duì)應(yīng)會(huì)話(huà)避免壞連接一直留在表里。3.4 心跳、空閑超時(shí)與失效會(huì)話(huà)清理心跳不是業(yè)務(wù)消息但它是聊天室能不能長(zhǎng)期掛住的關(guān)鍵。前端每 25 秒發(fā)一次ping服務(wù)端在OnMessage里刷新LAST_ACTIVE并回pong。如果前端連續(xù)三次沒(méi)有收到pong就主動(dòng)關(guān)閉連接并進(jìn)入重連。服務(wù)端這邊setMaxIdleTimeout(60000L)是容器級(jí)兜底定時(shí)清理是應(yīng)用級(jí)兜底兩層機(jī)制同時(shí)存在任何一層失效另一層還能收住。發(fā)送方法要加鎖原因是 JSR-356 的RemoteEndpoint.Basic不保證線(xiàn)程安全多個(gè)業(yè)務(wù)線(xiàn)程同時(shí)往同一個(gè) Session 寫(xiě)可能出現(xiàn)IllegalStateException或消息截?cái)唷Ｓ胹ynchronized (session)包住sendText是最簡(jiǎn)單的做法連接數(shù)不大時(shí)開(kāi)銷(xiāo)可以接受。如果追求吞吐可以改用getAsyncRemote()加發(fā)送隊(duì)列但異步發(fā)送的回調(diào)里不能再同步寫(xiě)同一個(gè) Session否則會(huì)死鎖。這部分在下一章的避坑里還會(huì)展開(kāi)。public static void sendText(Session session, String text) { if (session null || !session.isOpen()) { return; } synchronized (session) { try { session.getBasicRemote().sendText(text); } catch (IOException e) { // 寫(xiě)失敗說(shuō)明連接已經(jīng)不可用直接從在線(xiàn)表移除 String userId session.getPathParameters().get(userId); if (userId ! null) { ONLINE.remove(userId, session); } } } }sendText是整套服務(wù)端代碼里被調(diào)用次數(shù)最多的方法廣播、私聊、系統(tǒng)提示都走它。把空判斷、鎖、失敗清理收在一個(gè)方法里路由層就不用重復(fù)寫(xiě)這些邊界處理。注意session.getPathParameters()在OnClose之后調(diào)用可能返回空 Map所以移除時(shí)先判斷userId是否為 null避免ConcurrentHashMap的 key 為 null 拋異常。4. 前端落地ExtJS 組件樹(shù)與 WebSocket 適配器的對(duì)接方式4.1 ExtJS 視圖結(jié)構(gòu)Viewport、聊天面板、在線(xiàn)列表、輸入?yún)^(qū)前端用 ExtJS 的 Viewport 做整體布局左側(cè)是在線(xiàn)用戶(hù) Grid右側(cè)是消息列表加輸入?yún)^(qū)。消息列表可以用Ext.view.View配itemTpl也可以用 Grid 配列前者渲染輕、適合消息流后者方便做“按用戶(hù)篩選”。在線(xiàn)列表用 GridStore 的字段是userId、name、status收到online消息時(shí)整表替換收到用戶(hù)上下線(xiàn)時(shí)增量 add/remove。輸入?yún)^(qū)用Ext.form.Panel回車(chē)發(fā)送發(fā)送按鈕在請(qǐng)求發(fā)出后置灰收到服務(wù)端回顯再恢復(fù)。組件樹(shù)不要建得太深聊天面板里套太多panel會(huì)讓布局計(jì)算變慢消息一多就能感覺(jué)到卡頓。消息列表用flex: 1撐滿(mǎn)剩余高度輸入?yún)^(qū)固定高度在線(xiàn)列表給一個(gè)最小寬度。所有需要隨窗口變化的地方用layout: border或layout: fit不要用絕對(duì)定位否則分辨率一變就錯(cuò)位。4.2 WebSocket 適配器連接、重連、事件總線(xiàn)ExtJS 沒(méi)有內(nèi)置 WebSocket 類(lèi)需要自己封一個(gè)Ext.util.Observable子類(lèi)把onopen、onmessage、onclose、onerror轉(zhuǎn)成 ExtJS 事件。適配器負(fù)責(zé)拼 URL、發(fā)消息、心跳、重連業(yè)務(wù)控制器只監(jiān)聽(tīng)message和open事件。這樣控制器里不出現(xiàn)原生WebSocketAPI后面換傳輸方式也不用改業(yè)務(wù)代碼。Ext.define(Chat.ux.WebSocketAdapter, { extend: Ext.util.Observable, config: { url: null, userId: null }, constructor: function (config) { this.initConfig(config); this.callParent(arguments); this.reconnectDelay 1000; this.maxDelay 30000; this.manualClose false; this.heartbeatTimer null; this.connect(); }, connect: function () { var me this; me.socket new WebSocket(me.getUrl() / encodeURIComponent(me.getUserId())); me.socket.onopen function () { me.reconnectDelay 1000; me.startHeartbeat(); me.fireEvent(open); }; me.socket.onmessage function (event) { var msg Ext.JSON.decode(event.data, true); if (msg) { me.fireEvent(message, msg); } }; me.socket.onclose function () { me.stopHeartbeat(); me.fireEvent(close); if (!me.manualClose) { me.scheduleReconnect(); } }; me.socket.onerror function () { me.fireEvent(error); }; }, startHeartbeat: function () { var me this; me.stopHeartbeat(); me.heartbeatTimer setInterval(function () { me.send({ type: ping, ts: new Date().getTime() }); }, 25000); }, stopHeartbeat: function () { if (this.heartbeatTimer) { clearInterval(this.heartbeatTimer); this.heartbeatTimer null; } }, scheduleReconnect: function () { var me this; setTimeout(function () { me.connect(); }, me.reconnectDelay); me.reconnectDelay Math.min(me.reconnectDelay * 2, me.maxDelay); }, send: function (obj) { if (this.socket this.socket.readyState WebSocket.OPEN) { this.socket.send(Ext.JSON.encode(obj)); } }, close: function () { this.manualClose true; this.stopHeartbeat(); if (this.socket) { this.socket.close(); } } });適配器里reconnectDelay從 1 秒開(kāi)始翻倍上限 30 秒避免服務(wù)端重啟時(shí)所有客戶(hù)端在同一秒重連把連接數(shù)打滿(mǎn)。manualClose用來(lái)區(qū)分“用戶(hù)主動(dòng)關(guān)閉”和“網(wǎng)絡(luò)異常關(guān)閉”主動(dòng)關(guān)閉不觸發(fā)重連。Ext.JSON.decode(event.data, true)的第二個(gè)參數(shù)是安全模式解析失敗返回 null不會(huì)拋異常打斷事件循環(huán)。心跳定時(shí)器在onclose里必須清掉否則重連后會(huì)有多個(gè)定時(shí)器同時(shí)發(fā) ping。4.3 Store 與消息渲染避免全量重繪消息 Store 的字段包括from、content、ts、type收到chat或private消息時(shí)用store.add追加一條不要用loadData全量替換。全量替換會(huì)讓整個(gè)消息列表重新渲染消息一多就能看到明顯閃爍而且滾動(dòng)位置會(huì)丟。追加之后判斷用戶(hù)是否在底部如果在底部就滾到底如果用戶(hù)正在往上翻歷史消息就不要強(qiáng)制滾動(dòng)給一個(gè)“有新消息”的提示按鈕。在線(xiàn)用戶(hù) Store 的更新策略相反online消息到達(dá)時(shí)可以loadData全量替換因?yàn)樵诰€(xiàn)列表通常只有幾十條全量替換的代價(jià)比逐條比對(duì)小。但userOnline和userOffline這類(lèi)增量消息要用add和remove不要每次都全量拉一遍。兩個(gè) Store 的更新方式分開(kāi)是前端性能上最容易被忽略的一點(diǎn)。Ext.define(Chat.controller.ChatController, { extend: Ext.app.Controller, init: function () { var me this; me.adapter Ext.create(Chat.ux.WebSocketAdapter, { url: ws:// location.host /chat, userId: window.currentUserId }); me.adapter.on(message, me.onWsMessage, me); me.adapter.on(open, me.onWsOpen, me); }, onWsOpen: function () { this.adapter.send({ type: join }); }, onWsMessage: function (msg) { var msgStore Ext.getStore(Messages); var onlineStore Ext.getStore(OnlineUsers); if (msg.type chat || msg.type private || msg.type system) { msgStore.add({ from: msg.from, content: msg.content, ts: msg.ts, type: msg.type }); this.scrollToBottomIfNeeded(); return; } if (msg.type online) { onlineStore.loadData(msg.users || []); return; } if (msg.type userOnline) { onlineStore.add({ userId: msg.userId, status: online }); return; } if (msg.type userOffline) { onlineStore.remove(onlineStore.getById(msg.userId)); } }, scrollToBottomIfNeeded: function () { var view Ext.getCmp(messageList).getView(); var el view.getEl(); if (el el.dom.scrollHeight - el.dom.scrollTop - el.dom.clientHeight 40) { el.dom.scrollTop el.dom.scrollHeight; } } });控制器只做分發(fā)不直接操作 WebSocket 對(duì)象消息 Store 和在線(xiàn) Store 的更新邏輯分開(kāi)寫(xiě)。scrollToBottomIfNeeded里的 40 像素閾值是經(jīng)驗(yàn)值小于這個(gè)距離視為“用戶(hù)在底部”可以自動(dòng)滾動(dòng)超過(guò)這個(gè)距離說(shuō)明用戶(hù)正在看歷史消息不要打擾。Ext.getCmp在大型項(xiàng)目里不推薦但聊天室這種單頁(yè)面夠用如果控件有reference用lookupReference更穩(wěn)。4.4 前端協(xié)議對(duì)接與錯(cuò)誤提示前端發(fā)消息時(shí)不要帶from服務(wù)端會(huì)覆蓋私聊消息帶to群聊to填all。發(fā)送前做一次空內(nèi)容判斷連續(xù)回車(chē)不要發(fā)空消息。服務(wù)端返回error類(lèi)型時(shí)在輸入?yún)^(qū)上方顯示一行提示不要用alert打斷用戶(hù)。連接斷開(kāi)時(shí)把輸入框置灰重連成功后恢復(fù)用戶(hù)不需要手動(dòng)刷新頁(yè)面。錯(cuò)誤碼不要太細(xì)前端只需要區(qū)分“消息格式錯(cuò)誤”“對(duì)方不在線(xiàn)”“連接已斷開(kāi)”三類(lèi)。BAD_MESSAGE通常是前端 JSON 拼錯(cuò)開(kāi)發(fā)階段出現(xiàn)上線(xiàn)后不應(yīng)該出現(xiàn)USER_OFFLINE是正常業(yè)務(wù)分支提示“對(duì)方已離線(xiàn)”即可連接斷開(kāi)由適配器的close事件統(tǒng)一處理不需要服務(wù)端再發(fā)錯(cuò)誤消息。把這三類(lèi)分開(kāi)前端提示文案不會(huì)互相覆蓋。5. 避坑與排查握手 404、并發(fā)寫(xiě)、會(huì)話(huà)泄漏等五個(gè)高頻問(wèn)題5.1 握手 404路徑、容器依賴(lài)與打包沖突現(xiàn)象是瀏覽器控制臺(tái)報(bào)WebSocket connection to ws://... failed: Error during WebSocket handshake: Unexpected response code: 404服務(wù)端日志里看不到OnOpen。原因通常有三種前端拼的路徑和服務(wù)端ServerEndpoint的值不一致項(xiàng)目把websocket-api.jar打進(jìn)了WEB-INF/lib和 Tomcat 自帶的實(shí)現(xiàn)沖突web.xml的metadata-completetrue讓容器不掃描注解。解決時(shí)先看 Tomcat 的logs/localhost日志有沒(méi)有端點(diǎn)注冊(cè)信息再檢查WEB-INF/lib里有沒(méi)有websocket-api或tomcat-websocket的 jar有就移掉編譯期依賴(lài)用providedscope。路徑上注意前后端都帶沒(méi)帶尾斜杠/chat/{userId}和/chat/是兩回事。5.2 并發(fā)寫(xiě)異常RemoteEndpoint 的線(xiàn)程安全問(wèn)題現(xiàn)象是廣播時(shí)偶爾拋java.lang.IllegalStateException: The remote endpoint was in state [TEXT_FULL_WRITING]或者某個(gè)客戶(hù)端收到的消息少了一段。原因是多個(gè)線(xiàn)程同時(shí)調(diào)用同一個(gè) Session 的getBasicRemote().sendText()JSR-356 不保證RemoteEndpoint.Basic的線(xiàn)程安全。解決方法是給發(fā)送方法加synchronized (session)把同一個(gè) Session 的寫(xiě)操作串行化如果連接數(shù)很大改成每個(gè) Session 一個(gè)發(fā)送隊(duì)列由單線(xiàn)程消費(fèi)隊(duì)列業(yè)務(wù)線(xiàn)程只入隊(duì)。不要在被鎖住的代碼里做 JSON 序列化以外的耗時(shí)操作否則廣播會(huì)被慢客戶(hù)端拖住。5.3 會(huì)話(huà)泄漏onClose 沒(méi)觸發(fā)與 Map 只增不減現(xiàn)象是運(yùn)行一段時(shí)間后在線(xiàn)列表里出現(xiàn)已經(jīng)關(guān)掉頁(yè)面的用戶(hù)廣播時(shí)sendText一直失敗內(nèi)存緩慢上漲。原因是OnClose在網(wǎng)絡(luò)異常、容器強(qiáng)制回收、進(jìn)程被 kill 時(shí)不一定執(zhí)行而代碼只依賴(lài)OnClose刪除會(huì)話(huà)。解決方法是三層兜底發(fā)送失敗時(shí)從ONLINE移除LAST_ACTIVE超過(guò)閾值由定時(shí)任務(wù)清理OnError里也執(zhí)行移除。移除時(shí)用remove(key, value)雙參數(shù)版本防止舊連接的回調(diào)誤刪新連接。上線(xiàn)前用jmap或容器自帶的管理頁(yè)看一次 Session 數(shù)量連接關(guān)閉后數(shù)量應(yīng)該回落。5.4 重連風(fēng)暴前端退避與后端限流現(xiàn)象是服務(wù)端重啟或網(wǎng)絡(luò)抖動(dòng)后所有客戶(hù)端在同一秒重連Tomcat 的線(xiàn)程數(shù)瞬間打滿(mǎn)日志里大量握手失敗。原因是前端重連間隔固定沒(méi)有退避也沒(méi)有隨機(jī)抖動(dòng)。解決方法是在適配器里做指數(shù)退避間隔從 1 秒翻倍到 30 秒并在每次間隔上加 0 到 1 秒的隨機(jī)數(shù)把重連時(shí)間打散。服務(wù)端可以在ChatConfigurator的beforeRequest里按 IP 做簡(jiǎn)單的計(jì)數(shù)限流超過(guò)閾值直接拒絕握手。不要在前端用setInterval無(wú)限重試重試次數(shù)要有上限超過(guò)之后提示用戶(hù)手動(dòng)刷新。5.5 跨域與接入層配置Origin 校驗(yàn)與超時(shí)參數(shù)現(xiàn)象是本地開(kāi)發(fā)時(shí)前端頁(yè)面在 8080WebSocket 服務(wù)在另一個(gè)端口瀏覽器握手被拒絕或者經(jīng)過(guò)接入層轉(zhuǎn)發(fā)后Upgrade頭丟失握手變成普通 HTTP 請(qǐng)求。原因是 WebSocket 握手雖然不受同源策略的完全限制但瀏覽器會(huì)帶Origin服務(wù)端可以校驗(yàn)接入層如果沒(méi)有放行Upgrade和Connection頭握手無(wú)法完成。解決方法是在ChatConfigurator里讀取Origin只允許配置過(guò)的域名接入層配置里顯式放行Upgrade、Connection頭并把讀超時(shí)調(diào)大至少大于心跳間隔。本地開(kāi)發(fā)可以把前端和服務(wù)端配到同一個(gè)端口用相對(duì)路徑拼ws://減少跨域變量。注意接入層配置改完后先用瀏覽器開(kāi)發(fā)者工具的 Network 面板看握手響應(yīng)碼101 才是切換協(xié)議成功200 或 403 都要回頭查 Origin 和路徑。6. 驗(yàn)收與答辯一份能現(xiàn)場(chǎng)演示的檢查表和講解順序驗(yàn)收不要只看“能發(fā)消息”要按連接生命周期逐項(xiàng)過(guò)。下面這份表可以直接當(dāng)答辯演示腳本每項(xiàng)操作完看一眼瀏覽器和服務(wù)端日志通過(guò)標(biāo)準(zhǔn)寫(xiě)清楚避免現(xiàn)場(chǎng)扯皮。檢查項(xiàng)操作通過(guò)標(biāo)準(zhǔn)連接建立打開(kāi)兩個(gè)瀏覽器窗口分別登錄不同用戶(hù)服務(wù)端日志出現(xiàn)兩次onOpen在線(xiàn)列表顯示兩人群聊廣播A 發(fā)一條群聊B 觀察B 立刻收到消息順序與發(fā)送順序一致私聊定向A 選擇 B 發(fā)私聊C 觀察只有 B 和 A 收到C 不出現(xiàn)該消息在線(xiàn)列表關(guān)閉 B 的頁(yè)面A 的在線(xiàn)列表在數(shù)秒內(nèi)移除 B心跳與超時(shí)斷網(wǎng) 30 秒再恢復(fù)前端進(jìn)入重連恢復(fù)后能繼續(xù)收發(fā)會(huì)話(huà)釋放連續(xù)開(kāi)關(guān)頁(yè)面 20 次服務(wù)端ONLINE大小回落到實(shí)際在線(xiàn)數(shù)并發(fā)發(fā)送兩個(gè)用戶(hù)同時(shí)快速發(fā)消息不出現(xiàn)IllegalStateException消息不串行錯(cuò)亂答辯講解按“需求—選型—數(shù)據(jù)流—演示—排錯(cuò)”的順序走不要一上來(lái)念代碼。先用一句話(huà)說(shuō)清楚為什么不用輪詢(xún)內(nèi)網(wǎng)環(huán)境已有 Tomcat8JSR-356 不需要新增運(yùn)行時(shí)實(shí)時(shí)性更好。然后畫(huà)一條消息從 ExtJS 輸入框到對(duì)方 Store 的路徑指著代碼說(shuō)清楚OnOpen注冊(cè)、route分發(fā)、sendText加鎖這三處。演示時(shí)故意關(guān)掉一個(gè)窗口讓對(duì)方看到在線(xiàn)列表變化再故意斷網(wǎng)幾秒讓重連退避生效。老師如果問(wèn)“消息可靠嗎”不要答“可靠”答“當(dāng)前是內(nèi)存態(tài)服務(wù)端不持久化斷線(xiàn)期間的消息不補(bǔ)發(fā)這是這套方案的邊界如果要補(bǔ)發(fā)得加消息表和離線(xiàn)隊(duì)列”。把邊界說(shuō)清楚比硬撐更加分。我最早做這套聊天室時(shí)只測(cè)了兩個(gè)人正常發(fā)消息沒(méi)測(cè)“關(guān)頁(yè)面后會(huì)話(huà)有沒(méi)有刪”結(jié)果演示到一半在線(xiàn)列表里掛著一排已離線(xiàn)用戶(hù)現(xiàn)場(chǎng)很尷尬。從那以后我每次交付前都強(qiáng)制走一遍斷線(xiàn)重連和會(huì)話(huà)清理的檢查希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取