建立BIO多人聊天室

建立多人聊天室：

使用的是 阻塞式模型，這裡隻涉及多人聊天，不涉及 一對一聊天，使用了多線程.

接收資料時：要将換行符丢棄。

 2台以上裝置如何互動資料？

1.約定一個基礎的資料格式：使用回車換行符作為資訊的截斷。

2. 用戶端 - 伺服器  - 轉發到 用戶端 【三者及以上，使用者1 發送資訊到伺服器，伺服器周遊其他的用戶端，将該消息通知到其他用戶端上】

1.用戶端：

首先使用 UDP 廣播，擷取 tcp 伺服器的端口号和IP位址，

然後進行 tcp 的 用戶端 和 伺服器的連接配接

在 TCPClient 中 隻有一個讀線程，沒有寫線程（）

寫是在 client 類中進行的

2.對 tcp服務端 類的分析：

2.1 ：  server類【充當一個視窗】： 負責 啟動  TCPServer 和 UDPProvider 類，并且 将 從鍵盤傳入的資訊轉發給 已連接配接的用戶端。

2.2: TCPServer 類：

1.  start 函數：啟動 對用戶端進行監聽的類：ClientListener

2.：  ClientListener【多線程類】：使用 do-while 循環 監聽用戶端的連接配接。

每有一個用戶端連接配接，就建構一個異步線程ClientHandler。

server.accept(); 是阻塞式的，即若沒有用戶端連接配接，就一直阻塞在這裡
           

3 ： ClientHandler：真正對用戶端的消息的讀寫進行處理 ：

首先明确的是：用戶端的讀寫是分離的 ，互不幹擾（即讀一個線程，寫一個線程）

這是一個讀線程

但是 對于寫線程來說【對用戶端消息的轉發】：（

這裡沒有讓 ClientWriteHandler 繼承 Thread , 是因為 繼承了Thread，對于寫線程來說， 大部分時間都在等待，

但是實作該等待是比較複雜的，這涉及到了 多線程的協作問題，   是以就設定成了 單線程池）
           

伺服器性能分析：

伺服器需要GC回收 和主線程（這就兩條了）

監聽用戶端的連接配接，

轉發用戶端資訊也使用了一個單線程池

是以伺服器的實際線程數量至少是：2n+4

進行了一下用戶端壓測:能承受1000個左右，消耗90多M的記憶體和50的cpu量

和2000多個線程

伺服器優化：