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