機飛機游戲：NIO服務器與客戶端架構設計實戰(zhàn))
簡介這是一套面向Java游戲開發(fā)初學者與網(wǎng)絡編程學習者的多人聯(lián)機飛機游戲完整源碼包含客戶端與服務器端兩部分可用于理解C/S架構下的游戲邏輯分離、通信同步與界面渲染等核心問題。資源包共25個文件約36KB以Java源文件與編譯后的class文件為主體另含classpath路徑配置、Eclipse項目配置與用戶偏好設置文件以及授權協(xié)議和說明文檔結構清晰、便于導入IDE直接閱讀調(diào)試。目前已有320人學習關注。項目將用戶界面、圖形渲染與輸入處理放在客戶端把游戲狀態(tài)管理、邏輯運算與數(shù)據(jù)同步交由服務器端讀者可借此掌握Socket通信、多線程并發(fā)、AWT/Swing界面設計等關鍵技術的落地方式并參考其模塊劃分與配置組織快速搭建自己的聯(lián)機游戲原型或課程設計框架。1. 從「能雙人同屏」到「能跨網(wǎng)聯(lián)機」JAVA 多人聯(lián)機飛機游戲到底難在哪單機版飛機大戰(zhàn)很多人一兩天就能擼出來一個JFrame一個Timer循環(huán)鍵盤監(jiān)聽控制飛機移動碰撞檢測用矩形相交完事?？梢坏祟}里加上「多人聯(lián)機」四個字難度不是加一而是乘十。你要面對的是兩臺機器上的子彈位置怎么保持一致、誰說了算、網(wǎng)絡延遲 200ms 時對方飛機瞬移怎么辦、玩家中途掉線房間怎么收場。這些才是 JAVA 多人聯(lián)機飛機游戲客戶端及服務器端設計里真正值錢的部分。這篇筆記面向的是已經(jīng)會寫 JAVA 基礎語法、能看懂Socket和線程但沒真正做過聯(lián)機游戲的開發(fā)者。我會把一套可復現(xiàn)的 C/S 架構拆開服務器端用什么模型扛連接、客戶端怎么把渲染和網(wǎng)絡解耦、協(xié)議怎么定、狀態(tài)怎么同步、掉線怎么兜底。讀完你應該能自己搭出一個 28 人同房間、局域網(wǎng)或公網(wǎng)可玩的飛機對戰(zhàn)原型并且知道哪些參數(shù)一改就翻車。熱搜里那些「客戶端和服務端區(qū)別」「java 環(huán)境配置」的問題本質都會在這套架構里被逼著回答一遍。2. 服務器端選型為什么我最終放棄阻塞 IO改用 NIO 線程池2.1 三種服務器模型的取舍BIO、NIO、Netty做飛機游戲服務器第一道坎是通信模型。最直覺的寫法是ServerSocket.accept()拿到一個連接就開一個線程這就是阻塞 IOBIO。10 個玩家以內(nèi)它跑得好好的代碼也好懂。但飛機游戲有個特點高頻小包。玩家飛機位置、子彈坐標、敵機狀態(tài)每秒要廣播 2030 次。BIO 下每個連接一個線程線程上下文切換的開銷會隨著人數(shù)線性上漲50 人就開始抖。第二種是 JAVA 原生 NIO用Selector做多路復用一個線程管一堆連接。它省線程但ByteBuffer的讀寫、半包粘包處理、SelectionKey的狀態(tài)機寫起來非常容易出玄學 bug。第三種是 Netty本質是 NIO 的封裝幫你把粘包拆包、心跳、編解碼都做好了。我的建議很明確學習目的、想搞懂底層用原生 NIO想快速出可玩版本用 Netty。下面這套代碼我用原生 NIO 寫因為標題強調(diào)「設計」你得看見Selector長什么樣。2.2 用 NIO 搭一個能收發(fā)的服務器骨架// GameServer.java —— NIO 服務器主循環(huán)骨架 public class GameServer { private Selector selector; private ServerSocketChannel serverChannel; // 每個連接對應一個 ClientSession保存玩家狀態(tài) private MapSocketChannel, ClientSession sessions new ConcurrentHashMap(); public void start(int port) throws IOException { selector Selector.open(); serverChannel ServerSocketChannel.open(); serverChannel.configureBlocking(false); // 必須非阻塞否則 Selector 失效 serverChannel.socket().bind(new InetSocketAddress(port)); serverChannel.register(selector, SelectionKey.OP_ACCEPT); System.out.println(server listening on port); while (true) { selector.select(); // 阻塞直到有事件就緒 IteratorSelectionKey it selector.selectedKeys().iterator(); while (it.hasNext()) { SelectionKey key it.next(); it.remove(); // 必須手動移除否則重復處理 if (key.isAcceptable()) handleAccept(key); else if (key.isReadable()) handleRead(key); } } } private void handleAccept(SelectionKey key) throws IOException { SocketChannel client ((ServerSocketChannel) key.channel()).accept(); client.configureBlocking(false); client.register(selector, SelectionKey.OP_READ); sessions.put(client, new ClientSession(client)); } private void handleRead(SelectionKey key) { SocketChannel client (SocketChannel) key.channel(); ByteBuffer buf ByteBuffer.allocate(1024); try { int n client.read(buf); if (n -1) { closeSession(client); return; } buf.flip(); // 交給協(xié)議解析器處理半包/粘包 ProtocolDecoder.decode(sessions.get(client), buf); } catch (IOException e) { closeSession(client); } } }邏輯說明selector.select()是核心它讓一個線程同時盯著所有連接的讀寫事件。configureBlocking(false)是硬性前提忘了寫這行register會直接拋IllegalBlockingModeException。it.remove()也是血淚經(jīng)驗不刪的話同一個事件會被反復處理表現(xiàn)為「玩家移動一次服務器收到十次」。參數(shù)說明ByteBuffer.allocate(1024)是每個讀事件的緩沖區(qū)大小。飛機游戲單個消息通常幾十字節(jié)1024 夠用但如果你把整張地圖快照塞進一個包就得調(diào)大或者改成「長度前綴 分片」。port建議選 1024 以上避免權限問題。2.3 房間與廣播把「誰該收到這條消息」想清楚服務器收到一個玩家位置更新后不能無腦廣播給所有人。飛機游戲里同一房間的玩家才需要互相看見。所以ClientSession里要掛一個roomId廣播時按房間過濾。// 按房間廣播避免跨房間串消息 public void broadcast(int roomId, GameMessage msg) { byte[] data ProtocolEncoder.encode(msg); for (ClientSession s : sessions.values()) { if (s.getRoomId() roomId s.isAlive()) { s.send(data); // send 內(nèi)部用 channel.write注意處理寫半包 } } }這里有個容易翻車的點SocketChannel.write()在非阻塞模式下不保證一次寫完。如果對方接收慢返回值會小于data.length剩下的字節(jié)必須緩存起來等OP_WRITE就緒再寫。很多人第一次寫 NIO 服務器測試時好好的一上壓力就丟包就是栽在這。穩(wěn)妥做法是給每個ClientSession配一個發(fā)送隊列寫不完的掛隊列注冊OP_WRITE事件續(xù)寫。3. 客戶端設計渲染循環(huán)和網(wǎng)絡線程必須分家3.1 為什么不能在 Swing 的 EDT 里讀 Socket客戶端最容易犯的錯是把網(wǎng)絡讀取直接寫在paintComponent或者按鈕回調(diào)里。Swing 的事件分發(fā)線程EDT是單線程的你在里面socket.read()阻塞一下整個界面就卡死玩家看到的是「未響應」。正確做法是網(wǎng)絡收發(fā)放獨立線程收到數(shù)據(jù)后只更新一份共享的游戲狀態(tài)渲染線程按固定幀率去讀這份狀態(tài)。// NetworkClient.java —— 獨立網(wǎng)絡線程 public class NetworkClient implements Runnable { private Socket socket; private DataInputStream in; private volatile GameState state; // volatile 保證渲染線程能看到最新引用 Override public void run() { try { socket new Socket(127.0.0.1, 8888); in new DataInputStream(socket.getInputStream()); while (!Thread.currentThread().isInterrupted()) { int len in.readInt(); // 先讀長度前綴 byte[] body new byte[len]; in.readFully(body); // 保證讀滿避免半包 GameMessage msg ProtocolDecoder.decode(body); state.apply(msg); // 只更新狀態(tài)不碰 UI } } catch (IOException e) { // 斷線處理標記狀態(tài)讓渲染層顯示連接已斷開 state.setDisconnected(true); } } }邏輯說明readInt()讀長度、readFully()讀滿這是解決 TCP 粘包/半包最樸素也最可靠的辦法——長度前綴協(xié)議。發(fā)送端先寫 4 字節(jié)長度再寫正文接收端先讀長度再按長度讀滿。state.apply(msg)只改數(shù)據(jù)絕不在這里調(diào)repaint()否則線程安全問題會讓你懷疑人生。參數(shù)說明volatile修飾state引用保證一個線程改了引用另一個線程立刻可見。但注意volatile不保證GameState內(nèi)部字段的原子性如果多個字段要一起更新得加鎖或者用不可變對象整體替換。3.2 渲染循環(huán)用固定時間步長別用「能跑多快跑多快」// GamePanel.java —— 固定 60FPS 的渲染循環(huán) public class GamePanel extends JPanel implements ActionListener { private static final int FPS 60; private final Timer timer new Timer(1000 / FPS, this); public GamePanel(GameState state) { this.state state; timer.start(); } Override public void actionPerformed(ActionEvent e) { state.interpolate(); // 根據(jù)上次/本次快照做插值緩解網(wǎng)絡抖動 repaint(); } Override protected void paintComponent(Graphics g) { super.paintComponent(g); // 只讀 state畫飛機、子彈、敵機 for (Plane p : state.getPlanes()) { g.drawImage(p.getImage(), p.getRenderX(), p.getRenderY(), null); } } }邏輯說明Timer每 16ms 觸發(fā)一次interpolate()是關鍵。服務器 20Hz 發(fā)位置客戶端 60Hz 渲染中間那兩幀怎么辦用插值。保存上一幀和當前幀的位置按時間比例算中間值飛機就不會一格一格地跳。這是「看起來流暢」和「看起來卡頓」的分水嶺。參數(shù)說明FPS 60是渲染幀率和服務器廣播頻率比如 20Hz解耦。別把兩者設成一樣網(wǎng)絡一抖畫面就跟著抖。interpolate()的插值系數(shù)建議用(now - lastUpdateTime) / interval并做 01 的鉗制防止時間回退導致飛機倒著飛。4. 協(xié)議與狀態(tài)同步定好「誰說了算」再寫代碼4.1 消息格式二進制還是 JSON新手喜歡用 JSON因為可讀。但飛機游戲每秒幾十條消息JSON 的字符串解析開銷和體積都偏大。我的做法是二進制協(xié)議1 字節(jié)消息類型 若干字段。比如玩家位置消息type(1) playerId(4) x(4) y(4) timestamp(8)一共 21 字節(jié)。對比 JSON 的{t:pos,id:1,x:100,y:200}三四十字節(jié)省一半還多。字段類型字節(jié)數(shù)說明typebyte1消息類型1位置 2開火 3加入 4離開playerIdint4玩家唯一 ID服務器分配xfloat4飛機橫坐標yfloat4飛機縱坐標timestamplong8客戶端發(fā)送時刻用于延遲補償用ByteBuffer讀寫這套結構比DataOutputStream更靈活因為可以控制字節(jié)序統(tǒng)一用ByteOrder.BIG_ENDIAN避免大小端不一致。4.2 權威服務器位置由服務器裁決客戶端只做預測聯(lián)機游戲最大的坑是「兩個客戶端各算各的」。A 看到自己在 (100,100)B 看到 A 在 (98,102)打起來就是互相覺得對方作弊。解決辦法是服務器權威客戶端只上報「我按了哪個方向鍵」服務器算出真實位置再廣播給所有人。// 服務器端處理玩家輸入 public void onPlayerInput(ClientSession s, InputMsg input) { Plane p s.getPlane(); float speed 5.0f; // 每 tick 移動像素 if (input.hasFlag(InputMsg.UP)) p.y - speed; if (input.hasFlag(InputMsg.DOWN)) p.y speed; if (input.hasFlag(InputMsg.LEFT)) p.x - speed; if (input.hasFlag(InputMsg.RIGHT)) p.x speed; p.clampToBounds(800, 600); // 服務器做邊界校驗防作弊 broadcast(s.getRoomId(), new PosMsg(p)); }邏輯說明客戶端發(fā)的是「意圖」按了上不是「結果」我在 y95。服務器統(tǒng)一按speed計算所有人看到的 A 位置一致。clampToBounds是防作弊底線客戶端就算改了本地坐標服務器也不認。參數(shù)說明speed 5.0f是每 tick 移動量配合服務器 tick 頻率比如 20Hz就是 100 像素/秒。這個值要和客戶端預測用的值完全一致否則會出現(xiàn)「我明明沒動服務器說我動了」的拉扯感。客戶端預測client-side prediction是進階話題本地先按同樣規(guī)則移動等服務器消息回來再校正能顯著降低操作延遲感。5. 避坑與排查那些讓我熬夜到三點的聯(lián)機問題5.1 現(xiàn)象玩家移動一頓一頓像幻燈片原因服務器廣播頻率太低或者客戶端沒做插值直接按收到的離散位置渲染。20Hz 的位置更新60Hz 的屏幕中間兩幀沒數(shù)據(jù)飛機就停在原地等下一包。解決客戶端加插值見 3.2服務器廣播頻率提到 2030Hz。別盲目提到 60Hz帶寬和 CPU 扛不住插值才是正解。5.2 現(xiàn)象兩個人同時開火一方總看不到另一方的子彈原因子彈生成邏輯放在了客戶端本地各自算各自的。A 的子彈在 A 屏幕上飛B 根本不知道。解決開火事件必須上報服務器由服務器生成子彈實體并廣播?？蛻舳耸盏紹ulletSpawnMsg才創(chuàng)建子彈對象。所有游戲實體的生命周期都由服務器管。5.3 現(xiàn)象玩幾分鐘后服務器 CPU 飆到 100%原因Selector的selectedKeys沒清理或者OP_WRITE一直注冊著導致空轉。非阻塞 channel 只要可寫select()就立刻返回形成忙等。解決只在有數(shù)據(jù)要寫時才注冊OP_WRITE寫完立刻interestOps(OP_READ)取消。檢查it.remove()有沒有漏。5.4 現(xiàn)象玩家掉線后他的飛機還停在原地別人還能打中原因沒有心跳機制服務器不知道對方已經(jīng)斷了。TCP 連接在正常關閉時會觸發(fā)read() -1但如果是網(wǎng)線拔了、進程被殺服務器可能很久都感知不到。解決加心跳?？蛻舳嗣?2 秒發(fā)一個HeartbeatMsg服務器記錄每個 session 的lastActiveTime超過 10 秒沒收到就判定掉線廣播PlayerLeaveMsg并清理實體。5.5 現(xiàn)象本地測試完美一放到公網(wǎng)就各種超時原因本地127.0.0.1延遲接近 0掩蓋了所有時序問題。公網(wǎng) 100ms 延遲下客戶端預測和服務器校正打架表現(xiàn)為飛機來回抽搐。解決本地測試時人為加延遲?？梢栽诰W(wǎng)絡線程里Thread.sleep(100)模擬或者用工具做流量整形。所有同步邏輯必須在 100200ms 延遲下驗證過才算數(shù)。6. 進階技巧用狀態(tài)快照 差值壓縮把帶寬打下來當房間人數(shù)上到 8 人、實體上百個時每 tick 全量廣播會迅速吃滿帶寬。我一般會做兩件事狀態(tài)快照和差值壓縮。狀態(tài)快照是服務器每隔 N 個 tick 發(fā)一次完整狀態(tài)中間只發(fā)變化量。差值壓縮更狠只發(fā)和上一幀不同的字段。比如飛機沒動就不發(fā)位置只發(fā)一個「無變化」標記。// 差值編碼只發(fā)變化的實體 public byte[] encodeDelta(GameState prev, GameState curr) { ByteBuffer buf ByteBuffer.allocate(4096); buf.put((byte) MSG_DELTA); int countPos buf.position(); buf.putShort((short) 0); // 先占位最后回填變化數(shù)量 short changed 0; for (Plane p : curr.getPlanes()) { Plane old prev.getPlane(p.getId()); if (old null || old.getX() ! p.getX() || old.getY() ! p.getY()) { buf.putInt(p.getId()); buf.putFloat(p.getX()); buf.putFloat(p.getY()); changed; } } buf.putShort(countPos, changed); // 回填真實數(shù)量 byte[] out new byte[buf.position()]; buf.flip(); buf.get(out); return out; }邏輯說明先占位再回填是二進制協(xié)議的常用手法因為變化數(shù)量要等遍歷完才知道?？蛻舳耸盏組SG_DELTA后按playerId找到本地實體只更新變化的坐標沒提到的實體保持不動。參數(shù)說明ByteBuffer.allocate(4096)要按最大可能變化量估算8 人 × 12 字節(jié) 96 字節(jié)4096 綽綽有余。如果實體數(shù)量可能上千得改成分片發(fā)送或者用更激進的量化——坐標從 float 壓成 short精度降到 1 像素體積直接減半。驗證這套壓縮有沒有效果別靠感覺。在服務器端統(tǒng)計每 tick 發(fā)送的字節(jié)數(shù)打印出來對比全量廣播。我自己的經(jīng)驗是8 人房間從每 tick 約 800 字節(jié)降到 150 字節(jié)左右效果立竿見影。但差值壓縮有個后悔藥問題一旦某個包丟了客戶端狀態(tài)就和服務器永久不一致。所以每隔 12 秒必須補發(fā)一次全量快照做校正這個「全量兜底」的間隔就是你要調(diào)的參數(shù)太密省不了帶寬太疏狀態(tài)會漂。最后說個習慣我做完任何聯(lián)機功能都會先在本機開兩個客戶端加人為延遲跑一遍再拉一個同事跨網(wǎng)絡實測。本地全綠不代表線上能用網(wǎng)絡這東西永遠比你想象的更玄學。希望幫到你。本文還有配套的精品資源點擊獲取 JAVA多人聯(lián)機飛機游戲：NIO服務器與客戶端架構設計實戰(zhàn)
簡介這是一套面向Java游戲開發(fā)初學者與網(wǎng)絡編程學習者的多人聯(lián)機飛機游戲完整源碼包含客戶端與服務器端兩部分可用于理解C/S架構下的游戲邏輯分離、通信同步與界面渲染等核心問題。資源包共25個文件約36KB以Java源文件與編譯后的class文件為主體另含classpath路徑配置、Eclipse項目配置與用戶偏好設置文件以及授權協(xié)議和說明文檔結構清晰、便于導入IDE直接閱讀調(diào)試。目前已有320人學習關注。項目將用戶界面、圖形渲染與輸入處理放在客戶端把游戲狀態(tài)管理、邏輯運算與數(shù)據(jù)同步交由服務器端讀者可借此掌握Socket通信、多線程并發(fā)、AWT/Swing界面設計等關鍵技術的落地方式并參考其模塊劃分與配置組織快速搭建自己的聯(lián)機游戲原型或課程設計框架。1. 從「能雙人同屏」到「能跨網(wǎng)聯(lián)機」JAVA 多人聯(lián)機飛機游戲到底難在哪單機版飛機大戰(zhàn)很多人一兩天就能擼出來一個JFrame一個Timer循環(huán)鍵盤監(jiān)聽控制飛機移動碰撞檢測用矩形相交完事?？梢坏祟}里加上「多人聯(lián)機」四個字難度不是加一而是乘十。你要面對的是兩臺機器上的子彈位置怎么保持一致、誰說了算、網(wǎng)絡延遲 200ms 時對方飛機瞬移怎么辦、玩家中途掉線房間怎么收場。這些才是 JAVA 多人聯(lián)機飛機游戲客戶端及服務器端設計里真正值錢的部分。這篇筆記面向的是已經(jīng)會寫 JAVA 基礎語法、能看懂Socket和線程但沒真正做過聯(lián)機游戲的開發(fā)者。我會把一套可復現(xiàn)的 C/S 架構拆開服務器端用什么模型扛連接、客戶端怎么把渲染和網(wǎng)絡解耦、協(xié)議怎么定、狀態(tài)怎么同步、掉線怎么兜底。讀完你應該能自己搭出一個 28 人同房間、局域網(wǎng)或公網(wǎng)可玩的飛機對戰(zhàn)原型并且知道哪些參數(shù)一改就翻車。熱搜里那些「客戶端和服務端區(qū)別」「java 環(huán)境配置」的問題本質都會在這套架構里被逼著回答一遍。2. 服務器端選型為什么我最終放棄阻塞 IO改用 NIO 線程池2.1 三種服務器模型的取舍BIO、NIO、Netty做飛機游戲服務器第一道坎是通信模型。最直覺的寫法是ServerSocket.accept()拿到一個連接就開一個線程這就是阻塞 IOBIO。10 個玩家以內(nèi)它跑得好好的代碼也好懂。但飛機游戲有個特點高頻小包。玩家飛機位置、子彈坐標、敵機狀態(tài)每秒要廣播 2030 次。BIO 下每個連接一個線程線程上下文切換的開銷會隨著人數(shù)線性上漲50 人就開始抖。第二種是 JAVA 原生 NIO用Selector做多路復用一個線程管一堆連接。它省線程但ByteBuffer的讀寫、半包粘包處理、SelectionKey的狀態(tài)機寫起來非常容易出玄學 bug。第三種是 Netty本質是 NIO 的封裝幫你把粘包拆包、心跳、編解碼都做好了。我的建議很明確學習目的、想搞懂底層用原生 NIO想快速出可玩版本用 Netty。下面這套代碼我用原生 NIO 寫因為標題強調(diào)「設計」你得看見Selector長什么樣。2.2 用 NIO 搭一個能收發(fā)的服務器骨架// GameServer.java —— NIO 服務器主循環(huán)骨架 public class GameServer { private Selector selector; private ServerSocketChannel serverChannel; // 每個連接對應一個 ClientSession保存玩家狀態(tài) private MapSocketChannel, ClientSession sessions new ConcurrentHashMap(); public void start(int port) throws IOException { selector Selector.open(); serverChannel ServerSocketChannel.open(); serverChannel.configureBlocking(false); // 必須非阻塞否則 Selector 失效 serverChannel.socket().bind(new InetSocketAddress(port)); serverChannel.register(selector, SelectionKey.OP_ACCEPT); System.out.println(server listening on port); while (true) { selector.select(); // 阻塞直到有事件就緒 IteratorSelectionKey it selector.selectedKeys().iterator(); while (it.hasNext()) { SelectionKey key it.next(); it.remove(); // 必須手動移除否則重復處理 if (key.isAcceptable()) handleAccept(key); else if (key.isReadable()) handleRead(key); } } } private void handleAccept(SelectionKey key) throws IOException { SocketChannel client ((ServerSocketChannel) key.channel()).accept(); client.configureBlocking(false); client.register(selector, SelectionKey.OP_READ); sessions.put(client, new ClientSession(client)); } private void handleRead(SelectionKey key) { SocketChannel client (SocketChannel) key.channel(); ByteBuffer buf ByteBuffer.allocate(1024); try { int n client.read(buf); if (n -1) { closeSession(client); return; } buf.flip(); // 交給協(xié)議解析器處理半包/粘包 ProtocolDecoder.decode(sessions.get(client), buf); } catch (IOException e) { closeSession(client); } } }邏輯說明selector.select()是核心它讓一個線程同時盯著所有連接的讀寫事件。configureBlocking(false)是硬性前提忘了寫這行register會直接拋IllegalBlockingModeException。it.remove()也是血淚經(jīng)驗不刪的話同一個事件會被反復處理表現(xiàn)為「玩家移動一次服務器收到十次」。參數(shù)說明ByteBuffer.allocate(1024)是每個讀事件的緩沖區(qū)大小。飛機游戲單個消息通常幾十字節(jié)1024 夠用但如果你把整張地圖快照塞進一個包就得調(diào)大或者改成「長度前綴 分片」。port建議選 1024 以上避免權限問題。2.3 房間與廣播把「誰該收到這條消息」想清楚服務器收到一個玩家位置更新后不能無腦廣播給所有人。飛機游戲里同一房間的玩家才需要互相看見。所以ClientSession里要掛一個roomId廣播時按房間過濾。// 按房間廣播避免跨房間串消息 public void broadcast(int roomId, GameMessage msg) { byte[] data ProtocolEncoder.encode(msg); for (ClientSession s : sessions.values()) { if (s.getRoomId() roomId s.isAlive()) { s.send(data); // send 內(nèi)部用 channel.write注意處理寫半包 } } }這里有個容易翻車的點SocketChannel.write()在非阻塞模式下不保證一次寫完。如果對方接收慢返回值會小于data.length剩下的字節(jié)必須緩存起來等OP_WRITE就緒再寫。很多人第一次寫 NIO 服務器測試時好好的一上壓力就丟包就是栽在這。穩(wěn)妥做法是給每個ClientSession配一個發(fā)送隊列寫不完的掛隊列注冊OP_WRITE事件續(xù)寫。3. 客戶端設計渲染循環(huán)和網(wǎng)絡線程必須分家3.1 為什么不能在 Swing 的 EDT 里讀 Socket客戶端最容易犯的錯是把網(wǎng)絡讀取直接寫在paintComponent或者按鈕回調(diào)里。Swing 的事件分發(fā)線程EDT是單線程的你在里面socket.read()阻塞一下整個界面就卡死玩家看到的是「未響應」。正確做法是網(wǎng)絡收發(fā)放獨立線程收到數(shù)據(jù)后只更新一份共享的游戲狀態(tài)渲染線程按固定幀率去讀這份狀態(tài)。// NetworkClient.java —— 獨立網(wǎng)絡線程 public class NetworkClient implements Runnable { private Socket socket; private DataInputStream in; private volatile GameState state; // volatile 保證渲染線程能看到最新引用 Override public void run() { try { socket new Socket(127.0.0.1, 8888); in new DataInputStream(socket.getInputStream()); while (!Thread.currentThread().isInterrupted()) { int len in.readInt(); // 先讀長度前綴 byte[] body new byte[len]; in.readFully(body); // 保證讀滿避免半包 GameMessage msg ProtocolDecoder.decode(body); state.apply(msg); // 只更新狀態(tài)不碰 UI } } catch (IOException e) { // 斷線處理標記狀態(tài)讓渲染層顯示連接已斷開 state.setDisconnected(true); } } }邏輯說明readInt()讀長度、readFully()讀滿這是解決 TCP 粘包/半包最樸素也最可靠的辦法——長度前綴協(xié)議。發(fā)送端先寫 4 字節(jié)長度再寫正文接收端先讀長度再按長度讀滿。state.apply(msg)只改數(shù)據(jù)絕不在這里調(diào)repaint()否則線程安全問題會讓你懷疑人生。參數(shù)說明volatile修飾state引用保證一個線程改了引用另一個線程立刻可見。但注意volatile不保證GameState內(nèi)部字段的原子性如果多個字段要一起更新得加鎖或者用不可變對象整體替換。3.2 渲染循環(huán)用固定時間步長別用「能跑多快跑多快」// GamePanel.java —— 固定 60FPS 的渲染循環(huán) public class GamePanel extends JPanel implements ActionListener { private static final int FPS 60; private final Timer timer new Timer(1000 / FPS, this); public GamePanel(GameState state) { this.state state; timer.start(); } Override public void actionPerformed(ActionEvent e) { state.interpolate(); // 根據(jù)上次/本次快照做插值緩解網(wǎng)絡抖動 repaint(); } Override protected void paintComponent(Graphics g) { super.paintComponent(g); // 只讀 state畫飛機、子彈、敵機 for (Plane p : state.getPlanes()) { g.drawImage(p.getImage(), p.getRenderX(), p.getRenderY(), null); } } }邏輯說明Timer每 16ms 觸發(fā)一次interpolate()是關鍵。服務器 20Hz 發(fā)位置客戶端 60Hz 渲染中間那兩幀怎么辦用插值。保存上一幀和當前幀的位置按時間比例算中間值飛機就不會一格一格地跳。這是「看起來流暢」和「看起來卡頓」的分水嶺。參數(shù)說明FPS 60是渲染幀率和服務器廣播頻率比如 20Hz解耦。別把兩者設成一樣網(wǎng)絡一抖畫面就跟著抖。interpolate()的插值系數(shù)建議用(now - lastUpdateTime) / interval并做 01 的鉗制防止時間回退導致飛機倒著飛。4. 協(xié)議與狀態(tài)同步定好「誰說了算」再寫代碼4.1 消息格式二進制還是 JSON新手喜歡用 JSON因為可讀。但飛機游戲每秒幾十條消息JSON 的字符串解析開銷和體積都偏大。我的做法是二進制協(xié)議1 字節(jié)消息類型 若干字段。比如玩家位置消息type(1) playerId(4) x(4) y(4) timestamp(8)一共 21 字節(jié)。對比 JSON 的{t:pos,id:1,x:100,y:200}三四十字節(jié)省一半還多。字段類型字節(jié)數(shù)說明typebyte1消息類型1位置 2開火 3加入 4離開playerIdint4玩家唯一 ID服務器分配xfloat4飛機橫坐標yfloat4飛機縱坐標timestamplong8客戶端發(fā)送時刻用于延遲補償用ByteBuffer讀寫這套結構比DataOutputStream更靈活因為可以控制字節(jié)序統(tǒng)一用ByteOrder.BIG_ENDIAN避免大小端不一致。4.2 權威服務器位置由服務器裁決客戶端只做預測聯(lián)機游戲最大的坑是「兩個客戶端各算各的」。A 看到自己在 (100,100)B 看到 A 在 (98,102)打起來就是互相覺得對方作弊。解決辦法是服務器權威客戶端只上報「我按了哪個方向鍵」服務器算出真實位置再廣播給所有人。// 服務器端處理玩家輸入 public void onPlayerInput(ClientSession s, InputMsg input) { Plane p s.getPlane(); float speed 5.0f; // 每 tick 移動像素 if (input.hasFlag(InputMsg.UP)) p.y - speed; if (input.hasFlag(InputMsg.DOWN)) p.y speed; if (input.hasFlag(InputMsg.LEFT)) p.x - speed; if (input.hasFlag(InputMsg.RIGHT)) p.x speed; p.clampToBounds(800, 600); // 服務器做邊界校驗防作弊 broadcast(s.getRoomId(), new PosMsg(p)); }邏輯說明客戶端發(fā)的是「意圖」按了上不是「結果」我在 y95。服務器統(tǒng)一按speed計算所有人看到的 A 位置一致。clampToBounds是防作弊底線客戶端就算改了本地坐標服務器也不認。參數(shù)說明speed 5.0f是每 tick 移動量配合服務器 tick 頻率比如 20Hz就是 100 像素/秒。這個值要和客戶端預測用的值完全一致否則會出現(xiàn)「我明明沒動服務器說我動了」的拉扯感。客戶端預測client-side prediction是進階話題本地先按同樣規(guī)則移動等服務器消息回來再校正能顯著降低操作延遲感。5. 避坑與排查那些讓我熬夜到三點的聯(lián)機問題5.1 現(xiàn)象玩家移動一頓一頓像幻燈片原因服務器廣播頻率太低或者客戶端沒做插值直接按收到的離散位置渲染。20Hz 的位置更新60Hz 的屏幕中間兩幀沒數(shù)據(jù)飛機就停在原地等下一包。解決客戶端加插值見 3.2服務器廣播頻率提到 2030Hz。別盲目提到 60Hz帶寬和 CPU 扛不住插值才是正解。5.2 現(xiàn)象兩個人同時開火一方總看不到另一方的子彈原因子彈生成邏輯放在了客戶端本地各自算各自的。A 的子彈在 A 屏幕上飛B 根本不知道。解決開火事件必須上報服務器由服務器生成子彈實體并廣播?？蛻舳耸盏紹ulletSpawnMsg才創(chuàng)建子彈對象。所有游戲實體的生命周期都由服務器管。5.3 現(xiàn)象玩幾分鐘后服務器 CPU 飆到 100%原因Selector的selectedKeys沒清理或者OP_WRITE一直注冊著導致空轉。非阻塞 channel 只要可寫select()就立刻返回形成忙等。解決只在有數(shù)據(jù)要寫時才注冊OP_WRITE寫完立刻interestOps(OP_READ)取消。檢查it.remove()有沒有漏。5.4 現(xiàn)象玩家掉線后他的飛機還停在原地別人還能打中原因沒有心跳機制服務器不知道對方已經(jīng)斷了。TCP 連接在正常關閉時會觸發(fā)read() -1但如果是網(wǎng)線拔了、進程被殺服務器可能很久都感知不到。解決加心跳?？蛻舳嗣?2 秒發(fā)一個HeartbeatMsg服務器記錄每個 session 的lastActiveTime超過 10 秒沒收到就判定掉線廣播PlayerLeaveMsg并清理實體。5.5 現(xiàn)象本地測試完美一放到公網(wǎng)就各種超時原因本地127.0.0.1延遲接近 0掩蓋了所有時序問題。公網(wǎng) 100ms 延遲下客戶端預測和服務器校正打架表現(xiàn)為飛機來回抽搐。解決本地測試時人為加延遲?？梢栽诰W(wǎng)絡線程里Thread.sleep(100)模擬或者用工具做流量整形。所有同步邏輯必須在 100200ms 延遲下驗證過才算數(shù)。6. 進階技巧用狀態(tài)快照 差值壓縮把帶寬打下來當房間人數(shù)上到 8 人、實體上百個時每 tick 全量廣播會迅速吃滿帶寬。我一般會做兩件事狀態(tài)快照和差值壓縮。狀態(tài)快照是服務器每隔 N 個 tick 發(fā)一次完整狀態(tài)中間只發(fā)變化量。差值壓縮更狠只發(fā)和上一幀不同的字段。比如飛機沒動就不發(fā)位置只發(fā)一個「無變化」標記。// 差值編碼只發(fā)變化的實體 public byte[] encodeDelta(GameState prev, GameState curr) { ByteBuffer buf ByteBuffer.allocate(4096); buf.put((byte) MSG_DELTA); int countPos buf.position(); buf.putShort((short) 0); // 先占位最后回填變化數(shù)量 short changed 0; for (Plane p : curr.getPlanes()) { Plane old prev.getPlane(p.getId()); if (old null || old.getX() ! p.getX() || old.getY() ! p.getY()) { buf.putInt(p.getId()); buf.putFloat(p.getX()); buf.putFloat(p.getY()); changed; } } buf.putShort(countPos, changed); // 回填真實數(shù)量 byte[] out new byte[buf.position()]; buf.flip(); buf.get(out); return out; }邏輯說明先占位再回填是二進制協(xié)議的常用手法因為變化數(shù)量要等遍歷完才知道?？蛻舳耸盏組SG_DELTA后按playerId找到本地實體只更新變化的坐標沒提到的實體保持不動。參數(shù)說明ByteBuffer.allocate(4096)要按最大可能變化量估算8 人 × 12 字節(jié) 96 字節(jié)4096 綽綽有余。如果實體數(shù)量可能上千得改成分片發(fā)送或者用更激進的量化——坐標從 float 壓成 short精度降到 1 像素體積直接減半。驗證這套壓縮有沒有效果別靠感覺。在服務器端統(tǒng)計每 tick 發(fā)送的字節(jié)數(shù)打印出來對比全量廣播。我自己的經(jīng)驗是8 人房間從每 tick 約 800 字節(jié)降到 150 字節(jié)左右效果立竿見影。但差值壓縮有個后悔藥問題一旦某個包丟了客戶端狀態(tài)就和服務器永久不一致。所以每隔 12 秒必須補發(fā)一次全量快照做校正這個「全量兜底」的間隔就是你要調(diào)的參數(shù)太密省不了帶寬太疏狀態(tài)會漂。最后說個習慣我做完任何聯(lián)機功能都會先在本機開兩個客戶端加人為延遲跑一遍再拉一個同事跨網(wǎng)絡實測。本地全綠不代表線上能用網(wǎng)絡這東西永遠比你想象的更玄學。希望幫到你。本文還有配套的精品資源點擊獲取