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